Surveillance et alertes réseau Docker : guide pratique de terrain

Introduction

Le réseau Docker est le système circulatoire des applications conteneurisées. Il connecte les services, assure la découverte de services et isole les charges de travail. Mais lorsqu'il tombe en panne, tout tombe en panne. Les conteneurs peuvent perdre la connectivité, les réseaux overlay peuvent se partitionner et la résolution DNS peut échouer silencieusement. C'est pourquoi la surveillance du réseau Docker n'est pas un luxe ; elle est essentielle pour maintenir la fiabilité des applications conteneurisées.

Dans ce guide, nous allons adopter une approche pratique de la surveillance du réseau Docker. Nous verrons quoi surveiller, quelles métriques sont importantes, comment configurer des règles d'alerte et comment construire des tableaux de bord qui aident réellement à diagnostiquer les problèmes. Nous aborderons également les flux de travail de réponse aux incidents afin que, lorsqu'une alerte se déclenche, vous sachiez exactement quoi faire.

Nous nous concentrerons sur les capacités réseau natives de Docker, notamment les réseaux bridge et overlay. Nous éviterons de recourir aux plateformes d'orchestration de conteneurs ou aux pipelines CI/CD, car les principes fondamentaux s'appliquent partout où Docker est exécuté.

À la fin de ce guide, vous serez en mesure de :

• Identifier les composants clés du réseau Docker à surveiller.
• Collecter et interpréter les métriques essentielles.
• Définir des seuils d'alerte pertinents.
• Construire un tableau de bord qui met en évidence la santé du réseau.
• Répondre aux incidents réseau courants avec confiance.

Allons-y.

Inventaire des versions et de l'environnement

Avant de pouvoir surveiller efficacement le réseau Docker, vous devez savoir exactement ce que vous exécutez. Cet inventaire vous aidera à comprendre l'étendue de votre surveillance, à choisir les bons outils et à résoudre les problèmes ultérieurement.

Version de Docker et fonctionnalités réseau

Commencez par vérifier votre version de Docker. Différentes versions offrent différentes fonctionnalités et métriques réseau. Exécutez :

docker version

Sortie typique :

Client: Docker Engine - Community
 Version:           24.0.5
 API version:       1.43
 Go version:        go1.20.6
 Git commit:        ced0996
 Built:             Fri Jul 21 17:21:01 2023
 OS/Arch:           linux/amd64

Server: Docker Engine - Community
 Engine:
  Version:          24.0.5
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.6
  Git commit:       3egg0ss
  Built:            Fri Jul 21 17:19:02 2023
  OS/Arch:          linux/amd64
  Experimental:     false

Notez la version de l'API ; certains outils de surveillance s'appuient dessus. Ensuite, vérifiez la configuration réseau du démon Docker :

docker info --format '{{json .Plugins.Network}}'

Cela affiche les pilotes réseau disponibles comme bridge, overlay, macvlan, etc. Par exemple :

["bridge","host","ipvlan","macvlan","null","overlay"]

Connaître vos pilotes vous aide à déterminer les métriques à collecter.

Topologie et étendue

Dessinez un diagramme simple de votre topologie réseau Docker. Identifiez :

• Les interfaces hôte et les réseaux bridge (docker0 généralement).
• Les réseaux bridge définis par l'utilisateur.
• Les réseaux overlay (si vous utilisez Docker Swarm).
• Les mappages de ports (-p).
• La configuration DNS (DNS intégré à 127.0.0.11).

Une commande simple pour lister les réseaux :

docker network ls

Exemple de sortie :

NETWORK ID     NAME      DRIVER    SCOPE
4f5d3c2b1a0e   bridge    bridge    local
9a8b7c6d5e4f   host      host      local
2b3c4d5e6f7a   myapp_net bridge    local

Pour chaque réseau, inspectez ses détails :

docker network inspect myapp_net

Cette sortie inclut le sous-réseau, la passerelle et les conteneurs connectés. C'est essentiel pour comprendre le flux de trafic et les goulots d'étranglement potentiels.

Prérequis pour la collecte de métriques

Pour collecter des métriques du réseau Docker, vous avez besoin d'un agent capable d'accéder au démon Docker. Les options courantes incluent :

