Partager via

Collecter les diagnostics dans les conteneurs

  • Article

Les mêmes outils de diagnostic qui sont utiles pour diagnostiquer les problèmes .NET dans d'autres scénarios fonctionnent également dans les conteneurs Docker. Toutefois, certains outils nécessitent des étapes spéciales pour fonctionner dans un conteneur. Cet article explique comment les outils de collecte de traces de performances et de collecte des images mémoires peuvent être utilisés dans les conteneurs Docker.

Utiliser les outils CLI .NET dans un conteneur

Ces outils s’appliquent à : ✔️ SDK .NET Core 3.1 et versions ultérieures

Les outils de diagnostic CLI globaux .NET (dotnet-counters, dotnet-dump, dotnet-gcdump, dotnet-monitor et dotnet-trace) sont conçus pour fonctionner dans une grande variété d'environnements et devraient tous fonctionner directement dans les conteneurs Docker. Pour cette raison, ces outils sont la méthode préférée pour collecter des informations de diagnostic pour les scénarios .NET ciblant .NET Core 3.1 ou une version ultérieure dans les conteneurs.

Vous pouvez également installer ces outils sans le SDK .NET en téléchargeant les variantes de fichier unique à partir des liens du paragraphe précédent. Ces installations nécessitent une installation globale du runtime .NET version 3.1 ou ultérieure, que vous pouvez acquérir en suivant l’une des méthodes prescrites dans la documentation d’installation de .NET ou en consommant l’un des conteneurs d’exécution officiels.

Utiliser les outils CLI globaux .NET dans un conteneur sidecar

Si vous souhaitez utiliser les outils de diagnostic CLI globaux .NET pour diagnostiquer des processus dans un conteneur différent, gardez à l'esprit les exigences supplémentaires suivantes :

  1. Les conteneurs doivent partager un espace de noms de processus (afin que les outils du conteneur side-car puissent accéder aux processus dans le conteneur cible).
  2. Les outils de diagnostic CLI globaux .NET ont besoin d'accéder aux fichiers que le runtime .NET écrit dans le répertoire /tmp, de sorte que le répertoire /tmp doit être partagé entre le conteneur cible et le conteneur sidecar par le biais d'un montage de volume. Par exemple, les conteneurs peuvent partager un volume commun ou un volumeKubernetes emptyDir pour réaliser ceci. Si vous essayez d’utiliser les outils de diagnostic à partir d’un conteneur side-car sans partager le répertoire /tmp, vous obtenez une erreur concernant le processus « runtime .NET compatible non exécuté ».

Utiliser PerfCollect dans un conteneur

Cet article s’applique à : ✔️ SDK .NET Core 2.1 et versions ultérieures

Le script PerfCollect est utile pour collecter des traces de performances et c’est l’outil recommandé pour collecter les traces antérieures à .NET Core 3.0. Si vous utilisez PerfCollect dans un conteneur, gardez à l’esprit les exigences suivantes :

  • PerfCollect nécessite des capacités supplémentaires pour exécuter l’outil perf. L’ensemble minimal de capacités nécessaire est PERFMON et SYS_PTRACE. Certains environnements nécessitent SYS_ADMIN. Veillez à démarrer le conteneur avec les capacités nécessaires. Si l’ensemble minimal ne fonctionne pas, essayez avec l’ensemble complet.

  • PerfCollect nécessite que certaines variables d'environnement soient définies avant le démarrage de l'application qu'il profile. Ces paramètres peuvent être définis dans un fichier Docker ou lorsque vous démarrez le conteneur. Étant donné que ces variables ne doivent pas être définies dans des environnements de production normaux, il est courant de les ajouter lors du démarrage d’un conteneur qui sera profilé. Les deux variables requises par PerfCollect sont :

    • DOTNET_PerfMapEnabled=1
    • DOTNET_EnableEventLog=1

Notes

Lors de l’exécution de l’application avec .NET 7, vous devez également définir DOTNET_EnableWriteXorExecute=0 en plus des variables d’environnement précédentes.

Notes

.NET 6 se normalise sur le préfixe DOTNET_ au lieu de COMPlus_ pour les variables d’environnement qui configurent le comportement au moment de l’exécution de .NET. Toutefois, le préfixe COMPlus_ continuera à fonctionner. Si vous utilisez une version précédente du runtime .NET, vous devez tout de même utiliser le préfixe COMPlus_.

Utiliser PerfCollect dans un conteneur sidecar

Si vous voulez exécuter PerfCollect dans un conteneur pour profiler un processus .NET dans un autre conteneur, l'expérience est presque la même. Les différences sont les suivantes :

  • Les variables d’environnement mentionnées précédemment (DOTNET_PerfMapEnabled et DOTNET_EnableEventLog) doivent être définies pour le conteneur cible (et non celui qui exécute PerfCollect).
  • Le conteneur en cours d’exécution PerfCollect doit avoir la capacité SYS_ADMIN (et non le conteneur cible).
  • Les deux conteneurs doivent partager un espace de noms de processus.