TP Final : Pipeline d'observabilité unifié et modulaire

Ce que vous allez apprendre dans ce TP

• Structurer en modules réutilisables
• Couvrir les 3 signaux
• Auditer les secrets
• Auto-superviser Alloy

Introduction #

Ce que vous allez apprendre dans cette section

• Structurer en modules réutilisables
• Couvrir les 3 signaux
• Auditer les secrets
• Auto-superviser Alloy

Contexte. Projet de synthèse : vous devez standardiser la collecte d'une plateforme. La configuration doit être modulaire (réutilisable par plusieurs équipes), ne contenir aucun secret et couvrir logs, métriques et traces. C'est le type de livrable demandé dans une vraie mission.

Prérequis : Tous les TPs précédents, une stack Loki / Prometheus / Tempo  ·  Durée estimée : 90 min

Vous êtes chargé de standardiser la collecte d'une plateforme. Cahier des charges : une configuration modulaire, sans secret en clair, couvrant les 3 signaux et auto-supervisée. Réutilisez la stack des TPs précédents.

Un module réutilisable #

Encapsuler un pipeline de logs avec declare.

1. 1. Écrire le module de logs

   Pourquoi ? Un module encapsule un pipeline avec ses arguments : plusieurs équipes réutilisent la même logique sans copier-coller et en bénéficient de ses corrections.

   Dans modules/logs.alloy, créez un bloc declare "app_logs" qui prend en arguments targets, forward_to et env (optionnel, défaut dev), lit les fichiers et ajoute le label env.

2. 2. Importer et instancier le module

   Pourquoi ? Instancier le module montre comment passer des paramètres (cibles, environnement) : c'est ce qui rend le même code valable en dev et en production.

   Dans config.alloy, importez le fichier avec import.file et instanciez le module comme s'il s'agissait d'un composant.

Métriques, traces et sécurité #

Les deux autres signaux et la gestion des secrets.

1. 3. Ajouter métriques et traces

   Pourquoi ? Les trois signaux sont indépendants dans le fichier : un incident sur l'un ne doit pas bloquer les autres, et chacun suit son propre chemin de traitement.

   Ajoutez la collecte des métriques de l'hôte (prometheus.exporter.unix) et la réception OTLP des traces vers Tempo, en reprenant les composants vus dans les TPs précédents.

2. 4. Supprimer tous les secrets en clair

   Pourquoi ? Un secret oublié dans Git est une compromission : un audit systématique (recherche de mots-clés) fait partie de la recette d'un livrable.

   Auditez votre configuration : aucun mot de passe, token ou URL privée ne doit être écrit en dur. Comment vérifier rapidement ?

Auto-supervision et validation #

Superviser le superviseur.

1. 5. Superviser Alloy lui-même

   Pourquoi ? Un collecteur qui tombe sans prévenir est pire qu'une absence de collecte : superviser Alloy permet d'alerter avant que les trous de données ne se voient.

   Envoyez les métriques internes d'Alloy vers Prometheus et créez une alerte sur l'absence de données (up == 0).

2. 6. Checklist de recette

   Pourquoi ? Une checklist de recette rend la validation objective et reproductible : chaque critère se vérifie avec une commande ou une capture.

   Validez chaque point :
   • la configuration est formatée (alloy fmt) ;
   • l'UI n'affiche aucun composant en erreur ;
   • logs, métriques et traces sont visibles dans Grafana ;
   • aucun secret n'est présent dans Git ;
   • les labels (env, service_name) sont cohérents entre signaux.

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