Gouvernance de l'observabilité : coûts, rétention et sécurité

Collecter des traces, des métriques et des logs, c’est essentiel. Mais sans gouvernance, les volumes explosent, les coûts deviennent incontrôlables, et des données sensibles finissent dans des dashboards accessibles à tous. La gouvernance de l’observabilité, c’est l’ensemble des règles qui répondent à quatre questions : combien de temps garder les données, combien ça coûte, qui voit quoi, et comment on nomme les choses. Ce guide vous donne les leviers concrets pour construire un système d’observabilité durable et maîtrisé.

TL;DR

L’observabilité non gouvernée est un poste de coûts qui croît plus vite que votre infrastructure. Les quatre leviers : rétention adaptée par signal, cardinalité sous contrôle, données sensibles masquées avant stockage, et conventions partagées (nommage, labels, niveaux de log). Agir sur un seul de ces leviers peut diviser par deux votre facture ou votre dette technique.

Ce que vous allez apprendre

• Les coûts réels : pourquoi l’observabilité coûte cher et la formule pour l’estimer
• La rétention : combien de temps garder métriques, logs et traces — et pourquoi c’est différent pour chaque signal
• Les politiques par environnement : ce qui change entre dev, staging et production
• La cardinalité : comment une mauvaise combinaison de labels peut faire exploser votre base Prometheus — et comment la budgétiser
• La sécurité des données : PII, secrets, RGPD — ce qui ne doit jamais se retrouver dans vos pipelines, avec des exemples de masquage
• L’accès et le multi-tenant : RBAC, organisations, datasources — qui voit quoi dans Grafana
• Les conventions d’équipe : nommage des métriques, niveaux de log, labels obligatoires — le socle commun qui évite le chaos
• Le RACI : qui décide quoi en matière de gouvernance

Les coûts réels de l’observabilité

L’observabilité suit une loi simple : plus vous collectez, plus longtemps vous conservez, plus souvent vous interrogez — plus ça coûte. Et les volumes croissent naturellement avec l’infrastructure : chaque nouveau service, chaque nouveau pod, chaque nouveau label génère des données supplémentaires.

La formule des coûts

Le coût de votre observabilité est le produit de trois facteurs :

Volume × Rétention × Requêtage = Coût

• Volume : la quantité de données ingérées par jour (Go de logs, nombre de séries temporelles, nombre de spans)
• Rétention : la durée de conservation (7 jours, 30 jours, 1 an)
• Requêtage : la fréquence et la complexité des requêtes sur ces données

Le requêtage est le facteur le moins visible mais souvent le plus coûteux dans les systèmes managés. Trois exemples concrets :

• Alerting toutes les 30 secondes : chaque règle d’alerte évalue une requête à chaque intervalle — 50 règles à 30 s = 144 000 requêtes/jour
• Dashboards surchargés : un dashboard avec 50 panneaux, ouvert par 10 personnes, auto-rafraîchi toutes les 15 s, génère des milliers de requêtes par heure
• Range queries non bornées : une requête PromQL sur 30 jours de données avec une résolution fine (step 15 s) charge des millions de points en mémoire

Chacun de ces trois facteurs est un levier d’optimisation. Réduire la rétention de 30 à 15 jours divise le stockage par deux. Passer le scrape interval de 15 à 30 secondes divise le volume de métriques par deux. Filtrer les logs DEBUG en production réduit le volume de 50 à 80 %.

Qui consomme combien ?

Les trois signaux n’ont pas les mêmes profils de coût :

Signal	Volume relatif	Coût principal	Levier d’optimisation
Logs	Le plus volumineux (1-10 Go/jour par application sous trafic)	Stockage + indexation	Filtrage (niveaux, sampling), rétention courte
Métriques	Compact individuellement, mais la cardinalité (nombre de séries) fait tout	Mémoire + stockage TSDB	Contrôle des labels, agrégation, relabeling
Traces	Variable (dépend du sampling)	Stockage + indexation (span par span)	Taux de sampling (head-based ou tail-based)

Glissez pour voir

L'enquête Grafana Labs 2024

