Przeglądanie dzienników w celu diagnozowania problemów z potokami

  • Artykuł

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Dzienniki potoków udostępniają zaawansowane narzędzie do określania przyczyny awarii potoku, a pełne dzienniki można skonfigurować w celu udostępnienia dodatkowych informacji diagnostycznych.

Typowym punktem wyjścia jest przejrzenie dzienników w ukończonej kompilacji lub wydaniu. Dzienniki można wyświetlić, przechodząc do podsumowania przebiegu potoku i wybierając zadanie i zadanie. Jeśli określone zadanie kończy się niepowodzeniem, sprawdź dzienniki dla tego zadania. Skonfiguruj pełne dzienniki , aby uwzględnić więcej informacji diagnostycznych.

Konfigurowanie pełnych dzienników

Aby pomóc w rozwiązywaniu problemów, możesz skonfigurować dzienniki tak, aby były bardziej szczegółowe.

  • Aby skonfigurować pełne dzienniki dla pojedynczego przebiegu, możesz uruchomić nową kompilację, wybierając pozycję Uruchom potok i wybierając pozycję Włącz diagnostykę systemu, Uruchom.

    Włączanie diagnostyki systemu

  • Aby skonfigurować pełne dzienniki dla wszystkich przebiegów, możesz dodać zmienną o nazwie system.debug i ustawić jej wartość na true.

  • Aby skonfigurować pełne dzienniki dla pojedynczego przebiegu, możesz uruchomić nową kompilację, wybierając pozycję Kompilacja kolejki i ustawiając wartość zmiennej system.debug na true.

  • Aby skonfigurować pełne dzienniki dla wszystkich przebiegów, zmodyfikuj kompilację, przejdź do karty Zmienne i dodaj zmienną o nazwie system.debug, ustaw jej wartość na true, a następnie wybierz opcję Zezwalaj na czas kolejki.

  • Aby skonfigurować pełne dzienniki dla potoku YAML, dodaj zmienną system.debug w variables sekcji :

    variables:
  system.debug: true

Dzienniki potoku platformy Azure mogą teraz przechwytywać metryki wykorzystania zasobów, takie jak pamięć, użycie procesora CPU i dostępne miejsce na dysku. Dzienniki obejmują również zasoby używane przez agenta potoku i procesy podrzędne, w tym zadania uruchamiane w zadaniu. Jeśli podejrzewasz, że zadanie potoku może napotkać ograniczenia zasobów, włącz pełne dzienniki, aby informacje o wykorzystaniu zasobów zostały wprowadzone do dzienników potoku. Metryki wykorzystania zasobów są dostępne dla dowolnego agenta niezależnie od modelu hostingu.

Aby wyświetlić przechwycone metryki wykorzystania zasobów, przeszukaj dzienniki pod Agent environment resources kątem wpisów dla każdego kroku.

2024-02-28T17:41:15.1315148Z ##[debug]Agent environment resources - Disk: D:\ Available 12342.00 MB out of 14333.00 MB, Memory: Used 1907.00 MB out of 7167.00 MB, CPU: Usage 17.23%

Wyświetlanie i pobieranie dzienników

Aby wyświetlić poszczególne dzienniki dla każdego kroku, przejdź do wyników kompilacji dla przebiegu, a następnie wybierz zadanie i krok.

Dziennik zadań

Aby pobrać wszystkie dzienniki, przejdź do wyników kompilacji dla przebiegu, wybierz pozycję ..., a następnie wybierz pozycję Pobierz dzienniki.

Pobierz dzienniki

Aby pobrać wszystkie dzienniki, przejdź do wyników kompilacji dla przebiegu, wybierz pozycję Pobierz wszystkie dzienniki jako zip.

Oprócz dzienników diagnostycznych potoku dostępne są następujące wyspecjalizowane typy dzienników i mogą zawierać informacje ułatwiające rozwiązywanie problemów.

Dzienniki diagnostyczne procesu roboczego

Dziennik diagnostyczny ukończonej kompilacji wygenerowanej przez proces roboczy można pobrać na agencie kompilacji. worker Poszukaj pliku dziennika zawierającego sygnaturę daty i godziny ukończonej kompilacji. Na przykład worker_20160623-192022-utc_6172.log.

Dzienniki diagnostyczne agenta

