wikinotes

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
{{tag>sysadmin netadmin supervision monitoring prometheus}}

====== Installer node-exporter pour exposer les métriques de l’hôte ======

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

<code bash>
docker image pull prom/node-exporter:v1.2.2
</code>

Tester l’exécution de l'application
<code bash>
docker container run --rm --interactive --tty prom/node-exporter:v1.2.2
</code>

<file YAML 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
</file>

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:

<code bash>
docker container run --rm --interactive --tty --network vnet-monitoring curlimages/curl:7.79.1 "http://localnode/metrics"
</code>

Modifier la configurer l'instance Prometheus, on ajoute ici une nouvelle tâche pour récupérer périodiquement les métriques.

<file YAML>
...
scrape_configs:
  ...
  - job_name: "localhost"
    static_configs:
      - targets: ["localnode:9100"]

</file>

Ici un nouveau job intitulé "localhost" est définit. Pour s' assurer du bon fonctionnement de la tâche.

===== Collecteurs =====

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:


===== Troubleshooting =====

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 [[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 =====

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.

<code YAML 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
</code>

==== 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>
# 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

</code>

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 =====

  * 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
wikinotes

Outils pour utilisateurs

Outils du site

Outils de la page
