Sysdig: Qu'est-ce que c'est et comment l'utiliser

Sysdig est un outil de visibilité système universel avec prise en charge des conteneurs. Ce qui rend Sysdig spécial, c'est qu'il se connecte au noyau de la machine et sépare les informations par conteneur. Pour la portée de ce tutoriel, nous nous concentrerons sur la version open-source de Sysdig.

Dans les sections suivantes, vous allez:

  • Installer Sysdig
  • Faites tourner une installation Wordpress en utilisant Docker-compose
  • Utilisez Sysdig pour collecter des événements et les analyser ultérieurement
  • Utilisez Sysdig pour analyser les données en temps réel

Conditions préalables

  • Docker est installé sur votre système. Pour plus de détails sur l'installation de Docker, reportez-vous à la page Installer Docker.
  • Docker Compose est installé sur votre système. Reportez-vous à la page Installer Docker Compose pour savoir comment installer Docker Compose.
  • Les en-têtes du noyau sont installés sur le système hôte.

Installer Sysdig

Suivez ces étapes pour installer Sysdig à l'intérieur d'un conteneur Docker:

  1. Dans une fenêtre de terminal, exécutez la commande suivante pour extraire l'image Sysdig Docker:
docker pull sysdig / sysdig
Utilisation de la balise par défaut: le plus récent: Tirage depuis sysdig / sysdig 2967486b0658: Tirage complet 78101b780c72: Tirage complet 7e78b657334d: Tirage complet 650327159ca8: Tirage complet 47ebf73ab754: Tirage complet bf51ac76a6d9: Tirage complet 0cd11104dbf8f: Tirage complet Pull complet 6de86c8ed6e9: Pull complet 8d1825f8be4b: Pull complete Digest: sha256: bbfe6953fd2b3221a8974eb13024dd33c7e78aebef8fee3d7a0d9ecdeed84ce0 Statut: Image plus récente téléchargée pour sysdig / sysdig: dernier

2. Exécutez Sysdig dans un conteneur en entrant:

docker run -i -t --name sysdig --privileged -v /var/run/docker.sock:/host/var/run/docker.sock -v / dev: / host / dev -v / proc: / host / proc: ro -v / boot: / host / boot: ro -v / lib / modules: / host / lib / modules: ro -v / usr: / host / usr: ro sysdig / sysdig
* Configuration des liens / usr / src depuis l'hôte * Déchargement de la sonde sysdig, le cas échéant * Exécution de l'installation de dkms pour l'erreur sysdig! echo Vos en-têtes de noyau pour le noyau 3.10.0-957.12.2.el7.x86_64 sont introuvables dans /lib/modules/3.10.0-957.12.2.el7.x86_64/build ou /lib/modules/3.10.0-957.12 .2.el7.x86_64 / source. * L'exécution de la construction de dkms a échoué, impossible de trouver /var/lib/dkms/sysdig/0.26.4/build/make.log * Essayer de charger une sonde sysdig système, si elle est présente * Essayer de trouver une sonde sysdig précompilée pour 3.10 .0-957.12.2.el7.x86_64 Configuration du noyau trouvée dans /host/boot/config-3.10.0-957.12.2.el7.x86_64 * Essayer de télécharger le module précompilé à partir de https://s3.amazonaws.com/download .draios.com / stable / sysdig-probe-binaries / sysdig-probe-0.26.4-x86_64-3.10.0-957.12.2.el7.x86_64-82e2ae1fb159132636f7b50a762f20ef.ko Téléchargement réussi, chargement du module root @ 7b14a23f22eb: / #

Quelques points à noter sur la commande ci-dessus:

  • Le drapeau -i maintient STDIN ouvert.
  • Le paramètre --privileged permet d'accéder à tous les périphériques de l'hôte. Il définit également SELinux pour permettre aux processus exécutés à l'intérieur du conteneur le même accès à l'hôte qu'un processus s'exécutant sur l'hôte.
  • L'indicateur -v spécifie la liste des fichiers (sur l'hôte) auxquels Sysdig peut accéder.

Faire tourner une installation Wordpress

Dans cette section, vous allez installer Wordpress à l'aide de la commande docker-compose.

  1. Dans une nouvelle fenêtre de terminal, accédez au répertoire de vos projets et tapez les commandes suivantes:
mkdir wordpress-sysdig && cd wordpress-sysdig

2. Créez un fichier appelé docker-compose avec le contenu suivant:

version: '3.3' services: db: image: mysql: 5.7 volumes: - db_data: / var / lib / mysql restart: toujours environnement: MYSQL_ROOT_PASSWORD: somewordpress MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress wordpress: depend_on: - db image: wordpress: derniers ports: - "8000: 80" redémarrage: toujours environnement: WORDPRESS_DB_HOST: db: 3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress WORDPRESS_DB_NAME: volumes wordpress: db_data: {}