• cAdvisor : fournit des métriques réseau au niveau des conteneurs (octets envoyés/reçus).
• Prometheus avec les métriques du démon Docker : Docker expose des métriques internes sur http://host:9323/metrics si vous activez la fonctionnalité de métriques expérimentales.
• Netdata : possède des plugins Docker.
• Telegraf : agent d'InfluxData avec entrée Docker.

Pour ce guide, nous utiliserons Prometheus et le point de terminaison des métriques du démon Docker, car il est largement adopté et s'intègre bien avec les alertes.

Activez les métriques du démon Docker en éditant /etc/docker/daemon.json :

{
  "metrics-addr" : "0.0.0.0:9323",
  "experimental" : true
}

Puis redémarrez Docker :

sudo systemctl restart docker

Vérifiez les métriques :

curl http://localhost:9323/metrics

Vous devriez voir des métriques comme engine_daemon_network_actions_total et engine_daemon_network_connect_actions_total.

Pile d'alertes

Pour les alertes, Alertmanager de Prometheus est le compagnon standard. Nous définirons des règles d'alerte dans Prometheus et les acheminerons via Alertmanager vers des canaux de notification comme l'e-mail, Slack ou PagerDuty.

Assurez-vous d'avoir une instance Prometheus en cours d'exécution qui collecte les métriques du point de terminaison Docker. Une configuration Prometheus minimale :

scrape_configs:
  - job_name: 'docker'
    static_configs:
      - targets: ['localhost:9323']

Vous êtes maintenant prêt à concevoir des modifications de surveillance sûres.

Chemin de configuration sûr

Les modifications de surveillance peuvent causer des problèmes par inadvertance : charge supplémentaire sur le démon Docker, tempêtes d'alertes ou tableaux de bord mal configurés. Par conséquent, mettez en œuvre la surveillance de manière contrôlée et incrémentale.

Étape 1 : Commencer par une base de référence

Avant d'ajouter des alertes, collectez des métriques de base pendant une semaine sous charge normale. Cela vous donne une référence pour définir les seuils. Utilisez des requêtes Prometheus pour explorer les modèles de métriques.

Par exemple, surveillez le trafic réseau total par conteneur :

rate(container_network_receive_bytes_total[5m])

Ou les actions réseau du démon Docker :

rate(engine_daemon_network_actions_total[5m])

Enregistrez les plages typiques à différents moments de la journée. Par exemple, vous pourriez constater que votre conteneur frontend web moyen reçoit 1,2 Mo/s en entrée pendant les heures de pointe et 300 Ko/s hors pointe, tandis que le conteneur de base de données reste autour de 150 Ko/s de manière constante. Ces chiffres deviennent votre référence pour la détection d'anomalies.

Étape 2 : Activer un ensemble restreint de métriques

Commencez par quelques métriques à forte valeur ajoutée qui indiquent directement la santé du réseau. Évitez de collecter toutes les métriques possibles ; concentrez-vous sur :

• E/S réseau des conteneurs : octets et paquets par seconde, erreurs, paquets abandonnés.
• Actions réseau du démon Docker : connexion, déconnexion, création, destruction.
• Métriques de résolution DNS (si disponibles) : le DNS intégré de Docker peut être observé indirectement via la latence des requêtes.

Utilisez cAdvisor ou l'exportateur de nœuds Prometheus en conjonction avec les métriques Docker pour les statistiques réseau au niveau des conteneurs. Par exemple, pour obtenir des métriques réseau au niveau des conteneurs à partir de cAdvisor, assurez-vous qu'il fonctionne avec --docker_only=true et collectez son point de terminaison /metrics.

Étape 3 : Définir des alertes conservatrices

Créez des règles d'alerte avec des seuils généreux pour éviter les faux positifs. Par exemple, alertez lorsque les erreurs de réception réseau dépassent un état stable, pas seulement un pic transitoire.

Dans Prometheus, créez un fichier de règles docker_network_alerts.yml :

groups:
  - name: docker_network
    rules:
      - alert: DockerNetworkHighErrorRate
        expr: rate(container_network_receive_errors_total[5m]) > 10
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Taux d'erreurs réseau élevé sur le conteneur {{ $labels.name }}"
          description: "Les erreurs de réception dépassent 10 par seconde pendant 10 minutes."

