Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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
edotnet-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
edotnet-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:
- 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.
- 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 strumentoperf
. Il set minimo di funzionalità necessarie èPERFMON
eSYS_PTRACE
. Alcuni ambienti richiedonoSYS_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
eDOTNET_EnableEventLog
) devono essere impostate per il contenitore di destinazione (non quello che eseguePerfCollect
). - 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.