Selon l’Observability Survey 2024 de Grafana Labs, le coût est la préoccupation n°1 des praticiens — devant la complexité des outils et le manque de compétences. Les organisations sans politique de rétention constatent une croissance continue de leur facture, sans amélioration proportionnelle de la visibilité.

Anti-patterns de dashboards

Trois patterns qui font exploser le coût de requêtage :

• Panels “select *” : requête sur toutes les séries d’un namespace sur 30 jours — préférez des filtres explicites et une fenêtre courte (6 h, 24 h)
• Variables non contraintes : un sélecteur $instance sans filtre charge toutes les instances du cluster — limitez avec des regex ou un label scope
• rate() sur des séries trop cardinales : rate(http_requests_total[5m]) avec 100 000 séries (label user_id) charge toutes ces séries en mémoire — agrégez d’abord avec sum by (service)

Rétention : combien de temps garder les données

La rétention est le levier le plus direct sur les coûts. Mais toutes les données n’ont pas la même durée de vie utile. La règle : garder longtemps ce qui sert au capacity planning, garder court ce qui sert au diagnostic.

Recommandations par signal

Signal	Rétention courte (diagnostic)	Rétention longue (tendance)	Pourquoi cette différence
Métriques	15 jours (résolution complète)	1-2 ans (agrégées / downsampled)	Le diagnostic nécessite la résolution fine ; les tendances long terme acceptent un point par heure
Logs	7-30 jours selon le niveau	90 jours pour WARN/ERROR (audit)	Un log DEBUG de la semaine dernière n’a plus de valeur ; un log ERROR peut être requis pour un audit
Traces	7-15 jours	Rarement au-delà (volumétrie trop élevée)	Les traces servent au diagnostic immédiat, pas à l’analyse historique

Glissez pour voir

Le downsampling : garder les tendances sans le coût

Pour les métriques, la technique du downsampling permet de conserver l’historique long terme à moindre coût. Le principe : au-delà d’un seuil (par exemple 15 jours), les points sont agrégés — au lieu d’un point toutes les 15 secondes, vous gardez un point par heure (min, max, moyenne).

Thanos implémente nativement le downsampling via sa compaction, avec trois niveaux de résolution (brute, 5 minutes, 1 heure). Pour les autres systèmes compatibles Prometheus (Cortex, Mimir), les mécanismes varient : Mimir utilise la compaction par blocs et les recording rules pour obtenir un résultat similaire, mais le terme “downsampling” n’est pas toujours employé de la même façon.

Résultat pratique : vous gardez 2 ans de tendances dans un espace de stockage comparable à 2 semaines de données brutes.

Le tiering : niveaux de stockage

Pour les logs et les traces, le tiering de stockage complète le downsampling :

Niveau	Stockage	Accès	Usage
Hot	SSD / stockage rapide	Millisecondes	7-15 derniers jours
Warm	HDD / stockage standard	Secondes	15-90 jours
Cold	Object storage (S3, MinIO)	Minutes	Au-delà de 90 jours (archive)

Glissez pour voir

Le passage hot → warm → cold peut être automatisé (ILM dans Elasticsearch, rétention par blocs dans Loki/Tempo). Le stockage cold en object storage coûte typiquement 10× moins que le stockage hot.

Exemple de politique ILM type :

Donnée	Hot	Warm	Cold	Suppression
Logs DEBUG	3 jours	—	—	3 jours
Logs INFO	7 jours	23 jours	—	30 jours
Logs WARN/ERROR	15 jours	75 jours	275 jours	365 jours
Traces (sampled)	7 jours	8 jours	—	15 jours
Métriques (brutes)	15 jours	—	—	15 jours (puis downsampled)
Métriques (downsampled)	—	350 jours	1 an+	2 ans

Glissez pour voir

Règle pragmatique

Si personne n’a consulté un type de données depuis 30 jours, la rétention est probablement trop longue. Vérifiez les patterns d’accès réels avant de fixer vos durées de rétention.

Politiques par environnement

La gouvernance n’est pas la même en développement et en production. Un environnement de dev a besoin de visibilité maximale pour le debugging, mais ne nécessite ni rétention longue ni protection PII stricte. La production, c’est l’inverse.