Remarquez la clause for: 10m garantit que la condition persiste avant de se déclencher, réduisant le bruit. Ajustez le seuil en fonction de votre base de référence : si votre taux d'erreur de base est proche de zéro, même un taux supérieur à 1 par seconde peut être significatif. Commencez avec un seuil plusieurs fois supérieur au maximum observé pendant la base de référence, puis resserrez progressivement.

Étape 4 : Tester les alertes en staging ou avec une charge simulée

Avant de déployer en production, simulez des problèmes réseau dans un environnement de test. Par exemple, utilisez tc (contrôle du trafic) pour introduire une perte de paquets sur une interface de conteneur et vérifiez que l'alerte se déclenche.

Exemple : ajouter 20 % de perte de paquets sur eth0 à l'intérieur d'un conteneur :

docker exec mycontainer tc qdisc add dev eth0 root netem loss 20%

Vérifiez ensuite les alertes Prometheus et le routage Alertmanager. Si votre environnement de test ne peut pas exécuter tc à l'intérieur du conteneur en raison de capacités manquantes, exécutez-le sur l'hôte avec --cap-add=NET_ADMIN lors du démarrage du conteneur, ou utilisez un émulateur de réseau comme pumba pour les tests de chaos.

Étape 5 : Déploiement progressif et retour d'information

Déployez la configuration de surveillance sur les hôtes de production un par un ou par petits lots. Surveillez le système d'alerte lui-même pour détecter toute alerte inattendue. Ajustez les seuils en fonction du trafic réel.

Tenez un journal des modifications de surveillance pour suivre l'impact. Par exemple, enregistrez la date, l'alerte modifiée, l'ancien seuil, le nouveau seuil et la raison. Cela vous aide à revenir rapidement en arrière si une modification provoque une fatigue des alertes.

Vérification et diagnostics

Une fois la surveillance en place, vous devez vérifier que les métriques sont collectées avec précision et que les tableaux de bord sont utiles. Cette section fournit des contrôles concrets et des commandes de diagnostic.

Vérification de la collecte des métriques

Tout d'abord, confirmez que Prometheus collecte correctement les métriques Docker :

curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | select(.job=="docker") | .health'

Sortie attendue :

"up"

Si elle indique down, vérifiez la connectivité et le point de terminaison des métriques du démon Docker. Interrogez également une métrique d'exemple :

curl -s 'http://localhost:9090/api/v1/query?query=container_network_receive_bytes_total' | jq '.data.result[0].value'

Doit renvoyer une valeur. Si vous voyez un résultat vide, assurez-vous que le nom de la métrique est correct et que l'exportateur fonctionne.

Vérification des panneaux du tableau de bord

Si vous utilisez Grafana, créez un tableau de bord avec ces panneaux :

• Trafic réseau par conteneur : série temporelle de rate(container_network_receive_bytes_total[5m]) et rate(container_network_transmit_bytes_total[5m]).
• Erreurs réseau : rate(container_network_receive_errors_total[5m]) et rate(container_network_transmit_errors_total[5m]).
• Actions réseau du démon Docker : rate(engine_daemon_network_actions_total[5m]).

Exportez un exemple depuis Grafana ou prenez une capture d'écran pour vérifier que les visualisations sont rendues. Par exemple, un tableau de bord sain pourrait montrer le taux de réception de votre conteneur frontend oscillant autour de 1,5 Mo/s avec des pics occasionnels à 3 Mo/s, et un taux d'erreur nul.

Diagnostic des problèmes réseau courants

Lorsqu'une alerte se déclenche ou que vous soupçonnez un problème réseau, suivez un chemin de diagnostic systématique.

Vérifier la connectivité du conteneur :

docker exec mycontainer ping -c 4 8.8.8.8

Sortie attendue en cas de succès :

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.3 ms
...

Vérifier la résolution DNS à l'intérieur du conteneur :

docker exec mycontainer nslookup example.com

Si le DNS échoue, vérifiez le paramètre DNS intégré de Docker et /etc/resolv.conf.

Inspecter les détails du réseau :

docker network inspect myapp_net

Recherchez les conteneurs déconnectés ou les attributions d'IP incorrectes. Par exemple, si l'IP d'un conteneur est en dehors de la plage du sous-réseau, il peut y avoir un conflit de configuration.

