Différences

Ci-dessous, les différences entre deux révisions de la page.

--- software:applications:prometheus:installer_node-exporter [2022/02/11 16:24] – yoann
+++ software:applications:prometheus:installer_node-exporter [2022/02/14 12:00] (Version actuelle) – yoann
@@ Ligne 68: / Ligne 68: @@
 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 [[sysadmin:docker:typologie_reseaux_docker | typologie des réseaux Docker et usages]] ):
+<file YAML>
+version: "3.3"
+services:
+  node-exporter:
+    image: prom/node-exporter:v1.3.1
+    container_name: ${COMPOSE_PROJECT_NAME}_node-exporter
+    network_mode: host
+    . . .
+</file>
 ===== Les collecteurs =====
@@ Ligne 98: / Ligne 111: @@
 </code>
-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 pertinent.
+==== Collecteur textfile ====
+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.
+<note>
+Le timestamp n'est pas suporté, pour ajouter un horodatage:
+<code bash>
+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
+</code>
+</note>
+Pour définir un rôle statique à la machine, utiliser les labels:
+<code bash>
+echo 'role{role="application_server"} 1' > /path/to/directory/role.prom.$$
+mv /path/to/directory/role.prom.$$ /path/to/directory/role.prom
+</code>
+<code bash>
+# 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
+</code>
+==== Collecteur systemd ====
+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%%**:
+<file YAML >
+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'
+</file>
+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.
 <code bash>
@@ Ligne 106: / Ligne 184: @@
 # On affiche l'état du pare-feu
 sudo ufw status
 État : inactif
-# Le service lui est cependant actif
+# L"unité systemd est cependant toujours active
 systemctl status ufw.service
 ● ufw.service - Uncomplicated firewall
@@ Ligne 116: / Ligne 194: @@
 </code>
-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 cependant le pare-feu est désactivé.
+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é.
 ===== Références =====

wikinotes

Outils pour utilisateurs

Outils du site

Différences

Outils de la page