Critère	Dev	Staging	Production
Rétention logs	3-7 jours	7-15 jours	15-90 jours (selon niveau)
Rétention métriques	7 jours	15 jours	15 jours brut + downsampling long terme
Rétention traces	3 jours	7 jours	7-15 jours
Niveaux de log	DEBUG activé	INFO + DEBUG ciblé	INFO minimum, WARN/ERROR pour diagnostic
Sampling traces	100 % (tout tracer)	50-100 %	1-10 % (head-based) ou tail-based (erreurs)
Protection PII	Optionnelle (données fictives)	Obligatoire (données proches prod)	Stricte (masquage, audit, RGPD)
Accès (RBAC)	Large (toute l’équipe Editor)	Restreint (équipe + QA)	Strict (Viewer par défaut, Editor ciblé)
Alerting	Désactivé ou minimal	Actif (tests de seuils)	Pleinement opérationnel

Glissez pour voir

Bonne pratique

Configurez ces différences dans le pipeline, pas dans le code. Le Collector OpenTelemetry peut appliquer des règles différentes selon un attribut deployment.environment.name : niveaux de log filtrés, taux de sampling ajusté, processeurs de masquage PII activés ou non.

Cardinalité : le piège des métriques

La cardinalité est le nombre total de séries temporelles distinctes dans votre base. Chaque combinaison unique de nom de métrique + labels crée une série distincte. C’est le facteur qui fait le plus souvent exploser les coûts et les performances des systèmes de métriques.

Pourquoi la cardinalité explose

Prenons une métrique simple :

http_requests_total{method="GET", status="200", service="api"}

Trois labels, des valeurs bornées → quelques dizaines de séries. Ajoutez un label user_id avec 100 000 utilisateurs :

http_requests_total{method="GET", status="200", service="api", user_id="usr_12345"}

Vous passez de quelques dizaines à des centaines de milliers de séries. Multipliez par le nombre de méthodes HTTP, de codes de statut, de services, et le nombre de séries actives explose en produit cartésien :

Nombre de séries = valeurs_label₁ × valeurs_label₂ × … × valeurs_labelₙ

Avec 5 méthodes HTTP × 10 status codes × 20 services × 100 000 user_id, vous obtenez 100 millions de séries. C’est ingérable.

Les labels dangereux

Label	Pourquoi c’est dangereux	Alternative
user_id	Valeurs non bornées (croissance continue)	Logger dans les traces, pas dans les métriques
request_id	Unique par requête → autant de séries que de requêtes	Jamais dans un label de métrique
url_path	Les chemins dynamiques (/users/12345) créent autant de séries que d’utilisateurs	Normaliser : /users/:id
pod_name	Change à chaque redéploiement	Utiliser deployment, namespace
timestamp	Crée une série par instant	Ne jamais utiliser comme label

Glissez pour voir

Budget de cardinalité

Expliquer la cardinalité ne suffit pas — il faut un mécanisme contractuel pour la contrôler dans la durée. Le principe : chaque équipe ou service reçoit un budget de séries actives, avec des seuils d’alerte.

Paramètre	Seuil recommandé	Action si dépassé
Budget par service	2 000 - 10 000 séries actives	L’équipe doit justifier les labels ou en supprimer
Budget par métrique	< 1 000 séries par nom de métrique	Investigation : label non borné probable
Seuil d’alerte global	80 % de la capacité Prometheus	Alerte vers l’équipe plateforme
Arbitrage	—	L’équipe plateforme/SRE arbitre la suppression d’un label si le budget est dépassé

Glissez pour voir

Pour surveiller ces budgets, utilisez ces requêtes Prometheus :

# Nombre total de séries actives
count({__name__=~".+"})

# Top 10 des métriques par nombre de séries
topk(10, count by (__name__)({__name__=~".+"}))

# Séries par service (si le label existe)
count by (service)({__name__=~".+"})

Comment contrôler la cardinalité

1. Mesurez avant d’agir

   Les requêtes ci-dessus vous donnent l’état actuel. Les métriques avec plus de 10 000 séries méritent une investigation.

