Node Exporter est un endpoint (point d'extrémité) qui expose les métriques de l’hôte. Prometheus se connecte périodiquement à ce point d'extrémité pour récupérer les métriques (scrapping).
Le Node Exporter est un binaire statique écrit en Go. Il est disponible sous forme d'archive. Il peut être également intégré à certaines distributions. Ici on a fait le choix d'utiliser un conteneur Docker.
docker image pull prom/node-exporter:v1.2.2
Tester l’exécution de l'application
docker container run --rm --interactive --tty prom/node-exporter:v1.2.2
version: "3.3" networks: vnet-monitoring: external: name: vnet-monitoring services: node-exporter: image: prom/node-exporter:v1.2.2 container_name: node-exporter restart: unless-stopped environment: {} networks: vnet-monitoring: aliases: - localnode
On notera ici que le conteneur est intégré a un réseau externe vnet-monitoring qui devra exister. On a également définit un alias sur ce réseau pour ce service “localnode”.
On va pouvoir valider le fonctionnement du service sur le réseau vnet-monitoring en créant une requête via cURL:
docker container run --rm --interactive --tty --network vnet-monitoring curlimages/curl:7.79.1 "http://localnode/metrics"
Modifier la configurer l'instance Prometheus, on ajoute ici une nouvelle tâche pour récupérer périodiquement les métriques.
... scrape_configs: ... - job_name: "localhost" static_configs: - targets: ["localnode:9100"]
Ici un nouveau job intitulé “localhost” est définit. Pour s' assurer du bon fonctionnement de la tâche.
Depuis les versions 1.0.0 et supérieures les collecteurs peuvent être désactivés par défaut, on active alors seulement les collecteurs utiles pour l'application:
Lorsque node-exporter est installé dans un conteneur, malgré le montage lié avec le pseudo système de fichier /proc de l’hôte, les valeurs retournées pour les métriques réseau ne sont pas celles de l’hôte mais celles du conteneur.
Cette problématique est signalé dans cet article https://stackoverflow.com/questions/59722833/give-node-exporter-container-access-to-network-statistics-from-the-host
Pour que node-exporter puisse exporter les métriques des interfaces de l’hôte et non celle du conteneur, il doit utiliser le type de réseau hôte. (A propos des réseaux Docker voir la note typologie des réseaux Docker et usages ):
version: "3.3" services: node-exporter: image: prom/node-exporter:v1.3.1 container_name: ${COMPOSE_PROJECT_NAME}_node-exporter network_mode: host . . .
Par défaut de nombreux collecteurs sont actifs. On peut faire le choix inverse: désactiver l'ensemble des collecteurs via l'option --collector.disable-defaults et n'activer que les colecteurs nécessaires pour l'application.
version: "3.3" services: node-exporter: image: prom/node-exporter:v1.3.1 container_name: ${COMPOSE_PROJECT_NAME}_node-exporter network_mode: host pid: host restart: unless-stopped environment: {} volumes: - /proc:/host/proc:ro,rslave - /sys:/host/sys:ro,rslave - /:/host/rootfs:ro,rslave command: - '--path.rootfs=/host/rootfs' - '--path.procfs=/host/proc' - '--path.sysfs=/host/sys' - '--collector.disable-defaults' - --collector.netclass - --collector.netdev - --collector.netstat
Le collecteur textfile est comparable au Pushgateway en cela qu'il permet d'exporter des statistiques en provenance de tous types de taches. On peut l'utiliser pour exporter des métriques statiques comme par exemple un rôle lié à la machine. On utilisera de préférence la pushgateway pour les métriques associées aux services. Le module textfile remontera de préférences des métriques liées à la machine hôte.
Pour utiliser le collecteur textfile, définir l'argument --collector.textfile.directory sur la ligne de commande de node-exporter. Le collecteur analysera tous les fichiers *.prom dans le répertoire utilisant le format textformat.
echo my_batch_job_completion_time $(date +%s) > /path/to/directory/my_batch_job.prom.$$ mv /path/to/directory/my_batch_job.prom.$$ /path/to/directory/my_batch_job.prom
Pour définir un rôle statique à la machine, utiliser les labels:
echo 'role{role="application_server"} 1' > /path/to/directory/role.prom.$$ mv /path/to/directory/role.prom.$$ /path/to/directory/role.prom
# Création d'un fichier statique pour test mkdir /var/local/node-exporter cd /var/local/node-exporter echo 'node_ufw_status{ service="ufw" } 1' > ufw-status.prom # On vérifie que le fichier est lisible depuis le conteneur docker-compose exec node-exporter /bin/sh cat /host/rootfs/var/local/node-exporter/ufw-status.prom node_ufw_status{ service="ufw" } 1 exit
Le collecteur systemd ne remonte correctement les métriques que lorsque le conteneur s'exécute avec l'utilisateur root. Il est possible de sélectionner finement les services pour lesquels on souhaite remonter des métriques via des regex et l'option --collector.systemd.unit-include:
version: "3.3" services: node-exporter: image: prom/node-exporter:v1.3.1 container_name: ${COMPOSE_PROJECT_NAME}_node-exporter network_mode: host pid: host user: root restart: unless-stopped environment: {} volumes: - /proc:/host/proc:ro,rslave - /sys:/host/sys:ro,rslave - /:/host/rootfs:ro,rslave - /run/systemd/private:/run/systemd/private:ro,rslave command: - '--path.rootfs=/host/rootfs' - '--path.procfs=/host/proc' - '--path.sysfs=/host/sys' - '--collector.disable-defaults' - '--collector.systemd' - '--collector.systemd.unit-include=ufw\.service'
Via le collecteur systemd on peut récupérer des métriques concernant les services existants sur le système. Attention pour l'unité ufw.service car elle peut être active alors que le pare-feu est désactivé. L'utilisation du collecteur systemd seul pour vérifier l'état du pare-feu n'est dans ce cas pas vraiment pertinent.
# on désactive le pare-feu sudo ufw disable # On affiche l'état du pare-feu sudo ufw status État : inactif # L"unité systemd est cependant toujours active systemctl status ufw.service ● ufw.service - Uncomplicated firewall Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled) Active: active (exited) since Fri 2022-02-11 17:03:37 CET; 8min ago
La métrique exportée par le collecteur systemd indiquera que l'unité est active. Depuis l'explorateur Grafana, la valeur instantanée associée à la métrique node_systemd_unit_state{name=“ufw.service”, state=“active”} vaudra 1 car l'unité ufw.service est active alors que le pare-feu est désactivé.