Dela via

Samla in diagnostik i Linux-containrar

Samma diagnostikverktyg som är användbara för att diagnostisera .NET-problem i andra scenarier fungerar också i containrar. Verktygen kan köras i samma container som målprocessen, från värddatorn eller från en sidecar-container.

Använda .NET CLI-verktyg i en container

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

Alla dotnet-* CLI-diagnostikverktyg kan fungera när de körs i samma container som programmet som de inspekterar, men se upp för dessa potentiella felsökningspunkter:

  • Verktyg som körs i en container omfattas av resursbegränsningar för containrar. Verktygen kan köras långsamt eller misslyckas om resursgränserna är för låga. De flesta av verktygen har blygsamma krav men dotnet-dumpdotnet-gcdump kan använda mycket minne och diskutrymme när du riktar in dig på en process som har ett stort minnesfotavtryck. dotnet-trace och dotnet-counters kan också skapa stora filer om de är konfigurerade för att samla in en stor mängd spårningshändelser eller tidsseriedata för mått.
  • dotnet-dump gör att en hjälpprocess körs som behöver ptrace-behörigheter. Linux har många alternativ för säkerhetskonfiguration som kan påverka om detta lyckas, så i vissa fall kan du behöva justera containerns säkerhetskonfiguration. Mer information om hur du diagnostiserar säkerhetsbehörigheter finns i vanliga frågor och svar om dumpning .
  • När du kör verktyg i containern kan du antingen installera dem i förväg när du skapar containern eller laddar ned dem på begäran. Att installera dem i förväg gör det enklare när du behöver dem, men ökar containerns storlek och skapar en större attackyta som skadliga aktörer kan försöka utnyttja.

Använda .NET CLI-verktyg i en sidovagnscontainer eller från värden

dotnet-* CLI diagnostikverktyg stöder även att köras från hosten eller i en sidovagnscontainer. Detta undviker till stor del storleks-, säkerhets- och resursbegränsningarna för körning i samma container, men har vissa ytterligare krav för att verktygen ska kunna kommunicera korrekt.

När du identifierar en målprocess som ska inspekteras med kommandoradsargumenten --process-id eller --name verktyget kräver detta:

  1. Containrarna måste dela ett processnamnområde så att verktygen i sidovagnscontainern kan komma åt processer i målcontainern.
  2. Verktygen behöver åtkomst till diagnostikporten Unix Domain Socket som .NET-runtime skriver till katalogen /tmp, så katalogen /tmp måste delas mellan mål- och sidecar-containern 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".

Om du inte vill dela processnamnområdet och katalogen /tmp stöder många av verktygen också ett mer avancerat --diagnostic-port kommandoradsalternativ. På så sätt kan du direkt ange sökvägen till målprocessens diagnostikport i filsystemet på värden eller sidovagnen. Målcontainerns /tmp-katalog måste mappas till någonstans för att den här sökvägen ska finnas, men den behöver inte delas med värden eller sidecar /tmp.

Anteckning

Även när du använder diagnostikverktygen från värden eller sidovagnen kan målprocessen fortfarande ombes att utföra arbete som ökar resursanvändningen inom målcontainern. Vi har observerat att dotnet-dump kan leda till att stora mängder virtuellt minne laddas in av målprocessen vid insamling av en dump. Andra verktyg kan orsaka mindre påverkan även om vi inte har sett dessa orsaka problem i praktiken. Till exempel dotnet-trace begär målprocessen att allokera en händelsebuffert och dotnet-counters begär en liten minnesregion där måttdata aggregeras. Vi rekommenderar att du testar för att säkerställa att minnesgränserna inte är så snäva att de orsakar operativsystemet att avsluta containrarna när verktygen körs.

Anteckning

När dotnet-dump skriver en dumpfil till disk tolkas utmatningssökvägen i kontexten för målprocessens vy över filsystemet. Detta kan skilja sig från värd- eller sidovagnscontainern.

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 som innehåller kernelhändelser, till exempel CPU-exempel eller kontextväxlar. 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 appen som den profilerar startar. 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

Anteckning

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

Anteckning

.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-process i en annan container är upplevelsen nästan densamma. Skillnaderna är:

  • 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.