TP : Scraping, relabeling et réception OTLP des métriques

Ce que vous allez apprendre dans ce TP

• Cibler et enrichir une application
• Réduire la cardinalité
• Sécuriser le remote_write
• Recevoir de l'OTLP

Introduction #

Ce que vous allez apprendre dans cette section

• Cibler et enrichir une application
• Réduire la cardinalité
• Sécuriser le remote_write
• Recevoir de l'OTLP

Contexte. Une application métier expose des métriques, mais certaines sont inutiles et un label explose le nombre de séries, ce qui fait grimper la facture du backend. Vous devez filtrer proprement, sécuriser l'envoi et accepter en plus les métriques OpenTelemetry d'une nouvelle équipe.

Prérequis : TP « Premier pipeline » réalisé (stack Prometheus)  ·  Durée estimée : 45 min

Ce TP prolonge la stack du TP précédent (Prometheus + Alloy). Vous maîtrisez le cycle complet : découvrir, filtrer, expédier et interopérer avec OpenTelemetry.

Découverte et scraping #

Cibler une application et enrichir ses labels.

1. 1. Définir des cibles statiques et les enrichir

   Pourquoi ? Ajouter des labels (env, team) dès la découverte permet de filtrer et de facturer par équipe sans modifier l'application.

   Une application expose /metrics sur app:8080. Déclarez-la comme cible, ajoutez les labels env="dev" et team="platform" avec discovery.relabel, puis scrapez-la.

2. 2. Maîtriser la cardinalité

   Pourquoi ? Chaque combinaison de labels est une série stockée : supprimer le bruit à la source coûte moins cher que de payer pour le stocker puis l'ignorer.

   Les métriques go_gc_* sont inutiles ici et le label session_id explose la cardinalité. Insérez un composant prometheus.relabel qui supprime les premières (action drop) et retire le second (labeldrop).

Expédition sécurisée #

Authentification et variables d'environnement.

1. 3. Authentifier le remote_write sans écrire le mot de passe en clair

   Pourquoi ? Un mot de passe dans un fichier versionné est une fuite en puissance : le type secret et les variables d'environnement évitent de l'exposer dans l'UI et les logs.

   Configurez prometheus.remote_write avec basic_auth. Le mot de passe doit être lu depuis PROM_PASSWORD et ne jamais apparaître dans la configuration versionnée. Quelle précaution prendre pour la valeur ?

Interopérabilité OpenTelemetry #

Recevoir de l'OTLP et l'écrire dans Prometheus.

1. 4. Recevoir des métriques OTLP

   Pourquoi ? Les applications modernes émettent de l'OTLP : un récepteur dans Alloy évite de déployer un collecteur supplémentaire et convertit vers votre backend Prometheus existant.

   Ajoutez un otelcol.receiver.otlp (gRPC 4317 et HTTP 4318), un otelcol.processor.batch et un otelcol.exporter.prometheus qui renvoie les métriques vers le remote_write existant. N'oubliez pas de publier les ports dans le Compose.

2. 5. Générer de la télémétrie de test

   Pourquoi ? Un générateur de télémétrie permet de tester le pipeline sans dépendre d'une vraie application et de reproduire facilement un cas.

   Utilisez l'outil telemetrygen d'OpenTelemetry pour envoyer des métriques pendant 30 secondes et retrouvez-les dans Prometheus.

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