Observabilité : métriques, logs et traces avec Prometheus et Grafana

Métriques, logs et traces : maîtriser Prometheus, Grafana, Loki et OpenTelemetry pour construire une observabilité cloud-native robuste, conforme NIS2/DORA.

Marc Aubert 1 juin 2026 · Mis à jour le1 juin 2026 par Marc Aubert

L’observabilité est devenue un prérequis opérationnel pour toute organisation gérant des systèmes distribués. La multiplication des microservices, des environnements Kubernetes et des pipelines CI/CD a rendu le monitoring traditionnel par seuils insuffisant pour diagnostiquer des incidents complexes. Face à cette réalité, la combinaison Prometheus et Grafana s’est imposée comme la référence open source dans l’écosystème cloud-native, portée par la CNCF (Cloud Native Computing Foundation). Cet article pose les bases architecturales et les bonnes pratiques opérationnelles pour les équipes IT qui souhaitent construire ou consolider leur socle d’observabilité.

Les trois piliers de l’observabilité

L’observabilité d’un système repose sur trois types de signaux complémentaires : métriques, logs et traces. Certains référentiels industriels ajoutent un quatrième signal, les événements (Events), pour former l’acronyme MELT (Metrics, Events, Logs, Traces), mais les trois piliers restent la base de tout dispositif opérationnel.

Métriques : données numériques agrégées dans le temps (compteurs, jauges, histogrammes). Elles permettent de mesurer l’état d’un système à un instant T (CPU, latence, taux d’erreur HTTP) et sont idéales pour l’alerting sur des tendances.
Logs : enregistrements textuels horodatés d’événements discrets. Ils fournissent le contexte détaillé d’une anomalie mais génèrent des volumes importants qui nécessitent une gestion rigoureuse.
Traces distribuées : représentation du chemin d’une requête à travers plusieurs services. Indispensables en architecture microservices pour identifier quel composant introduit de la latence ou des erreurs.

La corrélation de ces trois signaux constitue la valeur ajoutée d’une plateforme d’observabilité mature. Identifier une dégradation via une métrique (p99 de latence en hausse), naviguer vers les logs correspondants, puis tracer la requête défaillante à travers les services : c’est ce parcours d’investigation que les outils modernes doivent faciliter.

Architecture Prometheus : collecte et stockage des métriques

Prometheus adopte une architecture de collecte en pull : le serveur Prometheus interroge périodiquement les endpoints /metrics exposés par les cibles instrumentées. Ce modèle présente des avantages en termes de contrôle centralisé et de sécurité, mais implique que chaque composant doit exposer ses métriques dans le format Prometheus (texte, exposition HTTP).

Composants clés

Composant	Rôle	Notes de sécurité
Prometheus Server	Scraping, stockage TSDB local, évaluation des règles	Pas d’auth native, proxy obligatoire
Alertmanager	Routage et déduplication des alertes	Sécuriser l’API HTTP, TLS recommandé
Exporters (Node, Blackbox, MySQL…)	Instrumentation des cibles tierces	Exposer uniquement sur interfaces internes
Pushgateway	Collecte pour jobs éphémères (batch)	Surface d’attaque accrue, usage limité
Thanos / Mimir	Rétention longue, fédération multi-cluster	Chiffrement TLS inter-composants obligatoire

Le stockage local de Prometheus est une base de données temporelle (TSDB) optimisée pour les lectures et écritures à haute fréquence. La rétention par défaut est de 15 jours. Pour les environnements soumis à des obligations de traçabilité (NIS2, DORA, ISO 27001), un remote storage vers Thanos ou Mimir est indispensable.

PromQL : le langage de requête

PromQL (Prometheus Query Language) est un langage fonctionnel spécialement conçu pour les séries temporelles. Quelques patterns courants en environnement de production :

# Taux d'erreur HTTP 5xx sur les 5 dernières minutes
rate(http_requests_total{status=~"5.."}[5m])

# Disponibilité d'un service (SLI)
1 - (rate(http_requests_total{status=~"5.."}[30d]) / rate(http_requests_total[30d]))

# P99 de latence
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

La maîtrise de PromQL est un investissement rentable : les équipes qui définissent leurs SLI (Service Level Indicators) directement en PromQL bénéficient d’alertes cohérentes avec leurs engagements de service.

Grafana : visualisation et corrélation multi-sources

Grafana est un outil de visualisation qui agrège des données issues de sources hétérogènes. Sa force réside dans sa capacité à corréler en un seul tableau de bord des métriques Prometheus, des logs Loki, des traces Tempo et des données de n’importe quelle source via ses nombreux plugins de datasource.

Gestion des droits et sécurité