2. Appliquez le relabeling

   Le metric_relabel_configs de Prometheus permet de supprimer ou réécrire des labels avant l’ingestion. Exemple — supprimer les labels dangereux sur une métrique tierce :

   # prometheus.yml — scrape_configs
   scrape_configs:
     - job_name: "mon-service"
       metric_relabel_configs:
         # Supprimer le label user_id (cardinalité non bornée)
         - source_labels: [user_id]
           regex: ".+"
           action: labeldrop
         # Supprimer le label request_id
         - source_labels: [request_id]
           regex: ".+"
           action: labeldrop
         # Normaliser les chemins dynamiques
         - source_labels: [path]
           regex: "/users/[^/]+"
           target_label: path
           replacement: "/users/:id"

3. Normalisez les chemins dynamiques

   Remplacez /users/12345/orders/67890 par /users/:id/orders/:id dans le label path — au niveau du SDK ou de l’instrumentation, pas dans Prometheus. Le relabeling ci-dessus est un filet de sécurité, pas la solution principale.

4. Revoyez les labels à chaque ajout de métrique

   Avant d’ajouter un label, posez-vous la question : “combien de valeurs distinctes ce label peut-il avoir ?” Si la réponse est “non borné” ou “plus de 1 000”, il ne devrait probablement pas être un label de métrique.

Prometheus et la mémoire

Prometheus stocke toutes les séries actives en mémoire (index inversé + chunks récents). Une explosion de cardinalité se traduit directement par une augmentation de la consommation RAM, puis par un OOM kill. C’est un problème qui ne se voit pas progressivement — il arrive souvent brutalement après un déploiement qui introduit un nouveau label.

Sécurité des données d’observabilité

Les données de télémétrie traversent des pipelines, sont stockées dans des bases partagées et affichées sur des dashboards accessibles à plusieurs équipes. Elles contiennent parfois — involontairement — des informations sensibles.

Données sensibles dans les logs et les traces

Type de donnée	Exemples	Risque	Obligation
PII (données personnelles)	E-mail, nom, adresse IP, numéro de téléphone	Non-conformité RGPD, amendes	Masquer ou pseudonymiser avant ingestion
Secrets	Tokens API, mots de passe, clés privées	Compromission du système	Ne jamais logger — filtrer dans le collecteur
Headers d’authentification	Authorization, Cookie	Usurpation de session	Exclure du champ http.request.header
Données financières	Numéro de carte, IBAN	Violation PCI-DSS	Masquer (****1234) ou exclure
Données médicales	Diagnostics, prescriptions	Violation réglementaire	Exclure complètement

Glissez pour voir

Où masquer les données sensibles

Le masquage doit intervenir le plus tôt possible dans le pipeline — avant le stockage, jamais après :

Niveau	Comment	Avantage
Au code	Ne pas logger la donnée en premier lieu	Solution la plus sûre
Dans le SDK	Processors OTel (redaction, transform)	Masquage avant export
Dans le Collector	Processor transform ou filter	Point central, indépendant du code
Dans l’ingestion	Pipeline Logstash, Loki pipeline stages	Dernier filet de sécurité

Glissez pour voir

Exemple : masquage dans le Collector OpenTelemetry

Le processor transform du Collector permet de supprimer ou masquer des attributs sensibles avant l’export vers le backend :

otel-collector-config.yaml

processors:
  transform:
    trace_statements:
      - context: span
        statements:
          # Supprimer le header Authorization des attributs
          - delete_key(attributes, "http.request.header.authorization")
          # Masquer l'email utilisateur (garder le domaine)
          - replace_pattern(attributes["enduser.email"],
              "^[^@]+", "****")

    log_statements:
      - context: log
        statements:
          # Supprimer les tokens qui auraient été loggés
          - replace_pattern(body,
              "Bearer [A-Za-z0-9\\-._~+/]+=*", "Bearer [REDACTED]")
          # Masquer les adresses email dans le corps
          - replace_pattern(body,
              "[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}",
              "****@****.***")

service:
  pipelines:
    traces:
      processors: [transform, batch]
    logs:
      processors: [transform, batch]

Tester votre pipeline de masquage

Envoyez des données de test contenant des PII connues (e-mail fictif, token factice) et vérifiez qu’elles sont bien masquées dans le backend. Un pipeline de masquage qui n’est pas testé est un pipeline qui ne masque probablement rien.