3. Exécutez la commande docker-compose up en mode détaché avec:

docker-compose up -d
Création du réseau "wordpress-sysdig_default" avec le pilote par défaut Création du volume "wordpress-sysdig_db_data" avec le pilote par défaut Extraction de wordpress (wordpress: dernier) ... dernier: Extraction de la bibliothèque / wordpress 8ec398bc0356: Extraction complète 85cf4fc86478: Extraction complète 970dadf4ccb6: Extraction complète 8c04561117a4: Pull complet d6b7434b63a2: Pull complet 83d8859e9744: Pull complet 9c3d824d0ad5: Pull complet 9e316fd5b3b3: Pull complet 578b40496c37: Pull complet 814ae7711d3c: Pull complet 4896fed78b6b: Pull complet e745266 Pull complet ecda5b7aad12: Pull complet 84256a6b6b44: Pull complet 35d4f385efb7: Pull complet bf697c2ae701: Pull complet d054b015f084: Pull complet Digest: sha256: 73e8d8adf491c7a358ff94c74c8ebe35cb8f8df appuyez sur_1 ... terminé

4. Vous pouvez vérifier l'état de vos conteneurs avec:

docker ps

Si tout se passe bien, vous devriez voir quelque chose de similaire à la sortie suivante:

NOM DES PORTS D'ÉTAT CRÉÉS PAR COMMANDE D'IMAGE ID CONTENANT f390eec29f52 wordpress: dernier "docker-entrypoint.s ..." Il y a environ une minute Jusqu'à Environ une minute 0.0.0.0:8000->80/tcp wordpress-sysdig_wordpress_1 a844840626d8 mysql: 5.7 "docker-entrypoint. s… "Il y a environ une minute Up Environ une minute 3306 / tcp, 33060 / tcp wordpress-sysdig_db_1 7b14a23f22eb sysdig / sysdig" /docker-entrypoint.… "Il y a 13 minutes Up 13 minutes sysdig

5. Maintenant, Wordpress est opérationnel. Pointez votre navigateur sur http: // localhost: 8000 pour démarrer l'assistant d'installation:

6. Une fois l'assistant d'installation terminé, allons-y et créons un exemple de message:

Collecte de données dans un fichier

Dans cette section, nous allons montrer comment vous pouvez utiliser Sysdig pour collecter des événements et les analyser ultérieurement.

  1. Pour vider tous les événements capturés dans un fichier, accédez au conteneur Sysdig et entrez la commande suivante:
sysdig -w monitoring-wordpress.scap

2. Dans une nouvelle fenêtre de terminal, utilisez ab pour effectuer 10000 requêtes avec un maximum de 100 requêtes s'exécutant simultanément:

ab -n 1000 -c 100 http: // localhost: 8000 /? p = 7
Il s'agit d'ApacheBench, version 2.3 <$ Revision: 1430300 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licencié à The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (soyez patient) 100 demandes terminées 200 demandes terminées 300 demandes terminées 400 demandes terminées 500 demandes terminées 600 demandes terminées 700 demandes terminées 800 demandes terminées 900 demandes terminées 1000 demandes terminées 1000 demandes terminées

Notez que la sortie ci-dessus a été tronquée par souci de concision.

3. Revenez en arrière pour visiter le conteneur Sysdig et arrêtez de capturer les données en entrant «CTRL + C».

Analyser les données

Maintenant, si vous regardez la taille du fichier monitoring-wordpress.scap, vous remarquerez que Sysdig a capturé pas moins de 80M de données:

ls -lh monitoring-wordpress.scap
-rw-r - r--. 1 racine root 80M 7 janvier 16:28 monitoring-wordpress.scap

Pour trouver votre chemin à travers cette montagne de données, vous allez utiliser quelque chose appelé un burin.

Un burin est essentiellement un script Lua qui analyse le flux d'événements et effectue des actions utiles.

Vous pouvez exécuter la commande suivante pour afficher la liste des burins:

sysdig -cl
Catégorie: Application --------------------- httplog Journal des requêtes HTTP httptop Top HTTP requêtes memcachelog memcached request log Catégorie: Utilisation du processeur ---------- --------- spectrogramme Visualisez la latence du système d'exploitation en temps réel. subsecoffset Visualisez le temps d'exécution du décalage d'une seconde. topcontainers_cpu Top conteneurs par utilisation CPU topprocs_cpu Top processus par utilisation CPU Catégorie: Erreurs ---------------- topcontainers_error Top conteneurs par nombre d'erreurs topfiles_errors Top fichiers par nombre d'erreurs topprocs_errors top processus par numéro des erreurs