Afficher les statistiques réseau du conteneur :

docker stats --no-stream mycontainer --format "table {{.Name}}\t{{.NetIO}}"

La sortie montre les octets reçus/transmis, par exemple mycontainer 1.2GB / 350MB.

Vérifier les journaux du démon Docker pour les erreurs liées au réseau :

journalctl -u docker.service --since "10 minutes ago" | grep -i network

Tableau de diagnostic des métriques et interprétation

Ce sont des exemples construits pour illustration ; les bases réelles varient.

Modes de défaillance et récupération

Le réseau Docker peut échouer de plusieurs manières. Connaître les modes de défaillance courants vous aide à planifier les procédures de récupération et à éviter les temps d'arrêt.

Mode de défaillance 1 : Le conteneur ne peut pas résoudre le DNS

Symptôme : Les applications à l'intérieur des conteneurs ne parviennent pas à se connecter aux services externes par nom d'hôte. ping fonctionne vers l'IP mais pas vers le nom d'hôte.

Causes probables :

• DNS mal configuré dans le démon Docker (--dns ou dns dans daemon.json).
• /etc/resolv.conf personnalisé remplaçant le DNS intégré de Docker.
• Problèmes de cache DNS du démon Docker.

Récupération :

1. Vérifiez les paramètres DNS du démon Docker : docker info | grep -A2 'DNS'
2. Inspectez le DNS du conteneur : docker exec mycontainer cat /etc/resolv.conf
3. Assurez-vous que le DNS intégré de Docker (127.0.0.11) est listé si vous utilisez des réseaux définis par l'utilisateur.
4. Si mal configuré, corrigez daemon.json et redémarrez Docker, ou recréez le conteneur.
5. Vérifiez avec docker exec mycontainer nslookup example.com.

Retour en arrière : Si un changement récent a introduit le problème, revenez à la configuration DNS précédente et redémarrez Docker.

Mode de défaillance 2 : Partition du réseau overlay (Swarm)

Symptôme : Les conteneurs sur différents nœuds ne peuvent pas communiquer sur un réseau overlay. Certains services ne peuvent pas s'atteindre.

Causes probables :

• Pare-feu bloquant le port VXLAN 4789/udp.
• Dérive d'horloge des nœuds cassant les clés de chiffrement.
• Incohérence du gestionnaire Swarm.

Récupération :

1. Vérifiez l'état du réseau overlay : docker network inspect <overlay_name>
2. Vérifiez que l'UDP 4789 est ouvert entre les nœuds : nc -u <node_ip> 4789 -v
3. Redémarrez Docker sur les nœuds affectés : sudo systemctl restart docker
4. Si le chiffrement est activé, vérifiez la distribution des clés.
5. Recréez le réseau overlay si nécessaire : docker network rm <overlay_name> && docker network create -d overlay <overlay_name>

Prévention : Surveillez le trafic overlay et la connectivité des nœuds.

Mode de défaillance 3 : Taux d'erreurs réseau élevé

Symptôme : L'alerte se déclenche sur container_network_receive_errors_total ou les erreurs de transmission. Les applications subissent des délais d'attente.

Causes probables :

• NIC physique ou câble défectueux.
• Congestion entraînant une perte de paquets.
• Bug dans le pilote réseau.

Récupération :

1. Isolez le conteneur ou l'hôte : vérifiez si les erreurs se produisent sur tous les conteneurs ou un seul.
2. Inspectez les erreurs de la NIC hôte : ethtool -S eth0 | grep -i error
3. Vérifiez la perte de paquets : ping -f -c 1000 <target> et observez la perte.
4. Déplacez les conteneurs vers un autre hôte si problème matériel.
5. Mettez à jour Docker ou le pilote réseau si bug logiciel.

Retour en arrière : Si le problème a commencé après une mise à jour de Docker, rétrogradez vers la version stable précédente.

Mode de défaillance 4 : Conflits de mappage de ports

Symptôme : Le conteneur ne démarre pas avec l'erreur : Bind for 0.0.0.0:8080 failed: port is already allocated.

Causes probables : Un autre conteneur ou processus hôte utilise le même port.

