Collecter des diagnostics dans des conteneurs Linux

Les mêmes outils de diagnostic qui sont utiles pour diagnostiquer les problèmes .NET dans d’autres scénarios fonctionnent également dans des conteneurs. Ces outils peuvent être exécutés dans le même conteneur que le processus cible, à partir de l'hôte ou d'un conteneur sidecar.

Utiliser les outils CLI .NET dans un conteneur

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

Tous les outils de diagnostic cli dotnet-* peuvent fonctionner quand ils s’exécutent dans le même conteneur que l’application qu’ils inspectent, mais attention à ces points de problèmes potentiels :

• Les outils exécutés dans un conteneur sont soumis aux limites de ressources du conteneur. Les outils peuvent s’exécuter lentement ou échouer si les limites de ressources sont trop faibles. La plupart des outils ont des exigences modestes, mais dotnet-dump peuvent utiliser un espace mémoire et dotnet-gcdump disque considérable lors du ciblage d’un processus ayant une grande empreinte mémoire. dotnet-trace et dotnet-counters peut également créer des fichiers volumineux s’ils sont configurés pour capturer une grande quantité d’événements de trace ou de données de série chronologique de métrique.
• dotnet-dump entraîne l’exécution d’un processus d’assistance qui nécessite des autorisations ptrace. Linux dispose de nombreuses options de configuration de sécurité qui peuvent affecter si cela réussit. Dans certains cas, vous devrez peut-être ajuster la configuration de sécurité du conteneur. Veuillez consulter la FAQ sur les dumps pour plus d'informations sur le diagnostic des privilèges de sécurité.
• Lorsque vous exécutez des outils à l’intérieur du conteneur, vous pouvez les installer à l’avance lors de la génération du conteneur ou les télécharger à la demande. Les installer à l’avance facilite la tâche lorsque vous en avez besoin, mais augmente la taille du conteneur et crée une surface d’attaque plus grande que les acteurs malveillants pourraient tenter d’exploiter.

Utilisation des outils CLI .NET dans un conteneur sidecar ou à partir de l'hôte

Les outils de diagnostic CLI dotnet-* prennent également en charge l'exécution à partir de l'hôte ou dans un conteneur sidecar. Cela évite en grande partie la taille, la sécurité et les limitations des ressources de l’exécution dans le même conteneur, mais présente des exigences supplémentaires pour que les outils communiquent correctement.

Lors de l’identification d’un processus cible à inspecter à l’aide des arguments de --process-id ligne de commande ou --name d’outil, cela nécessite :

1. Les conteneurs doivent partager un espace de noms de processus afin que les outils du conteneur sidecar puissent accéder aux processus dans le conteneur cible.
2. Les outils doivent accéder au socket de domaine Unix du port de diagnostic que le runtime .NET écrit dans le répertoire /tmp. Le répertoire /tmp doit donc être partagé entre le conteneur cible et le conteneur sidecar via un montage de volume. Par exemple, ceci pourrait être réalisé en faisant partager aux conteneurs un volume commun ou un volume emptyDir de Kubernetes. Si vous tentez d’utiliser les outils de diagnostic à partir d’un conteneur sidecar sans partager le répertoire /tmp , vous obtenez une erreur concernant le processus « pas d’exécution du runtime .NET compatible ».

Si vous ne souhaitez pas partager l’espace de noms de processus et le répertoire /tmp , de nombreux outils prennent également en charge une option de ligne de commande plus avancée --diagnostic-port . Cela vous permet de spécifier directement le chemin d’accès au port de diagnostic du processus cible dans le système de fichiers de l’hôte ou du side-car. Le répertoire /tmp du conteneur cible doit être mappé quelque part pour que ce chemin existe, mais il n’a pas besoin d’être partagé avec l’hôte ou sidecar /tmp.

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 contenant des événements du noyau tels que des échantillons de processeur ou des changements de contexte. 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

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.