TP : Premier pipeline - métriques système et logs locaux

Ce que vous allez apprendre dans ce TP

• Construire un pipeline métriques et logs
• Utiliser des variables d'environnement
• Valider les données dans Grafana

Introduction #

Ce que vous allez apprendre dans cette section

• Construire un pipeline métriques et logs
• Utiliser des variables d'environnement
• Valider les données dans Grafana

Contexte. L'équipe infrastructure veut un premier pipeline complet « as code » : métriques système vers Prometheus et logs vers Loki, sans assistant graphique ni configuration manuelle. Ce TP pose le socle réutilisé par les suivants.

Prérequis : TP « Installer Alloy » réalisé, Docker Compose  ·  Durée estimée : 45 min

Vous allez construire un pipeline « Configuration as Code » complet : exportateur, scrape, remote_write, lecture de logs et expédition. Le tout est lancé via Docker Compose avec Prometheus, Loki et Grafana.

Préparer la stack #

Un environnement local réutilisable pour les TPs suivants.

1. 1. Créer le fichier docker-compose.yml

   Pourquoi ? Une stack locale reproductible (Prometheus, Loki, Grafana) évite de dépendre d'un environnement partagé et sert de banc d'essai pour tous les TPs suivants.

   Déclarez les services prometheus (avec le récepteur remote write activé), loki, grafana et alloy (qui monte /var/log en lecture seule).

Le pipeline de métriques #

De l'exportateur système jusqu'à Prometheus.

1. 2. Exporter et scraper les métriques système

   Pourquoi ? L'exportateur système remplace node_exporter : on collecte CPU, mémoire, disques et réseau avec un seul binaire déjà présent.

   Écrivez le début de config.alloy : un prometheus.exporter.unix limité aux collecteurs cpu, meminfo, diskstats et netdev, scrapé toutes les 15 secondes.

2. 3. Expédier avec remote_write et des variables d'environnement

   Pourquoi ? Les secrets et URLs ne doivent jamais être écrits en dur : les variables d'environnement permettent de réutiliser la même configuration du développement à la production.

   Ajoutez le composant prometheus.remote_write. L'URL doit venir de la variable d'environnement PROM_URL (fonction sys.env) et chaque série doit porter un label externe host valant le nom d'hôte (constants.hostname).

Le pipeline de logs #

Lire les logs de l'hôte et les envoyer à Loki.

1. 4. Lire les fichiers de logs

   Pourquoi ? Les logs du système sont la première source d'information en cas d'incident : il faut d'abord les découvrir (fichiers) avant de pouvoir les lire.

   Découvrez les fichiers /host/var/log/*.log, ajoutez-leur le label job="varlogs" et lisez-les.

2. 5. Expédier vers Loki

   Pourquoi ? Les logs lus ne servent à rien tant qu'ils ne sont pas stockés quelque part : Loki les rend interrogeables et corrélables avec les métriques.

   Ajoutez le composant loki.write vers http://loki:3100.

3. 6. Valider dans Grafana

   Pourquoi ? Valider de bout en bout dans Grafana prouve que le pipeline entier fonctionne, et pas seulement chaque composant isolé.

   Démarrez la stack, ajoutez Prometheus et Loki comme sources de données dans Grafana (http://localhost:3000) puis exécutez une requête PromQL et une requête LogQL.

Niveau de difficulté : ●●○○○ (2/5)