Notez que la sortie ci-dessus a été tronquée par souci de concision.

Pour récupérer des informations détaillées sur un burin, exécutez la commande sysdig suivie de l'indicateur -i et du nom du burin, comme dans l'exemple suivant:

sysdig -i httptop
Catégorie: Application --------------------- httptop Principales demandes HTTP Afficher les principales demandes HTTP par: ncalls, heure ou octets Args: [chaîne] par - Afficher les principales transactions HTTP par: ncalls, heure ou par tes, la valeur par défaut est ncalls

Poursuivant notre exemple, voici comment vous pouvez utiliser le burin httptop pour afficher les principales requêtes HTTP:

sysdig -r monitoring-wordpress.scap -c httptop
URL de la méthode ncalls ----------------------------------------------- --------------------------------- 2001 GET localhost: 8000 /? P = 7 14 OPTIONS * 2 GET localhost: 8000 / favicon.ico 1 GET /wp-content/themes/twentytwenty/assets/fonts/inter/Inter-upright-var.woff2 1 GET localhost / v1.24 / containers / 6bd8418eb03f / json 1 GET localhost / v1.24 / conteneurs / 06def7875617 / json 1 GET /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600 1 GET /v1.24/images/db39680b63ac47a1d989da7b742f7b688688688681

Vous pouvez voir les mêmes informations dans un format adapté aux conteneurs avec l'indicateur -pcontainer:

sysdig -r monitoring-wordpress.scap -c httptop -pcontainer
URL de la méthode du conteneur ncalls ---------------------------------------------- ---------------------------------- 1000 wordpress-sysdig_wo GET localhost: 8000 /? P = 7 1000 host GET localhost: 8000 /? p = 7 43 wordpress-sysdig_wo OPTIONS * 1 sysdig GET /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600 1 sysdig GET localhost / v1.2s4 v6.26 / 1 cd06093b141b / json 1 sysdig GET /v1.24/images/00e230fe24da9067f9b6e65cfbe9935a5affac1ae8e44edb6a5b0ccc26374d 1 sysdig GET /v1.24/images/db39680b63ac47a2fd89897

Creuser plus profond

Sysdig capture des informations riches en contenu qui vous permettent d'obtenir des informations détaillées sur le fonctionnement interne de vos conteneurs. Supposons que vous exécutiez quelques conteneurs et que vous vouliez savoir quel processus consomme le plus de CPU.

  1. Répertoriez les conteneurs qui étaient actifs pendant la période au cours de laquelle vous avez capturé des événements:
sysdig -r monitoring-wordpress.scap -c lscontainers

2. Vous pouvez identifier le conteneur qui a consommé le plus de CPU avec:

sysdig -r monitoring-wordpress.scap -c topcontainers_cpu
CPU% container.name --------------------------------------------- ----------------------------------- 5,37% wordpress-sysdig_wordpress_1 1,35% wordpress-sysdig_db_1 0,84% hôte 0,51% sysdig

3. Vous pouvez creuser encore plus et identifier le processus le plus gourmand en CPU avec le burin topprocs_cpu:

sysdig -r monitoring-wordpress.scap -c topprocs_cpu container.name contient wordpress_1
CPU% Process PID ---------------------------------------------- ---------------------------------- 0,12% apache2 8383 0,11% apache2 9413 0,11% apache2 9300 0,11% apache2 9242 0,11% apache2 8897 0,11% apache2 8422 0,10% apache2 9372 0,10% apache2 9241 0,10% apache2 8424 0,09% apache2 9429

Si vous voulez voir plus de détails, le burin ps fournit une alternative plus verbeuse:

sysdig -r monitoring-wordpress.scap -c ps container.name = wordpress-sysdig_wordpress_1
TID PID USER VIRT RES FDLIMIT CMD 5896 5896 root 232.82M 22.32M 429496729 apache2 8383 8383 www-data 307.44M 25.46M 429496729 apache2 8422 8422 www-data 235.44M 22.90M 429496729 apache2 8424 8424 www-data 307.44 8849 8897 www-data 235.44M 22.89M 429496729 apache2 9154 9154 www-data 235.44M 22.91M 429496729 apache2 9241 9241 www-data 307.44M 25.66M 429496729 apache2 9242 9242 www-data 307.44M 25.67M 429496729 apache2 22.89M 429496729 apache2 9372 9372 www-data 235.44M 22.89M 429496729 apache2 9413 9413 www-data 233.44M 20.77M 429496729 apache2

Conseils utiles