Récupération :

1. Trouvez le port en conflit : sudo lsof -i :8080 ou docker ps --format '{{.Ports}}' | grep 8080
2. Arrêtez le processus en conflit ou modifiez le mappage de ports.
3. Mettez à jour docker-compose ou la commande run avec un port hôte différent.

Prévention : Utilisez l'allocation dynamique de ports ou maintenez un registre de ports.

Vérification des métriques après récupération

Après la récupération, vérifiez que les métriques reviennent à la normale. Par exemple, le taux d'erreurs devrait baisser et la connectivité être rétablie. Utilisez des requêtes Prometheus pour confirmer. Par exemple, après avoir corrigé un problème DNS, exécutez une requête comme rate(dns_query_duration_seconds[5m]) pour vous assurer que la latence est revenue à la base.

Liste de contrôle des opérations

Pour maintenir le réseau Docker en bonne santé, intégrez les vérifications suivantes dans vos opérations régulières. Attribuez un responsable unique pour chaque vérification afin d'assurer la responsabilité. Par exemple, Priya Shah (ingénieure DevOps) est responsable de l'examen quotidien du taux d'erreurs, et Marcus Chen (administrateur réseau) est responsable de l'exercice trimestriel de connectivité overlay. Révisez la liste de contrôle elle-même mensuellement pour l'adapter aux changements.

Vérifications quotidiennes

• [ ] Examiner les tableaux de bord pour détecter des pics de trafic réseau inhabituels ou des taux d'erreurs. Responsable : Priya Shah.
• [ ] Vérifier l'état des alertes Prometheus et les alertes réduites au silence. Responsable : ingénieur de garde.
• [ ] Vérifier que le point de terminaison des métriques du démon Docker est actif et collecté. Responsable : ingénieur de garde.

Vérifications hebdomadaires

• [ ] Inspecter la liste des réseaux Docker pour les réseaux orphelins : docker network ls et nettoyer avec docker network prune. Responsable : Priya Shah.
• [ ] Examiner les actions réseau échouées dans les journaux du démon Docker. Responsable : Marcus Chen.
• [ ] Mettre à jour la documentation réseau si la topologie a changé. Responsable : rédacteur technique.

Vérifications mensuelles

• [ ] Tester le flux d'alertes en déclenchant une alerte de test (par exemple, en utilisant curl pour atteindre un point de terminaison personnalisé ou en abaissant temporairement un seuil). Responsable : Priya Shah.
• [ ] Vérifier les performances de résolution DNS depuis des conteneurs représentatifs. Responsable : Marcus Chen.
• [ ] Vérifier les configurations de sauvegarde du démon Docker et des paramètres réseau. Responsable : administrateur système.

Vérifications trimestrielles

• [ ] Revoir les seuils d'alerte par rapport à la base récente et ajuster si nécessaire. Responsable : Priya Shah.
• [ ] Effectuer un exercice de basculement pour les réseaux overlay (le cas échéant). Responsable : Marcus Chen.
• [ ] Envisager de mettre à jour Docker vers une version stable plus récente et refaire l'inventaire de l'environnement. Responsable : gestionnaire de version.

Tableau : Résumé des vérifications opérationnelles

Ce sont des exemples construits ; adaptez-les à votre environnement.

Pièges et erreurs courants

Même avec la surveillance en place, les équipes tombent souvent dans des pièges qui sapent leurs efforts. Voici les pièges courants de la surveillance du réseau Docker et comment les éviter.

1. Fatigue des alertes due à des seuils trop sensibles

Pourquoi cela arrive : Fixer des seuils trop bas ou ne pas utiliser de durée for entraîne des alertes pour chaque petit incident.

Comment éviter : Commencez par des seuils conservateurs basés sur les données de référence. Utilisez une clause for d'au moins 5 à 10 minutes pour vous assurer que la condition est persistante. Révisez régulièrement la fréquence des alertes et ajustez.

2. Ignorer le DNS comme point de défaillance

Pourquoi cela arrive : Les équipes se concentrent sur les métriques d'interface mais oublient que le DNS intégré de Docker (127.0.0.11) est un composant critique. Les défaillances DNS apparaissent souvent comme des erreurs d'application plutôt que des erreurs réseau.

