Raccogliere i dati di diagnostica in contenitori

Gli stessi strumenti di diagnostica utili per la diagnosi dei problemi di .NET Core in altri scenari funzionano anche nei contenitori Docker. Tuttavia, alcuni degli strumenti richiedono passaggi speciali per funzionare in un contenitore. Questo articolo illustra come usare gli strumenti per raccogliere tracce delle prestazioni e dump nei contenitori Docker.

Uso degli 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

Gli strumenti di diagnostica dell'interfaccia della riga di comando globali di .NET Core (dotnet-counters, dotnet-dump, dotnet-gcdump, dotnet-monitor e dotnet-trace) sono progettati per funzionare in un'ampia gamma di ambienti e dovrebbero tutti funzionare direttamente nei contenitori Docker. Per questo motivo, questi strumenti sono il metodo preferito per raccogliere informazioni di diagnostica per gli scenari .NET Core destinati a .NET Core 3.1 o versioni successive nei contenitori.

È anche possibile installare questi strumenti senza .NET SDK scaricando le varianti a file singolo dai collegamenti nel paragrafo precedente. Queste installazioni richiedono un'installazione globale del runtime .NET versione 3.1 o successiva, che è possibile acquisire seguendo uno dei metodi indicati nella documentazione di installazione di .NET o usando uno dei contenitori di runtime ufficiali.

Uso degli strumenti dell'interfaccia della riga di comando globali di .NET Core in un contenitore sidecar

Per usare gli strumenti di diagnostica dell'interfaccia della riga di comando globali di .NET Core per diagnosticare i processi in un contenitore diverso, tenere presenti i requisiti aggiuntivi seguenti:

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 di diagnostica dell'interfaccia della riga di comando globali di .NET Core devono accedere ai file che il runtime di .NET Core scrive nella directory /tmp, pertanto la directory /tmp deve essere condivisa tra il contenitore di destinazione e sidecar 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 che indica che il processo non esegue un runtime .NET compatibile.

Uso di PerfCollect in un contenitore

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

Lo script PerfCollect è utile per raccogliere tracce delle prestazioni ed è lo strumento consigliato per la raccolta di tracce prima di .NET Core 3.0. 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 che alcune variabili di ambiente vengano impostate prima dell'avvio della profilatura dell'app. Queste variabili possono essere impostate 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.

Uso di PerfCollect in un contenitore sidecar

Se si vuole eseguire PerfCollect in un contenitore per profilare un processo .NET Core in un contenitore diverso, l'esperienza è quasi identica ad eccezione di queste differenze:

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