RGPD et données d'observabilité

Le RGPD s’applique dès qu’une donnée permet d’identifier une personne, directement ou par recoupement. Une adresse IP est une donnée personnelle. Un user_id pseudonymisé est acceptable si la table de correspondance est protégée. Les traces distribuées qui contiennent des attributs utilisateur (e-mail, nom) sont soumises aux mêmes obligations que les bases de données applicatives : base légale, durée de rétention définie, droit à l’effacement.

Checklist sécurité

• Audit régulier : recherchez les patterns sensibles dans vos logs et spans (regex sur e-mails, tokens, numéros de carte)
• Tests de pipeline : envoyez des données de test contenant des PII et vérifiez qu’elles sont masquées en sortie
• Séparation des environnements : les données de production ne doivent pas être accessibles depuis les environnements de développement
• Rétention limitée : plus une donnée contenant des PII est conservée longtemps, plus le risque d’exposition augmente

Accès et multi-tenant : qui voit quoi

Dans une organisation avec plusieurs équipes, chaque équipe ne devrait voir que les données qui la concernent. C’est le principe du multi-tenant : une seule infrastructure d’observabilité, mais des frontières de visibilité entre les équipes.

Permissions dans Grafana

Grafana implémente un modèle de contrôle d’accès à trois niveaux, disponible dans toutes les éditions (OSS, Cloud, Enterprise) :

Niveau	Mécanisme	Ce qu’il contrôle
Organisations	Isolation forte (instances séparées de datasources, dashboards, alertes)	Séparation entre clients / business units
Teams + Folders	Permissions par dossier de dashboards	Séparation entre équipes dans une même organisation
Rôles (Viewer, Editor, Admin)	Actions autorisées par utilisateur ou team	Créer, modifier, voir

Glissez pour voir

En pratique :

• Viewer : consulte les dashboards et explore les données — ne peut rien modifier
• Editor : crée et modifie les dashboards, les alertes, les annotations
• Admin : gère les datasources, les utilisateurs, les permissions

RBAC avancé et LBAC

Au-delà de ce modèle de base, Grafana propose des fonctionnalités avancées selon l’édition. Le RBAC fin (rôles custom, permissions granulaires par ressource) est disponible en Enterprise et Cloud. Le LBAC (Label-Based Access Control) va plus loin : les requêtes sont filtrées automatiquement selon les labels autorisés pour l’utilisateur — par exemple, une équipe ne voit que les métriques dont le label namespace correspond à ses namespaces Kubernetes. C’est le niveau d’isolation nécessaire pour du vrai multi-tenant sur une même instance.

Multi-tenant dans les backends

Le contrôle d’accès dans Grafana ne suffit pas si les backends eux-mêmes ne sont pas multi-tenant. Voici l’état de l’art :

Backend	Multi-tenant natif	Mécanisme
Mimir (métriques)	Oui	Header X-Scope-OrgID — isolation par tenant au stockage
Loki (logs)	Oui	Header X-Scope-OrgID — même principe
Tempo (traces)	Oui	Header X-Scope-OrgID
Prometheus (standalone)	Non	Un Prometheus par tenant, ou Mimir en frontal
Elasticsearch	Via indices + sécurité	Index par tenant + rôles Elasticsearch

Glissez pour voir

X-Scope-OrgID : deux règles d'ops

Le header X-Scope-OrgID est le standard de fait pour le multi-tenant dans l’écosystème Grafana (Mimir, Loki, Tempo). Deux précautions essentielles :

1. Le reverse proxy ou la gateway doit injecter le header — ne laissez jamais le client final le fournir directement
2. Ne faites pas confiance au client : validez ou écrasez le header en bordure (gateway, ingress controller) avant qu’il n’atteigne le backend

La documentation Loki le dit explicitement : en mode multi-tenant, les requêtes sans header valide sont rejetées.

Bonne pratique

Injectez le X-Scope-OrgID dans le Collector OpenTelemetry (processor attributes ou resource) pour router les données vers le bon tenant dès l’ingestion, plutôt qu’au niveau de chaque datasource Grafana.

Conventions d’équipe : le socle commun

