Dela via

Samla in diagnostik i containrar

  • Artikel

Samma diagnostikverktyg som är användbara för att diagnostisera .NET Core-problem i andra scenarier fungerar också i Docker-containrar. Vissa av verktygen kräver dock särskilda steg för att fungera i en container. Den här artikeln beskriver hur verktyg för att samla in prestandaspårningar och samla in dumpar kan användas i Docker-containrar.

Använda .NET CLI-verktyg i en container

Dessa verktyg gäller för: ✔️ .NET Core 3.1 SDK och senare versioner

De globala CLI-diagnostikverktygen för .NET Core (dotnet-counters, dotnet-dump, dotnet-gcdump, dotnet-monitor och dotnet-trace) är utformade för att fungera i en mängd olika miljöer och bör alla fungera direkt i Docker-containrar. Därför är dessa verktyg den bästa metoden för att samla in diagnostikinformation för .NET Core-scenarier som riktar sig till .NET Core 3.1 eller senare i containrar.

Du kan också installera dessa verktyg utan .NET SDK genom att ladda ned enfilvarianterna från länkarna i föregående stycke. Dessa installationer kräver en global installation av .NET Runtime version 3.1 eller senare, som du kan hämta genom att följa någon av de föreskrivna metoderna i installationsdokumentationen för .NET eller genom att använda någon av de officiella runtime-containrarna.

Använda .NET Core globala CLI-verktyg i en sidovagnscontainer

Om du vill använda .NET Cores globala CLI-diagnostikverktyg för att diagnostisera processer i en annan container bör du ha följande ytterligare krav i åtanke:

  1. Containrarna måste dela ett processnamnområde (så att verktygen i sidovagnscontainern kan komma åt processer i målcontainern).
  2. De globala CLI-diagnostikverktygen för .NET Core behöver åtkomst till filer som .NET Core-runtime skriver till katalogen /tmp, så katalogen /tmp måste delas mellan mål- och sidovagnscontainern via en volymmontering. Detta kan till exempel göras genom att containrarna delar en gemensam volym eller en Kubernetes emptyDir-volym . Om du försöker använda diagnostikverktygen från en sidovagnscontainer utan att dela katalogen /tmp får du ett felmeddelande om att processen "inte kör kompatibel .NET-körning".

Använda PerfCollect i en container

Det här verktyget gäller för: ✔️ .NET Core 2.1 och senare versioner

Skriptet PerfCollect är användbart för att samla in prestandaspårningar och är det rekommenderade verktyget för att samla in spårningar före .NET Core 3.0. Tänk på följande om du använder PerfCollect i en container:

  • PerfCollect kräver ytterligare funktioner för att köra perf verktyget. Den minimala uppsättning funktioner som krävs är PERFMON och SYS_PTRACE. Vissa miljöer kräver SYS_ADMIN. Se till att starta containern med nödvändiga funktioner. Om den minimala uppsättningen inte fungerar kan du prova med den fullständiga uppsättningen.

  • PerfCollect kräver att vissa miljövariabler anges innan profileringen startas. Dessa kan anges antingen i en Dockerfile eller när du startar containern. Eftersom dessa variabler inte ska anges i normala produktionsmiljöer är det vanligt att bara lägga till dem när du startar en container som ska profileras. De två variabler som Krävs för PerfCollect är:

    • DOTNET_PerfMapEnabled=1
    • DOTNET_EnableEventLog=1

Kommentar

När du kör appen med .NET 7 måste du också ange DOTNET_EnableWriteXorExecute=0 utöver föregående miljövariabler.

Kommentar

.NET 6 standardiserar på prefixet DOTNET_ i stället COMPlus_ för för miljövariabler som konfigurerar .NET-körningsbeteende. Prefixet COMPlus_ fortsätter dock att fungera. Om du använder en tidigare version av .NET-körningen bör du fortfarande använda prefixet COMPlus_ för miljövariabler.

Använda PerfCollect i en sidovagnscontainer

Om du vill köra PerfCollect i en container för att profilera en .NET Core-process i en annan container är upplevelsen nästan densamma förutom dessa skillnader:

  • Miljövariablerna som nämnts tidigare (DOTNET_PerfMapEnabled och DOTNET_EnableEventLog) måste anges för målcontainern (inte den som kör PerfCollect).
  • Containern som körs PerfCollect måste ha SYS_ADMIN funktionen (inte målcontainern).
  • De två containrarna måste dela ett processnamnområde.