En contexte multi-équipes, la configuration RBAC de Grafana est un point critique. Grafana propose un RBAC granulaire permettant de définir des permissions au niveau des tableaux de bord, des dossiers et des datasources. Les recommandations opérationnelles incluent :

Intégrer Grafana avec le SSO d’entreprise (OIDC, SAML, LDAP) pour éviter la gestion de comptes locaux.
Activer l’audit log Grafana ([log] level = info, [unified_alerting] avec traçabilité des modifications).
Restreindre l’accès aux datasources sensibles : une équipe applicative n’a pas forcément à interroger les métriques d’infrastructure bas niveau.
Stocker les credentials des datasources dans un gestionnaire de secrets externe (HashiCorp Vault, Kubernetes External Secrets) plutôt qu’en clair dans la base de données Grafana.

Loki pour les logs

Grafana Loki est une solution de centralisation de logs conçue pour s’intégrer nativement avec Grafana. Contrairement à Elasticsearch, Loki n’indexe que les labels (métadonnées) et stocke le contenu des logs brut, ce qui réduit considérablement les coûts de stockage. L’agent de collecte recommandé pour les nouveaux déploiements est Grafana Alloy (successeur de Promtail depuis 2024, qui assure également la collecte de métriques et de traces) ou l’OpenTelemetry Collector. Ils poussent les logs vers Loki en annotant chaque flux avec des labels (pod, namespace, application, environnement).

L’intégration Loki-Grafana permet de naviguer directement depuis une métrique Prometheus dégradée vers les logs correspondants, réduisant le temps de diagnostic (MTTR).

SRE et SLO : traduire les objectifs métier en alertes

Le cadre SRE (Site Reliability Engineering), formalisé par Google dans son SRE Book, apporte une méthodologie pour structurer l’observabilité autour d’objectifs mesurables.

SLI (Service Level Indicator) : métrique qui mesure le comportement d’un service du point de vue de l’utilisateur (disponibilité, latence, taux d’erreur).
SLO (Service Level Objective) : cible pour un SLI (exemple : disponibilité >= 99,9% sur 30 jours glissants).
Error Budget : marge d’erreur consommable avant de violer un SLO. Quand le budget est épuisé, les nouvelles fonctionnalités sont gelées au profit de la fiabilité.

Dans Prometheus, les alertes basées sur les error budgets (“burn rate alerts”) sont plus pertinentes que les alertes sur des seuils statiques : elles signalent une consommation anormalement rapide du budget d’erreur, permettant d’anticiper une violation de SLO avant qu’elle ne se produise. La spécification officielle de ces alertes est documentée dans le projet open source SLO Generator.

OpenTelemetry : vers une instrumentation standardisée

OpenTelemetry (OTel) est le projet CNCF qui standardise la collecte et l’export de la télémétrie applicative. Son adoption croissante dans les environnements cloud-native modifie l’architecture de collecte :

Instrumentation auto : les SDKs OTel (Java, Python, Go, Node.js…) permettent une instrumentation sans modification du code source pour les frameworks courants.
OpenTelemetry Collector : agent/agrégateur qui reçoit les données (métriques, logs, traces) au format OTLP et les exporte vers les backends cibles (Prometheus via prometheusremotewrite, Loki, Tempo, Jaeger, Datadog…).
Réduction du vendor lock-in : en adoptant OTel pour l’instrumentation, l’équipe conserve la liberté de changer de backend de stockage sans ré-instrumenter les applications.

Pour les DSI souhaitant standardiser leur approche, OTel est aujourd’hui en état de production (graduated CNCF project) et constitue une base solide pour une stratégie d’observabilité durable.

Intégration dans un contexte Kubernetes

En environnement Kubernetes sécurisé en production, l’observabilité prend une dimension supplémentaire. Le stack kube-prometheus (qui regroupe Prometheus Operator, Alertmanager, Grafana et un ensemble de règles d’alerte préconfigurées) est le point de départ recommandé.

Points de vigilance spécifiques à Kubernetes :

Network Policies : restreindre le trafic de scraping Prometheus aux seuls namespaces cibles. Prometheus ne doit pas pouvoir atteindre n’importe quel endpoint du cluster.
ServiceMonitor et PodMonitor : les ressources custom du Prometheus Operator permettent de déclarer les cibles de scraping de façon déclarative, sans modifier la configuration centrale.
Secrets et ConfigMaps : ne jamais stocker des credentials d’exporters dans des ConfigMaps non chiffrées. Utiliser des Secrets Kubernetes avec chiffrement at-rest activé (EncryptionConfiguration), ou des solutions comme Sealed Secrets / External Secrets Operator.
Ressources et limites : Prometheus peut consommer des volumes importants de mémoire en fonction du nombre de séries actives (cardinalité). Définir des resources.limits et surveiller le compte de séries via prometheus_tsdb_head_series.

