Supervision de containers
Objectifs du chapitre et prérequis
1. Contexte et prérequis
Grafana et Prometheus peuvent fonctionner dans des containers Docker. Toutefois, le moteur Docker n’est pas supervisé et aucun élément applicatif n’est démarré.
Ce chapitre sera consacré à la mise en place d’une supervision du moteur Docker, au suivi du système et à l’ajout d’un suivi minimal des containers à l’aide de cAdvisor.
L’aspect multinœud de Docker Swarm ne sera pas abordé dans ce chapitre. Il est recommandé de réaliser les exercices avec un seul nœud défini. Ce mécanisme sera présenté au cours du prochain chapitre.
2. Fichiers téléchargeables
Vous pouvez récupérer les exemples sur le repository GitHub suivant : https://github.com/EditionsENI/prometheus-grafana
Vous pouvez également récupérer ces fichiers dans l’archive chapitre-09.tar.gz depuis la page Informations générales.
Supervision de Docker et gestion du cycle de vie
1. Contexte
Prometheus et Grafana sont démarrés mais se cantonnent à leur propre supervision. Afin d’avoir un suivi minimal du moteur Docker, le lecteur va aborder l’activation du point de collecte pour Prometheus et son intégration dans le suivi existant.
Un temps sera également consacré au rechargement à chaud de la configuration de Prometheus via les mécanismes suivants :
-
Utilisation de la commande Docker (similaire au mécanisme kill abordé précédemment).
-
Activation et utilisation de points d’entrée HTTP.
2. Configuration de Docker
Docker offre nativement un point d’entrée de collecte pour Prometheus. Malheureusement, par défaut, ce point est désactivé. Pour y remédier, il est nécessaire de modifier ou créer le fichier /etc/docker/daemon.json en définissant les entrées suivantes :
-
Champ metrics-addr suivi de l’adresse d’écoute.
-
Champ experimental à la valeur true.
La valeur du champ metrics-addr sera positionnée à la valeur 0.0.0.0:9323. De cette manière, le container de Prometheus sera accessible depuis n’importe quelle adresse de la machine.
Voici le contenu du fichier à créer dans le cas où ce dernier n’existerait pas :
{
"metrics-addr" : "0.0.0.0:9323",
"experimental" : true
}
Dans le cas où des éléments de configuration seraient déjà présents, fusionnez l’ensemble des valeurs afin d’y ajouter ces nouvelles clés.
Procédez ensuite à l’arrêt/relance du moteur à l’aide de la commande systemctl suivie de l’option restart et du service à redémarrer (docker).
Cet arrêt/relance entraînera la suppression et la création des containers de Grafana et Prometheus.
Voici ci-dessous la commande complète précédée de sudo :
$ sudo systemctl restart docker
N’hésitez pas à consulter l’état des ports ouverts sur la machine à l’aide de la commande ss suivie des options -lpt. Filtrez également la sortie à l’aide de la commande grep...
Suivi des métriques système
1. Contexte
Le moteur Docker est maintenant suivi. En revanche, aucune métrique n’est disponible pour le suivi des indicateurs système. Le travail va donc consister à déployer l’exporteur système abordé précédemment à l’aide d’un container.
Ce dernier est directement disponible sous le nom prom/node-exporter:v1.0.1 ou quay.io/prometheus/node-exporter:v1.0.1.
2. Prérequis
Afin de pouvoir lancer l’exporteur à l’aide d’un container Docker, il faut soit :
-
arrêter celui lancé via systemd,
-
lancer l’exporteur sur un port différent à l’aide de l’option --web.listen-address (--web.listen-address=:9101 pour le faire démarrer sur le port 9101).
Pour la suite, l’exporteur local - dans le cas où il aurait été déployé - sera arrêté et désactivé à l’aide des commandes systemctl suivantes :
$ sudo systemctl disable node_exporter
$ sudo systemctl stop node_exporter
3. Intégration de l’exporteur système (node-exporter)
a. Exposition de la problématique
Étant donné que l’exporteur est démarré dans un container, une partie des caractéristiques du système est perdue. Afin de corriger la situation, il est nécessaire de procéder aux ajustements suivants :
-
Montage des répertoires /proc et /sys de la machine hôte dans le container dans le sous-répertoire /host.
-
Montage du répertoire / de la machine hôte dans le répertoire /rootfs.
-
Utilisation de la couche réseau de la machine hôte.
-
Changement de l’emplacement des points de montage /proc et /sys (options --path.procfs et sysfs) pour pointer vers le sous-répertoire correspondant dans /host.
-
Exclusion de la surveillance des points de montage suivants : /sys, /proc, /dev, /host, /etc et / avec l’option...
Suivi des containers à l’aide de cAdvisor
1. Contexte
La plateforme surveille le système, le moteur Docker ainsi que les containers Grafana et Prometheus. Afin de disposer d’un exemple complet, les éléments suivants vont être ajoutés :
-
Un container PHP.
-
Un container de base de données MariaDB.
Un découpage réseau sera mis en place afin de séparer les différentes couches applicatives et techniques.
Enfin, afin de réaliser la surveillance système de ces containers (en plus des composants déjà suivis), le service cAdvisor sera déployé. L’utilisateur disposera alors d’un suivi des consommations système brutes, aussi bien processeur que mémoire.
2. Définition des services applicatifs
a. Définition des réseaux applicatifs et de surveillance
Actuellement, la partie réseau n’a été que brièvement abordée et elle n’a eu qu’un seul objet jusqu’à présent : utiliser la couche réseau de la machine hôte.
Le problème est que tout le monde est en mesure d’accéder à l’ensemble des éléments. Afin de mieux isoler ces composants, les réseaux suivants vont être ajoutés :
-
monitoring : hébergera tous les éléments en rapport avec la surveillance de la plateforme.
-
front : hébergera le container en rapport avec la partie présentation PHP.
-
database : hébergera le container de base de données.
Voici le champ networks suite à ces ajouts :
networks:
host:
name: "host"
external: true
front: {}
database: {}
monitoring: {}
b. Définition des services applicatifs
Les deux services à créer porteront les noms php et mariadb.
Le service php aura accès aux réseaux front et database. Cette déclaration se fait à l’aide du champ networks. Il dépendra également du service mariadb pour fonctionner. Cette dépendance peut se déclarer à l’aide du champ depends_on.
Le service mariadb n’aura accès qu’au réseau database. Autre aspect...