Dzienniki diagnostyczne agenta zawierają rekord sposobu konfigurowania agenta i tego, co się stało po uruchomieniu. agent Wyszukaj pliki dziennika. Na przykład agent_20160624-144630-utc.log. Istnieją dwa rodzaje plików dziennika agenta:

  • Plik dziennika wygenerowany podczas uruchamiania config.cmdpolecenia . Ten dziennik:

    • Zawiera ten wiersz w górnej części: Adding Command: configure

    • Pokazuje dokonane wybory konfiguracji.

  • Plik dziennika wygenerowany podczas uruchamiania run.cmdpolecenia . Ten dziennik:

    • Nie można otworzyć, dopóki proces nie zostanie zakończony.

    • Próbuje nawiązać połączenie z organizacją usługi Azure DevOps lub serwerem Team Foundation Server.

    • Pokazuje, kiedy każde zadanie zostało uruchomione i jak zostało ukończone

Oba dzienniki pokazują, jak zostały wykryte i ustawione możliwości agenta.

Diagnostyka sieci dla własnych agentów

Dla elementu Agent.Diagnostic ustaw wartość true, aby zebrać dodatkowe dzienniki, których można użyć do rozwiązywania problemów z siecią w przypadku własnych agentów.

Plik Informacja Dotyczy
cloudinit.* Pomyślnie ukończono inicjowanie chmury (jeśli jest używane) Linux
BrokenPackages.* Pakiety są w stanie spójnym Linux
Agent.* Zmienne środowiskowe Linux, Windows
waagentConf.txt Agent maszyny wirtualnej platformy Azure (waagent.conf) Azure: Linux, Windows
environment.txt / agent.* Lista członkostwa w grupie kont Windows

Uwaga

Element Agent.Diagnostic ma automatycznie ustawianą wartość true, gdy element System.Debug ma ustawioną wartość true.

Zmienne Agent.Diagnostic i dzienniki opisane w tej sekcji są dostępne w wersji 2.200.0 i nowszych.

Aby uzyskać więcej informacji, zobacz rozwiązywanie problemów z agentem w repozytorium agenta open source agenta microsoft/azure-pipelines-agenta usługi Azure Pipelines.

Inne dzienniki

W dziennikach diagnostycznych znajdziesz environment.txt i capabilities.txt.

Plik environment.txt zawiera różne informacje o środowisku, w którym uruchomiono kompilację. Obejmuje to informacje, takie jak zadania, które są uruchamiane, czy zapora jest włączona, informacje o wersji programu PowerShell i niektóre inne elementy. Stale dodajemy te dane, aby uczynić je bardziej użytecznymi.

Plik capabilities.txt zapewnia czysty sposób na sprawdzenie wszystkich możliwości zainstalowanych na maszynie kompilacji, na którym uruchomiono kompilację.

Dzienniki śledzenia HTTP

Ważne

Ślady HTTP i pliki śledzenia mogą zawierać hasła i inne wpisy tajne. Nie publikuj ich w miejscach publicznych.

Korzystanie z wbudowanego śledzenia HTTP

Jeśli agent jest w wersji 2.114.0 lub nowszej, możesz śledzić nagłówki ruchu HTTP i zapisywać je w dzienniku diagnostycznym. Ustaw zmienną VSTS_AGENT_HTTPTRACE środowiskową przed uruchomieniem agent.listener.

Windows:
    set VSTS_AGENT_HTTPTRACE=true

macOS/Linux:
    export VSTS_AGENT_HTTPTRACE=true

Korzystanie z pełnego śledzenia HTTP — Windows

  1. Uruchom program Fiddler.

  2. Zalecamy nasłuchiwanie tylko ruchu agenta. Przechwytywanie ruchu plików > wyłączone (F12)

  3. Włącz odszyfrowywanie ruchu HTTPS. Karta Narzędzia > Fiddler Opcje > PROTOKOŁU HTTPS. Odszyfruj ruch HTTPS

  4. Poinformuj agenta o użyciu serwera proxy:

    set VSTS_HTTP_PROXY=http://127.0.0.1:8888

  5. Uruchom agenta interaktywnie. Jeśli używasz usługi jako usługi, możesz ustawić jako zmienną środowiskową w panelu sterowania dla konta, w którym działa usługa.

  6. Uruchom ponownie agenta.

Korzystanie z pełnego śledzenia HTTP — macOS i Linux

Użyj serwera proxy Charlesa (podobnego do programu Fiddler w systemie Windows), aby przechwycić ślad HTTP agenta.

  1. Uruchom serwer proxy Charles.

  2. Charles: serwer proxy > Ustawienia > karta SSL. Włącz. Dodaj adres URL.

  3. Charles: Serwer proxy systemu > Mac OSX. Zalecamy wyłączenie, aby wyświetlić tylko ruch agenta.

    export VSTS_HTTP_PROXY=http://127.0.0.1:8888

  4. Uruchom agenta interaktywnie. Jeśli jest ona uruchomiona jako usługa, możesz ją ustawić w pliku env. Zobacz nix service

  5. Uruchom ponownie agenta.

Przechwytywanie dzienników niestandardowych