Sans conventions partagées, chaque équipe invente son propre schéma de nommage, ses propres labels, ses propres niveaux de log. Le résultat : des dashboards incompatibles, des requêtes qui ne fonctionnent que pour un service, et une corrélation inter-services impossible.

Nommage des métriques

Adoptez les conventions Prometheus/OpenMetrics :

Règle	Exemple correct	Exemple incorrect
snake_case	http_request_duration_seconds	httpRequestDuration
Unité dans le nom	_seconds, _bytes, _total	_ms, _kb, sans unité
Suffixe _total pour les counters	http_requests_total	http_requests
Suffixe _info pour les métadonnées	build_info	build_metadata
Pas de type dans le nom	http_request_duration_seconds	http_request_duration_seconds_histogram

Glissez pour voir

Labels obligatoires

Définissez un socle de labels que tous les services doivent exposer :

Label Prometheus	Attribut OTel (Semantic Conventions)	Usage	Exemple
service	service.name	Identifie le composant émetteur	payment-api
environment	deployment.environment.name	Distingue prod/staging/dev	production
version	service.version	Identifie la version déployée	2.3.1
namespace	k8s.namespace.name	Scope Kubernetes / organisationnel	checkout

Glissez pour voir

Si vous utilisez OpenTelemetry, mappez ces attributs vers les labels Prometheus dans le Collector via le processor resource ou directement dans l’exporteur Prometheus.

Niveaux de log standardisés

Imposez une grille unique à tous les services :

Niveau	Signification	Alerte ?
DEBUG	Détails de développement, désactivé en production	Non
INFO	Événement normal attendu	Non
WARN	Situation anormale mais non bloquante	Monitoring
ERROR	Échec d’une opération, intervention nécessaire	Oui
FATAL	Processus irrécupérable, va s’arrêter	Oui (immédiat)

Glissez pour voir

Règle clé : un ERROR doit toujours être actionnable — si personne ne doit agir, c’est un WARN. Si trop d’ERROR arrivent sans action, le niveau est mal calibré et crée du bruit qui masque les vrais problèmes.

Documentation des conventions

Les conventions ne servent que si elles sont écrites, versionnées et accessibles :

1. Créez un document de référence

   Un fichier OBSERVABILITY-CONVENTIONS.md dans votre repo principal, décrivant les labels obligatoires, les conventions de nommage, les niveaux de log, et les règles de rétention.

2. Automatisez la validation

   Utilisez des linters ou des règles de relabeling dans le Collector pour rejeter les métriques qui ne respectent pas les conventions (label manquant, format incorrect).

3. Revoyez lors des design reviews

   Chaque nouveau service devrait passer par une checklist d’observabilité avant le déploiement : métriques exposées, labels conformes, niveaux de log calibrés.

4. Mesurez la conformité

   Créez un dashboard “health de l’observabilité” qui montre le pourcentage de services conformes, le nombre de séries non étiquetées, le volume de logs par niveau.

RACI de la gouvernance

La gouvernance, c’est aussi qui décide quoi. Sans clarification des responsabilités, les conventions restent des vœux pieux.

Activité	Plateforme / SRE	Équipes dev	Sécurité / Compliance
Politiques de rétention	R (définit et applique)	C (consulté sur besoins)	A (valide conformité RGPD)
Quotas / budgets cardinalité	R (définit les seuils)	I (informé)	—
Pipeline Collector	R (déploie et maintient)	C (remonte les besoins)	A (valide masquage PII)
Instrumentation (métriques, logs)	C (revue de conformité)	R (implémente)	—
Labels et conventions de nommage	R (définit les standards)	R (les applique dans le code)	—
RBAC / accès Grafana	R (gère les rôles)	I (reçoit les accès)	A (audit)
Masquage PII dans le pipeline	R (implémente les processors)	C (signale les champs sensibles)	A (valide, audite)
Alerting (création de règles)	C (revue impact perf)	R (crée les alertes métier)	—
Audit et conformité	I (fournit les données)	I (répond aux questions)	R (exécute les audits)

Glissez pour voir

Légende : R = Responsable (fait), A = Accountable (valide/approuve), C = Consulté, I = Informé.

Bonne pratique

