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

docker-compose.yml

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.

docker-compose.yml

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é.

• https://prometheus.io/docs/guides/node-exporter/
• https://stackoverflow.com/questions/54905833/how-to-set-node-exporter-of-prometheus
• https://borismallach.fr/install-er-node-exporter-sur-un-synology-avec-docker/
• https://github.com/prometheus/node_exporter