Oprócz wbudowanych dzienników można używać zadań i skryptów do przechwytywania dzienników niestandardowych w potoku. W poniższych przykładach pokazano, jak przechwytywać wykorzystanie zasobów, ślady sieci, zrzuty pamięci i perfview ślady. Jeśli pracujesz z pomocą techniczną, może zostać wyświetlony monit o przechwycenie dzienników, takich jak te.

Pobieranie dzienników niestandardowych

Po przechwyceniu niestandardowego dziennika w potoku należy go przekazać, aby można było go pobrać do przeglądu. Dziennik niestandardowy można przekazać w ramach standardowych dzienników potoku lub przekazać go jako artefakt. Przykłady w poniższych sekcjach przedstawiają oba sposoby przekazywania dzienników niestandardowych.

Przekazywanie dziennika w ramach standardowych dzienników

Aby przekazać dziennik niestandardowy w ramach standardowych dzienników potoku, użyj polecenia ##vso[task.uploadfile] , aby przekazać żądany plik. Aby użyć tego polecenia, określ go jako część polecenia skryptu, jak pokazano w poniższym przykładzie. Plik można pobrać i wyświetlić jako część standardowych dzienników potoku. Metoda ##vso[task.uploadfile] jest dobra do przekazywania pojedynczego pliku dziennika. Jeśli masz więcej niż jeden plik dziennika, musisz użyć oddzielnego ##vso[task.uploadfile] wiersza dla każdego pliku.

- pwsh: Write-Host "##vso[task.uploadfile]$(Agent.TempDirectory)\resource-usage.txt"

Aby uzyskać więcej informacji, zobacz Polecenia rejestrowania i UploadFile: Przekazywanie pliku, który można pobrać z dziennikami zadań.

Przekazywanie dziennika jako artefaktu potoku

Aby przekazać dziennik niestandardowy jako artefakt potoku, użyj zadania PublishPipelineArtifact@1 . PublishPipelineArtifact@1 może przekazać jeden plik lub pliki w ścieżce katalogu i jest przydatny, jeśli masz wiele niestandardowych plików dziennika do przekazania.

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Pipeline.Workspace)/s/trace'
    artifact: 'file_result.pcap'
    publishLocation: 'pipeline'

Aby uzyskać więcej informacji, zobacz Publikowanie artefaktów potoku.

Szczegóły wykorzystania zasobów przechwytywania

W przypadku korzystania z usług Azure DevOps Services można wyświetlić wykorzystanie zasobów w dziennikach, w tym użycie dysku, użycie pamięci i użycie procesora CPU, włączając pełne dzienniki. Po zakończeniu potoku wyszukaj wpisy w Agent environment resources dziennikach dla każdego kroku.

2024-02-28T17:41:15.1315148Z ##[debug]Agent environment resources - Disk: D:\ Available 12342.00 MB out of 14333.00 MB, Memory: Used 1907.00 MB out of 7167.00 MB, CPU: Usage 17.23%

Jeśli używasz usługi Azure DevOps Server lub chcesz zebrać dodatkowe metryki, możesz użyć programu PowerShell do przechwytywania wykorzystania zasobów i przekazywania go do dzienników potoku. Po zakończeniu przebiegu potoku można pobrać dzienniki potoku i wyświetlić przechwycone dane. Upload resource usage from pipeline run Jeśli krok jest szóstym krokiem zadania, nazwa pliku w dziennikach będzie 6_resource-usage.txt.

# Place this task in your pipeline to log the current resource utilization
# of the pipeline. This task appends the specified resource usage to a logfile
# which is uploaded at the end of the current pipeline job.
- pwsh: |
      $logFile = '$(Agent.TempDirectory)\resource-usage.txt'
      if (!(Test-Path $logFile))
      {
        New-Item $logFile
      }
      Get-Date | Out-File -FilePath $logFile -Append
      Get-Volume | Out-File -FilePath $logFile -Append
      Get-Counter '\Memory\Available MBytes' | Out-File -FilePath $logFile -Append
      Get-Counter '\Processor(_Total)\% Processor Time' | Out-File -FilePath $logFile -Append
      sleep 10
  displayName: 'Check resource utilization'

# Other tasks here, and you can repeat the "Check resource utilization"
# step if desired, and the results will be appended to the resource-usage.txt file

- pwsh: Write-Host "##vso[task.uploadfile]$(Agent.TempDirectory)\resource-usage.txt"
  displayName: 'Upload resource usage from pipeline run'
  condition: always()

Przechwytywanie zrzutu pamięci procesu dotnet przy użyciu narzędzia ProcDump