Si vous exécutez Sysdig pour capturer des événements comme dans l'exemple ci-dessus (sysdig -w monitoring-wordpress.scap), le fichier d'événements augmentera en continu jusqu'à ce qu'il consomme tout l'espace disponible. Il existe quelques méthodes qui peuvent aider à éviter que cela se produise:

  • Spécifiez le nombre d'événements que Sysdig doit capturer en lui passant l'indicateur -n. Une fois que Sysdig capture le nombre spécifié d'événements, il se ferme automatiquement:
sysdig -n 5000 -w monitoring-wordpress.scap
  • Utilisez l'indicateur -C pour configurer Sysdig afin qu'il divise la capture en fichiers plus petits d'une taille spécifiée. L'exemple suivant enregistre en continu les événements dans des fichiers <10 Mo:
sysdig -C 10 -w monitoring-wordpress.scap

Cela créera un tas de fichiers ne dépassant pas 10 Mo:

ls -lh monitoring-wordpress *
-rw-r - r--. 1 racine root 9.6M 7 janvier 17:13 monitoring-wordpress.scap0 -rw-r - r--. 1 racine root 9.6M 7 janvier 17:14 monitoring-wordpress.scap1 -rw-r - r--. 1 racine root 9.6M 7 janvier 17:14 monitoring-wordpress.scap2 -rw-r - r--. 1 racine root 9.6M 7 janvier 17:14 monitoring-wordpress.scap3 -rw-r - r--. 1 racine root 9.6M 7 janvier 17:14 monitoring-wordpress.scap4 -rw-r - r--. 1 racine root 9.6M 7 janvier 17:14 monitoring-wordpress.scap5 -rw-r - r--. 1 racine root 9.6M 7 janvier 17:14 monitoring-wordpress.scap6 -rw-r - r--. 1 racine root 9.6M 7 janvier 17:14 monitoring-wordpress.scap7 -rw-r - r--. 1 racine root 6,4M 7 janvier 17:14 monitoring-wordpress.scap8
  • Spécifiez le nombre maximal de fichiers que Sysdig doit conserver avec l'indicateur -W. Par exemple, vous pouvez combiner les indicateurs -C et -W comme ceci:
sysdig -C 10 -W 4 -w monitoring-wordpress.scap

La commande ci-dessus ne conservera que les quatre derniers fichiers de capture:

ls -lh monitoring-wordpress *
-rw-r - r--. 1 racine root 7,2M 7 janvier 17:21 monitoring-wordpress.scap0 -rw-r - r--. 1 racine root 9.6M 7 janvier 17:21 monitoring-wordpress.scap1 -rw-r - r--. 1 racine root 9.6M 7 janvier 17:21 monitoring-wordpress.scap2 -rw-r - r--. 1 racine root 9.6M 7 janvier 17:21 monitoring-wordpress.scap3 root @ cd06093b141b: / # sysdig -C 10 -W 4 -w monitoring-wordpress.scap

Surveillance en temps réel

Avec Sysdig, vous pouvez également analyser les données en temps réel. À première vue, cela peut sembler une tâche intimidante car, par défaut, tous les événements sont imprimés en continu sur la console. Heureusement, les ciseaux sont là pour vous aider.

Prenons un exemple.

Analysez vos processus par conteneur

  1. Exécutez la commande suivante pour répertorier vos conteneurs:
docker ps
NOMS DE PORTS D'ÉTAT CRÉÉS PAR COMMANDE D'IMAGE ID DE CONTENEUR 5b253e74e8e7 sysdig / sysdig "/docker-entrypoint.…" Il y a 9 minutes Jusqu'à 9 minutes sysdig 06def7875617 wordpress: dernière "docker-entrypoint.s…" Il y a 3 heures Jusqu'à 3 heures 0.0.0.0:8000 -> 80 / tcp wordpress-sysdig_wordpress_1 6bd8418eb03f mysql: 5.7 "docker-entrypoint.s…" Il y a 3 heures Jusqu'à 3 heures 3306 / tcp, 33060 / tcp wordpress-sysdig_db_1

2. Vous pouvez analyser les processus en cours d'exécution dans le conteneur WordPress avec:

sysdig -pc -c topprocs_cpu container.name = wordpress-sysdig_wordpress_1

3. De même, vous pouvez analyser les processus en cours d'exécution dans le conteneur MySQL:

sysdig -pc -c topprocs_cpu container.name = wordpress-sysdig_db_1

Notez que, pas très différent de cet exemple, Sysdig peut surveiller le trafic réseau, l'utilisation du disque, etc.

Dans ce didacticiel, vous avez passé en revue les principes fondamentaux de l'utilisation de Sysdig pour obtenir une compréhension claire de l'activité générée par vos conteneurs. Les exemples de ce billet de blog vous ont aidé à démarrer et, dans de futurs didacticiels, nous vous montrerons comment utiliser Csysdig et Sysdig Inspect.