Intégrez ce RACI dans votre document OBSERVABILITY-CONVENTIONS.md. Les rôles doivent être assignés à des équipes, pas à des individus — les personnes changent, les responsabilités restent.

Pièges courants

Piège	Conséquence	Solution
Pas de politique de rétention	Croissance linéaire des coûts sans valeur ajoutée	Définir des durées par signal et par niveau de sévérité
Labels non bornés dans les métriques	Explosion de cardinalité → OOM Prometheus	Pas de user_id, request_id, url_path dynamique dans les labels
Données personnelles dans les logs/traces	Non-conformité RGPD, risque juridique	Masquer au plus tôt (code > SDK > Collector)
Tout le monde Admin dans Grafana	Modifications accidentelles, pas de traçabilité	Viewer par défaut, Editor par équipe, Admin limité
Conventions non documentées	Chaque équipe invente son schéma, corrélation impossible	Fichier de conventions versionné + linter automatisé
Rétention identique pour tous les signaux	Gaspillage (traces gardées 90 jours) ou frustration (métriques supprimées à 7 jours)	Adapter la rétention au cycle de vie de chaque signal
Pas de budget cardinalité	Découverte de l’explosion au moment de l’OOM	Seuils par service, alertes à 80 %, revue lors des design reviews
Pipeline de masquage non testé	Fausse confiance, PII stockées quand même	Tests avec données fictives contenant des patterns sensibles
Même gouvernance pour tous les environnements	Trop restrictif en dev (freine le debug), trop permissif en prod (risque PII)	Politiques différenciées dev/staging/prod

Glissez pour voir

À retenir

1. Le coût de l’observabilité suit la formule Volume × Rétention × Requêtage — agir sur chaque facteur a un impact direct

2. La rétention doit être adaptée au signal : 15 jours de résolution fine pour les métriques, 7-30 jours pour les logs, 7-15 jours pour les traces — avec du downsampling ou du tiering pour le long terme

3. Les politiques varient par environnement : DEBUG et 100 % de traces en dev, rétention calibrée et masquage PII strict en production

4. La cardinalité est le piège n°1 des métriques : un seul label à valeurs non bornées peut provoquer un OOM — budgétisez les séries par service

5. Les données sensibles (PII, secrets, tokens) doivent être masquées le plus tôt possible dans le pipeline — le Collector OTel est le point central pour ça

6. Le RBAC et le multi-tenant garantissent que chaque équipe voit uniquement ses données — le header X-Scope-OrgID est le standard dans l’écosystème Grafana, injecté par la gateway, jamais par le client

7. Les conventions d’équipe (nommage, labels, niveaux de log) sont le socle invisible qui rend tout le reste possible — documentez-les, automatisez leur validation

8. La gouvernance a besoin d’un RACI clair : l’équipe plateforme définit les politiques, les devs instrumentent, la sécurité audite

Sources

• Grafana Labs — Observability Survey 2024 : grafana.com/observability-survey/2024 — état de l’art des pratiques, coûts et tendances
• Prometheus — Storage : prometheus.io/docs/prometheus/latest/storage — fonctionnement de la TSDB et impact de la cardinalité
• Grafana — Roles and permissions : grafana.com/docs/grafana/latest/administration/roles-and-permissions — modèle de permissions (OSS, Enterprise, Cloud)
• Grafana Loki — Multi-tenancy : grafana.com/docs/loki/latest/operations/multi-tenancy — isolation par tenant via X-Scope-OrgID
• OpenTelemetry Semantic Conventions : opentelemetry.io/docs/specs/semconv — conventions de nommage des attributs
• Thanos — Downsampling : thanos.io/tip/components/compact.md — compaction et downsampling natif

Prochaines étapes

OpenTelemetry Le standard d'instrumentation universel — APIs, SDKs, Collector et conventions sémantiques

Corrélation des signaux Relier logs, métriques et traces — le résultat concret des conventions de gouvernance

SLI, SLO et SLA Transformer vos métriques en objectifs de fiabilité avec Error Budget et burn rate

Logs structurés Format, champs essentiels et bonnes pratiques de logging — le signal le plus volumineux

Métriques Counter, gauge, histogram — les types de métriques et le piège de la cardinalité en détail

×

📖 Voir la documentation →