Jeśli masz wykonanie testu, które ulega awarii, dział pomocy technicznej klienta może poprosić o przechwycenie zrzutu pamięci procesu dotnet po nieudanym wykonaniu testu. Dodaj następujące zadanie po zadaniu testowym programu Visual Studio za pomocą polecenia condition: always(). Po zakończeniu przebiegu potoku można pobrać dzienniki potoku, w tym zrzut pamięci.

# Run this task after your test execution crashes
# with a condition of alway() so that it always runs
- pwsh: |
    Invoke-WebRequest https://download.sysinternals.com/files/Procdump.zip -OutFile $(Agent.TempDirectory)\Procdump.zip
    mkdir $(Agent.TempDirectory)\Procdump
    unzip $(Agent.TempDirectory)\Procdump.zip -d Procdump
    cd $(Agent.TempDirectory)\Procdump
    Get-Process dotnet | % { $(Agent.TempDirectory)\procdump.exe -accepteula -ma $_.Id dotnet-$($_.Id).dmp }
    Compress-Archive *.dmp -DestinationPath $(Agent.TempDirectory)\dump_files.zip
    Write-Host "##vso[task.uploadfile]$(Agent.TempDirectory)\dump_files.zip"
  condition: always()
  displayName: 'Create and upload a dotnet process memory dump'

Przechwytywanie śladów ETW dla hostowanego agenta

Jeśli rozwiązujesz problemy z siecią agentów hostowanych przez firmę Microsoft, dział pomocy technicznej klienta może poprosić Cię o zebranie śladów ETW. Po zakończeniu przebiegu potoku można pobrać dzienniki potoku, w tym ślady ETW.

# Add this task to start the ETW trace
- script: netsh trace start scenario=InternetClient capture=yes tracefile=$(Agent.TempDirectory)\networktrace.etl
  displayName: 'Start ETW trace'

# Other tasks here

# Add these 2 tasks to stop the trace and upload
# the trace to the pipeline logs
- script: netsh trace stop
  displayName: 'Stop ETW trace'

- pwsh: |
    Write-Host "##vso[task.uploadfile]$(Agent.TempDirectory)\networktrace.etl"
    Write-Host "##vso[task.uploadfile]$(Agent.TempDirectory)\networktrace.cab"
  displayName: 'Upload ETW trace logs'

Przechwytywanie perfview śladów kompilacji programu Visual Studio

Jeśli dział pomocy technicznej klienta poprosi o utworzenie perfview śladu kompilacji programu Visual Studio, przed i po kroku kompilacji programu Visual Studio dodaj następujące zadania do potoku.

Po uruchomieniu potoku możesz pobrać artefakt PerfViewLog ze szczegółów przebiegu potoku i wysłać ten plik do działu obsługi klienta.

steps:
- task: PowerShell@2 # download the perfview exe
  inputs:
    targetType: 'inline'
    script: |
      invoke-webrequest https://github.com/microsoft/perfview/releases/download/v3.1.7/PerfView.exe -OutFile PerfView.exe

- task: PowerShell@2
  inputs:
    targetType: 'inline' # start perfview to capture the traces before build build task
    script: '$(System.DefaultWorkingDirectory)\PerfView.exe "/DataFile:PerfViewData.etl" /accepteula /BufferSizeMB:512 /StackCompression /CircularMB:5000 /Providers:"Microsoft-Windows-IIS" /logfile:"PerfView.log" /zip:true /norundown start'

- task: VSBuild@1
  displayName: '$(solution)' # build of the solution, note the msbuildargs might be different for your scenario
  inputs:
    solution: '$(solution)'
    clean: true
    msbuildArgs: '/p:DeployOnBuild=true /p:PrecompileBeforePublish=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(Build.ArtifactStagingDirectory)" /p:TransformWebConfigEnabled=false /p:AutoParameterizationWebConfigConnectionStrings=false /p:MarkWebConfigAssistFilesAsExclude=false /p:ProfileTransformWebConfigEnabled=false /p:IsTransformWebConfigDisabled=true'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: PowerShell@2 # stop the perfview tracing
  inputs:
    targetType: 'inline' 
    script: |
      $(System.DefaultWorkingDirectory)\perfview.exe /accepteula /logfile:"PerfView.log" stop

- task: PowerShell@2 # abort perfview, it seems required.
  inputs:
    targetType: 'inline'
    script: '$(System.DefaultWorkingDirectory)\perfview.exe /accepteula /logfile:"PerfView.log" abort'

- task: PowerShell@2 # add a sleep of 5 mins, to givet time for required for traces to be complete
  inputs:
    targetType: 'inline'
    script: 'Start-Sleep -Seconds 300'

- task: PublishPipelineArtifact@1 # upload the traces
  displayName: 'Publish Pipeline Artifact'
  inputs:
    artifactName: webapp