La consultation de l’infrastructure de référence CNCF et des guides de sécurisation Kubernetes de l’ANSSI est recommandée pour les environnements sensibles.

Conformité et rétention : les exigences réglementaires

La directive NIS2 (UE 2022/2555) et le règlement DORA (UE 2022/2554) imposent aux organisations des obligations en matière de journalisation et de traçabilité des incidents, sans fixer de durée de rétention précise dans leurs textes. C’est l’ANSSI qui, dans ses préconisations de sécurité relatives aux systèmes de journalisation, recommande une rétention minimale de 12 mois pour les logs de sécurité, portée à 24 mois pour les environnements critiques. Ces recommandations s’appliquent directement aux plateformes d’observabilité :

Intégrité des logs (signature, protection contre l’altération).
Rétention minimale de 12 mois pour les logs de sécurité (recommandation ANSSI), alignée avec les attentes des contrôleurs NIS2/DORA.
Séparation des droits entre les équipes qui produisent les logs et celles qui les consultent.
Centralisation sur une plateforme distincte des systèmes supervisés pour résister à un incident de sécurité.

Les plateformes comme Grafana Loki ou Elasticsearch, couplées à un stockage objet immuable (S3 Object Lock, Azure Immutable Blob Storage), permettent de répondre à ces exigences sans surcoût prohibitif.

Conclusion opérationnelle

La mise en place d’une observabilité efficace avec Prometheus et Grafana n’est pas un projet ponctuel mais une discipline continue. Les équipes les plus matures combinent une instrumentation standardisée via OpenTelemetry, des alertes structurées autour des SLO, une corrélation métriques-logs-traces en un seul plan de contrôle, et une gouvernance des accès cohérente avec les exigences de sécurité. Pour les DSI et RSSI, l’enjeu est de transformer ces outils techniques en levier de pilotage de la fiabilité : moins de bruit d’alerte, des MTTR réduits, et une capacité à démontrer la conformité opérationnelle face aux référentiels comme NIS2 ou DORA.

Pour approfondir les aspects de sécurisation de l’infrastructure sous-jacente, la page infrastructure IT et les guides sur cloud et cybersécurité entreprise complètent ce panorama.

Questions fréquentes

Quelle est la différence entre Prometheus et un outil comme Datadog pour l'observabilité ?

Prometheus est open source, auto-hébergé, sans coût de licence, avec un modèle pull qui donne un contrôle total sur la collecte. Datadog est une offre SaaS facturée à l'host ou à l'ingestion, avec moins de friction opérationnelle initiale mais un risque de coûts exponentiels à grande échelle et un vendor lock-in fort sur l'instrumentation. Pour les équipes ayant les compétences pour opérer le stack, Prometheus/Grafana offre un TCO inférieur et une conformité plus simple sur la localisation des données (RGPD, secteur public).

Comment éviter l'explosion de cardinalité dans Prometheus ?

La cardinalité est le nombre de séries temporelles uniques, déterminé par le produit des valeurs de chaque label. Les erreurs courantes : utiliser une valeur d'URL brute (milliers de combinaisons), des identifiants d'utilisateur ou des UUID comme labels. Les règles : ne jamais utiliser de valeurs à cardinalité illimitée comme labels, surveiller `prometheus_tsdb_head_series` et `prometheus_tsdb_head_chunks`, définir des `recording rules` pour pré-agréger les séries fréquentes, et activer des limites de scraping via `sample_limit` par target.

Promtail est-il encore recommandé pour envoyer des logs vers Loki ?

Promtail est en maintenance depuis 2024 au profit de Grafana Alloy, le successeur unifié (métriques, logs, traces, profiling en un seul agent). Pour les nouveaux déploiements, Grafana Alloy ou l'OpenTelemetry Collector sont les choix recommandés. Promtail reste fonctionnel pour les déploiements existants mais ne recevra plus de nouvelles fonctionnalités ; planifier une migration est pertinent dans le cadre d'une revue d'infrastructure.

Quelles sont les obligations de journalisation imposées par NIS2 et DORA ?

NIS2 (directive UE 2022/2555) impose aux entités essentielles et importantes de mettre en place des mesures de journalisation et de détection des incidents, sans fixer de durée précise dans le texte de la directive. DORA (règlement UE 2022/2554) impose une traçabilité des incidents liés aux TIC dans le secteur financier. C'est l'ANSSI qui, dans son guide de préconisations sur les systèmes de journalisation, recommande une rétention minimale de 12 mois pour les logs de sécurité. Ces durées peuvent être portées à 24 mois pour les environnements critiques.