Comment éviter : Surveillez la latence des requêtes DNS et les taux d'erreurs. Ajoutez une vérification synthétique qui résout un nom d'hôte connu depuis un conteneur chaque minute. Utilisez un outil comme blackbox_exporter ou une simple tâche cron.

3. Ne pas surveiller le démon Docker lui-même

Pourquoi cela arrive : Les métriques au niveau des conteneurs sont faciles à collecter, mais les actions réseau internes du démon (connexion, déconnexion, création) peuvent indiquer des problèmes comme le churn réseau.

Comment éviter : Activez les métriques du démon Docker (comme indiqué précédemment) et incluez engine_daemon_network_actions_total dans vos tableaux de bord et alertes.

4. Négliger les conflits de mappage de ports

Pourquoi cela arrive : Les conflits de ports se produisent silencieusement lorsque les conteneurs sont recréés ou que de nouveaux services sont déployés. Sans surveillance proactive, le seul symptôme est l'échec du démarrage du conteneur.

Comment éviter : Mettez en œuvre une vérification pré-déploiement qui analyse la disponibilité des ports à l'aide d'un script ou d'un pipeline CI. Maintenez un fichier de registre de ports dans le contrôle de version et mettez-le à jour à chaque changement de service.

5. Ne pas tester les procédures de récupération

Pourquoi cela arrive : Les équipes écrivent des runbooks mais ne les pratiquent jamais. Lorsqu'un incident réel se produit, les procédures ne sont pas testées et peuvent ne pas fonctionner.

Comment éviter : Planifiez des exercices d'incendie réguliers (mensuels ou trimestriels) où vous simulez intentionnellement une défaillance (par exemple, en utilisant tc pour abandonner des paquets) et suivez les étapes de récupération. Documentez les lacunes et mettez à jour le runbook.

6. Surveiller en isolation des métriques d'application

Pourquoi cela arrive : Les métriques réseau seules ne vous disent pas si les utilisateurs sont affectés. Un pic d'erreurs peut ne pas être corrélé avec la latence de l'application si les tentatives fonctionnent.

Comment éviter : Corrélez les métriques réseau avec des indicateurs de niveau application comme les taux d'erreurs HTTP 5xx, la latence des requêtes et le débit. Utilisez des tableaux de bord Grafana qui montrent côte à côte les panneaux réseau et application.

Conclusion

La surveillance du réseau Docker est une discipline essentielle pour maintenir les applications conteneurisées. En suivant les étapes pratiques de ce guide, vous avez appris à inventorier votre environnement, activer une surveillance sûre, collecter et interpréter les métriques, configurer des alertes pertinentes et répondre aux défaillances.

Points clés à retenir :

• Commencez par un inventaire clair des versions de Docker, des pilotes réseau et de la topologie.
• Mettez en œuvre la surveillance de manière incrémentale, en utilisant un ensemble restreint de métriques à forte valeur ajoutée et des alertes conservatrices.
• Utilisez Prometheus et les métriques du démon Docker pour la collecte, et Grafana pour les tableaux de bord.
• Vérifiez avec des commandes concrètes et des sorties attendues.
• Préparez-vous aux modes de défaillance courants comme les problèmes DNS, les partitions overlay, les taux d'erreurs élevés et les conflits de ports.
• Évitez les pièges courants en réglant les alertes, en surveillant le DNS et le démon, en testant la récupération et en corrélant avec les métriques d'application.
• Suivez une liste de contrôle opérationnelle régulière avec des responsables clairs pour garder votre réseau en bonne santé.

Prochaines étapes :

1. Effectuez l'inventaire des versions et de l'environnement sur vos hôtes Docker.
2. Activez les métriques Docker et configurez la collecte Prometheus.
3. Créez un tableau de bord de base et observez pendant quelques jours.
4. Rédigez des règles d'alerte initiales avec des seuils conservateurs.
5. Simulez une défaillance et testez votre flux de réponse.
6. Attribuez des responsables aux éléments de la liste de contrôle et planifiez des révisions régulières.
7. Étendez progressivement à plus de métriques et d'alertes à mesure que vous gagnez en confiance.

Avec ces pratiques, vous pouvez transformer la surveillance du réseau Docker d'une corvée réactive en un avantage proactif.