Condividi tramite


Raccogliere i dati diagnostici nei container Linux

Gli stessi strumenti di diagnostica utili per la diagnosi dei problemi .NET in altri scenari funzionano anche nei contenitori. Gli strumenti possono essere eseguiti nello stesso contenitore del processo di destinazione, dall'host o da un contenitore sidecar.

Usare gli strumenti dell'interfaccia della riga di comando di .NET in un contenitore

Questi strumenti si applicano a: ✔️ .NET Core 3.1 SDK e versioni successive

Tutti gli strumenti di diagnostica dell'interfaccia della riga di comando dotnet-* possono funzionare quando vengono eseguiti all'interno dello stesso contenitore dell'applicazione che stanno esaminando, ma attenzione a questi potenziali problemi:

  • Gli strumenti eseguiti all'interno di un contenitore saranno soggetti ai limiti delle risorse del contenitore. Gli strumenti possono essere eseguiti lentamente o hanno esito negativo se i limiti delle risorse sono troppo bassi. La maggior parte degli strumenti ha requisiti contenuti, ma dotnet-dump e dotnet-gcdump possono usare una notevole quantità di memoria e spazio su disco quando si applicano a un processo con un footprint di memoria elevato. dotnet-trace e dotnet-counters possono anche creare file di grandi dimensioni se sono configurati per acquisire una grande quantità di eventi di traccia o dati delle serie temporali delle metriche.
  • dotnet-dump causerà l'esecuzione di un processo helper che richiede autorizzazioni ptrace. Linux offre numerose opzioni di configurazione della sicurezza che possono influire sulla corretta esecuzione di questa operazione, in alcuni casi potrebbe essere necessario modificare la configurazione di sicurezza del contenitore. Per altre indicazioni sulla diagnosi dei privilegi di sicurezza, vedere le domande frequenti sul dump .
  • Quando si eseguono strumenti all'interno del contenitore, è possibile installarli in anticipo durante la compilazione del contenitore o scaricarli su richiesta. L'installazione in anticipo rende più semplice quando sono necessari, ma aumenta le dimensioni del contenitore e crea una superficie di attacco più grande che gli attori malintenzionati potrebbero tentare di sfruttare.

Usare gli strumenti CLI di .NET in un contenitore sidecar o da host

Gli strumenti di diagnostica dell'interfaccia della riga di comando dotnet-* supportano anche l'esecuzione dall'host o in un contenitore sidecar. Ciò evita in gran parte le dimensioni, la sicurezza e le limitazioni delle risorse di esecuzione nello stesso contenitore, ma presenta alcuni requisiti aggiuntivi per consentire agli strumenti di comunicare correttamente.

Quando si identifica un processo bersaglio da controllare usando gli argomenti della riga di comando dello strumento --process-id o --name, è necessario:

  1. I contenitori devono condividere uno spazio dei nomi dei processi in modo che gli strumenti nel contenitore sidecar possano accedere ai processi nel contenitore di destinazione.
  2. Gli strumenti devono accedere al socket di dominio Unix della porta di diagnostica che il runtime .NET scrive nella directory /tmp, quindi la directory /tmp deve essere condivisa tra il contenitore di destinazione e il sidecar container tramite un montaggio del volume. A tale scopo, ad esempio, è possibile fare in modo che i contenitori condividano un volume comune o un volume emptyDir Kubernetes. Se si tenta di usare gli strumenti di diagnostica da un contenitore sidecar senza condividere la directory /tmp , verrà visualizzato un errore relativo al processo "non in esecuzione di runtime .NET compatibile".

Se non si vuole condividere lo spazio dei nomi del processo e la directory /tmp , molti degli strumenti supportano anche un'opzione della riga di comando più avanzata --diagnostic-port . In questo modo è possibile specificare direttamente il percorso della porta diagnostica del processo di destinazione all'interno del filesystem dell'host o del sidecar. La directory /tmp del contenitore di destinazione deve essere mappata in un luogo affinché questo percorso esista, ma non deve essere condivisa con l'host o il sidecar /tmp.

Nota

Anche quando si eseguono gli strumenti di diagnostica dall'host o dal sidecar, può comunque essere richiesto al processo di destinazione di svolgere operazioni che aumentano l'uso delle risorse all'interno del contenitore di destinazione. È stato osservato che dotnet-dump può causare il caricamento di una grande quantità di memoria virtuale nel processo di destinazione durante la raccolta di un dump. Altri strumenti possono causare effetti più piccoli anche se non abbiamo visto questi problemi in pratica. Ad esempio, dotnet-trace richiede al processo di destinazione di allocare un buffer eventi e dotnet-counters richiede un'area di memoria di piccole dimensioni in cui vengono aggregati i dati delle metriche. È consigliabile testare per assicurarsi che i limiti di memoria non siano così limitati che l'esecuzione degli strumenti causi l'interruzione dei contenitori da parte del sistema operativo.

Nota

Quando dotnet-dump scrive un file dump su disco, il percorso di output viene interpretato nel contesto della visualizzazione del processo di destinazione del file system. Questo può differire dal contenitore host o dal contenitore di sidecar.

Utilizzare PerfCollect in un contenitore

Questo strumento si applica a: ✔️ .NET Core 2.1 e versioni successive

Lo PerfCollect script è utile per raccogliere tracce delle prestazioni che contengono eventi del kernel, ad esempio esempi di CPU o commutatori di contesto. Se si usa PerfCollect in un contenitore, tenere presenti i requisiti seguenti:

  • PerfCollect richiede funzionalità aggiuntive per eseguire lo strumento perf. Il set minimo di funzionalità necessarie è PERFMON e SYS_PTRACE. Alcuni ambienti richiedono SYS_ADMIN. Assicurarsi di avviare il contenitore con le funzionalità necessarie. Se il set minimo non funziona, provare con il set completo.

  • PerfCollect Richiede l'impostazione di alcune variabili di ambiente prima dell'avvio dell'app che sta profilando. Questi possono essere impostati in un Dockerfile o all'avvio del contenitore. Poiché queste variabili non devono essere impostate in ambienti di produzione normali, è comune aggiungerle solo all'avvio di un contenitore che verrà profilato. Le due variabili richieste da PerfCollect sono:

    • DOTNET_PerfMapEnabled=1
    • DOTNET_EnableEventLog=1

Nota

Quando si esegue l'app con .NET 7, è anche necessario impostare DOTNET_EnableWriteXorExecute=0 oltre alle variabili di ambiente precedenti.

Nota

.NET 6 standardizza il prefisso DOTNET_ anziché quello di COMPlus_ per le variabili di ambiente che configurano il comportamento in fase di esecuzione di .NET. Tuttavia, il prefisso diCOMPlus_ continuerà a funzionare. Se si usa una versione precedente del runtime .NET, è comunque consigliabile usare il prefisso COMPlus_ per le variabili di ambiente.

Usare PerfCollect in un contenitore sidecar

Se si desidera eseguire PerfCollect in un contenitore per profilare un processo .NET in un contenitore diverso, l'esperienza è quasi la stessa. Le differenze sono le seguenti:

  • Le variabili di ambiente indicate in precedenza (DOTNET_PerfMapEnabled e DOTNET_EnableEventLog) devono essere impostate per il contenitore di destinazione (non quello che esegue PerfCollect).
  • Il contenitore che esegue PerfCollect deve avere la funzionalità SYS_ADMIN (non il contenitore di destinazione).
  • I due contenitori devono condividere uno spazio dei nomi dei processi.