Partager via

Collecter les diagnostics dans les conteneurs

  • Article

Les mêmes outils de diagnostic qui sont utiles pour diagnostiquer les problèmes .NET Core 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.

Utilisation des outils CLI .NET dans un conteneur

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

Les outils de diagnostic globaux CLI .NET Core (dotnet-counters, dotnet-dump, dotnet-gcdump, dotnet-monitor et dotnet-trace) sont conçus pour fonctionner dans des environnements très divers et doivent tous fonctionner directement dans des conteneurs Docker. Pour cette raison, ces outils sont la méthode privilégiée pour collecter des informations de diagnostic pour les scénarios .NET Core ciblant .NET Core 3.1 ou 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.

Utilisation des outils CLI globaux .NET Core dans un conteneur side-car

Si vous souhaitez utiliser les outils de diagnostic CLI globaux .NET Core pour diagnostiquer les processus dans un autre conteneur, 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 Core ont besoin d’accéder aux fichiers que le runtime .NET Core écrit dans le répertoire /tmp. Le répertoire /tmp doit donc être partagé entre le conteneur cible et le conteneur side-car via 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é ».

Utilisation de l’outil 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 dont elle effectue le profilage. Celles-ci peuvent être définies dans un fichier Dockerfile ou lors du démarrage du 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_.

Utilisation de PerfCollect dans un conteneur side-car

Si vous souhaitez exécuter PerfCollect dans un conteneur pour profiler un processus .NET Core dans un autre conteneur, l’expérience est presque la même, sauf pour les différences 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.