Observabilité moderne : au-delà du monitoring traditionnel

Vos clients détectent les problèmes avant vous ?

Si la réponse est oui, vous avez un problème d’observabilité. Le monitoring classique — un dashboard avec des courbes de CPU et de RAM — ne suffit plus. Les architectures distribuées, les microservices, le serverless ont rendu les systèmes trop complexes pour être surveillés avec des métriques d’infrastructure.

L’observabilité moderne change la question. Le monitoring demande : “est-ce que ça marche ?”. L’observabilité demande : “pourquoi est-ce que ça ne marche pas ?”. La différence semble subtile. En pratique, elle change tout.

Monitoring vs Observabilité : le changement de paradigme

Le monitoring traditionnel

Le monitoring vérifie des conditions connues. CPU > 80% ? Alerte. Disque > 90% ? Alerte. Service HTTP down ? Alerte. Vous définissez à l’avance ce que vous surveillez. Si le problème n’est pas dans votre liste de checks, vous ne le voyez pas.

Ce modèle fonctionne pour les architectures simples. Un monolithe sur 3 serveurs, ça se monitore avec Nagios et un café.

L’observabilité

L’observabilité permet d’explorer les problèmes inconnus. Vous ne savez pas à l’avance quelle question poser. Un utilisateur signale une lenteur intermittente. Avec l’observabilité, vous pouvez naviguer des métriques globales vers la requête spécifique, puis vers la trace distribuée, puis vers le log de l’appel de base de données qui prend 3 secondes au lieu de 30 millisecondes.

Un système est observable quand vous pouvez comprendre son état interne à partir de ses sorties externes, sans avoir à déployer du nouveau code.

C’est la définition de la théorie du contrôle, adaptée au software. Et elle implique quelque chose de fondamental : l’instrumentation doit être en place avant que le problème survienne.

Les trois piliers de l’observabilité

Pilier 1 : Les métriques

Les métriques sont des valeurs numériques agrégées dans le temps. Taux de requêtes, latence P50/P95/P99, taux d’erreur, utilisation mémoire, nombre de connexions actives.

Les métriques répondent à la question “quoi”. Le taux d’erreur a augmenté. La latence P99 a doublé. Le throughput a chuté.

Les bonnes pratiques :

• Adoptez la méthode RED pour les services : Rate (débit), Errors (taux d’erreur), Duration (latence)
• Adoptez la méthode USE pour les ressources : Utilization, Saturation, Errors
• Stockez les histogrammes, pas les moyennes. La moyenne est un mensonge statistique qui masque les outliers
• Définissez des métriques custom métier : nombre de commandes par minute, montant du panier moyen, taux de conversion. Ce sont ces métriques qui comptent vraiment

Pilier 2 : Les logs

Les logs sont des événements horodatés émis par les applications. Un log raconte ce qui s’est passé à un instant précis : une requête reçue, une erreur capturée, une transaction terminée.

Les logs répondent à la question “quand et où”. L’erreur s’est produite à 14h32, dans le service de paiement, sur le pod payment-7f8d9.

Les bonnes pratiques :

• Logs structurés (JSON), jamais du texte libre. Un log structuré est requêtable, un log texte est une perte de temps
• Correlation ID systématique. Chaque requête entrante reçoit un ID unique qui se propage à tous les services. Sans ça, reconstituer une transaction dans 15 services est impossible
• Niveaux de log respectés : ERROR pour les erreurs impactant l’utilisateur, WARN pour les dégradations, INFO pour les événements métier, DEBUG désactivé en production
• Pas de données sensibles dans les logs. Les PII, tokens, mots de passe n’ont rien à faire dans les logs. C’est une faille de sécurité et une violation RGPD

Pilier 3 : Les traces distribuées

Les traces suivent le parcours d’une requête à travers tous les services. Une trace est composée de spans : chaque span représente une opération (un appel HTTP, une query SQL, un message publié dans une queue).

Les traces répondent à la question “pourquoi”. La requête a mis 3 secondes parce que l’appel au service d’inventaire a mis 2.8 secondes, dont 2.5 secondes sur une query SQL non indexée.

Les bonnes pratiques :

• Instrumentez tous les points d’entrée et de sortie : HTTP, gRPC, SQL, Redis, queues, appels externes
• Utilisez l’échantillonnage intelligent (tail-based sampling) : gardez 100% des traces en erreur et lentes, échantillonnez les traces normales
• Liez les traces aux logs et métriques via le trace ID. C’est la corrélation qui donne toute sa puissance à l’observabilité

OpenTelemetry : le standard qui unifie tout

OpenTelemetry (OTel) est devenu le standard de fait pour l’instrumentation. Soutenu par la CNCF, adopté par tous les vendors (Datadog, Grafana, New Relic, Dynatrace), il fournit :

• Des SDKs pour tous les langages majeurs (Java, Python, Node.js, Go, .NET, Rust)
• L’auto-instrumentation : ajoutez un agent, vos frameworks sont instrumentés automatiquement (Express, Django, Spring, gRPC)
• Un protocole standard (OTLP) pour exporter les données vers n’importe quel backend
• Le Collector : un pipeline de données qui reçoit, transforme et exporte la télémétrie

L’avantage stratégique d’OTel est le découplage. Vous instrumentez une fois avec OTel, vous changez de backend quand vous voulez. Fini le lock-in sur un vendor de monitoring.

Architecture OTel recommandée

L’architecture que nous déployons systématiquement :

1. Applications instrumentées avec les SDKs OTel (auto-instrumentation + instrumentation custom pour la logique métier)
2. OTel Collector déployé en sidecar ou en DaemonSet, qui reçoit la télémétrie, l’enrichit (ajout de labels Kubernetes, sampling), et l’exporte
3. Backend de stockage et visualisation (Grafana stack ou Datadog)

Le Collector est la pièce centrale. Il permet de transformer les données (redacter des PII, enrichir avec des métadonnées), de router (les traces vers Tempo, les métriques vers Prometheus, les logs vers Loki), et de buffer en cas d’indisponibilité du backend.

Comparatif des stacks

Grafana Stack (open source)

• Prometheus pour les métriques
• Loki pour les logs
• Tempo pour les traces
• Grafana pour la visualisation et les alertes

Avantages : open source, pas de coût de licence, communauté massive, chaque composant est best-in-class dans sa catégorie. Inconvénients : c’est vous qui opérez. Le sizing, le stockage, la haute disponibilité, les mises à jour — tout est à votre charge. Comptez 0.5 à 1 ETP pour opérer une stack Grafana en production.

Pour qui : les équipes avec des compétences infra solides et un souci de maîtrise des coûts. Idéal si vous dépensez plus de 5 000 euros par mois chez un vendor et que vous avez les compétences pour opérer.

Datadog

Solution SaaS tout-en-un : métriques, logs, traces, profiling, RUM, synthetics, security, dans une seule interface.

Avantages : corrélation native entre tous les signaux, installation simple (un agent), pas d’infra à gérer, UX exceptionnelle. Inconvénients : le coût. La facturation par host, par million d’événements, par Go ingéré peut exploser rapidement. Comptez 30 à 50 euros par host par mois pour la suite complète, plus les coûts de logs.

Pour qui : les équipes qui veulent de l’observabilité complète sans investir dans l’opérationnel. Le ROI est bon si la réduction du MTTR (temps de résolution) justifie le coût.

Elastic Stack (ELK)

Elasticsearch + Kibana pour les logs, avec APM pour les traces et les métriques.

Avantages : puissance de recherche full-text inégalée sur les logs, écosystème mature. Inconvénients : Elasticsearch est gourmand en ressources (RAM, stockage), la gestion des index demande de l’expertise, et le modèle de licence a créé de l’incertitude. Pour les nouvelles architectures, Loki a largement remplacé ELK pour les logs.

SLOs, SLIs et Error Budgets

L’observabilité sans objectifs mesurables est du tourisme technique. Les SLOs (Service Level Objectives) donnent un cadre décisionnel.

SLI (Service Level Indicator)

Le SLI est la métrique qui mesure la qualité du service. Exemples :

• Taux de requêtes HTTP réussies (status < 500) sur le total des requêtes
• Latence P99 des requêtes de recherche
• Taux de disponibilité du checkout

SLO (Service Level Objective)

Le SLO est l’objectif sur le SLI. Exemples :

• 99.9% des requêtes réussies sur 30 jours (budget : 43 minutes de downtime)
• P99 de latence < 500 ms pour 99% des fenêtres de 5 minutes
• 99.95% de disponibilité du checkout

Error Budget

L’error budget est la marge entre la perfection (100%) et votre SLO. Avec un SLO de 99.9%, votre error budget est de 0.1% — environ 43 minutes par mois.

L’error budget change les conversations. Quand le budget est consommé, on ralentit les déploiements et on investit dans la fiabilité. Quand il reste du budget, on accélère les livraisons. C’est un outil de décision, pas juste un nombre.

Les alertes qui ne brûlent pas les équipes

L’alert fatigue est un problème majeur. Quand chaque jour apporte 50 alertes dont 45 sont des faux positifs, les équipes ignorent les alertes. Et le jour où une vraie alerte arrive, personne ne réagit.

Les règles d’or

Chaque alerte doit être actionnable. Si l’alerte se déclenche et que la réponse est “on attend et on voit”, ce n’est pas une alerte, c’est du bruit. Supprimez-la.

Alertez sur les symptômes, pas sur les causes. Le CPU à 90% n’est pas un problème si les utilisateurs ne sont pas impactés. Le taux d’erreur qui passe de 0.1% à 5% est un problème. Alertez sur le taux d’erreur.

Alertez sur les SLOs. Les alertes basées sur le burn rate de l’error budget sont les plus pertinentes. Si vous consommez votre error budget mensuel en 1 heure, c’est une alerte critique. Si vous le consommez en 3 jours, c’est une alerte de warning.

Deux niveaux maximum. Page (réveille quelqu’un) et ticket (à traiter dans les 24h). Tout le reste est du monitoring passif consultable sur dashboard.

Structure d’une bonne alerte

Une alerte efficace contient :

• Quoi : quel service est impacté et quel SLO est menacé
• Impact : combien d’utilisateurs sont affectés
• Runbook : lien vers la procédure de diagnostic et de remédiation
• Dashboard : lien direct vers le dashboard contextualisé

Sans runbook, l’alerte est inutile à 3h du matin quand l’astreinte décroche et ne connaît pas le service.

Le tracing distribué en pratique

Dans une architecture microservices, une requête utilisateur traverse 5, 10, parfois 20 services. Sans tracing distribué, identifier le service responsable d’une lenteur ou d’une erreur est un cauchemar.

Le propagation context

Le principe est simple : chaque requête entrante reçoit un trace ID unique. Ce trace ID est propagé dans les headers HTTP, les messages de queue, les appels gRPC. Chaque service crée un span avec le trace ID, enregistre ses opérations, et l’envoie au backend de traces.

Avec OpenTelemetry, la propagation est automatique pour les frameworks instrumentés. Le format standard est W3C Trace Context (header traceparent).

Ce que le tracing révèle

• Les goulots d’étranglement : quel service prend le plus de temps dans la chaîne
• Les appels N+1 : un service qui fait 100 requêtes SQL au lieu d’une
• Les dépendances cachées : un service qui appelle un autre service dont personne ne connaissait l’existence
• Les retry storms : un service en erreur qui déclenche des cascades de retries dans toute l’architecture

La gestion des coûts d’observabilité

L’observabilité coûte cher. Les logs sont le premier poste. Un cluster Kubernetes de taille moyenne génère facilement 100 Go de logs par jour. À 0.10 euro par Go ingéré chez un vendor, ça fait 3 000 euros par mois juste pour les logs.

Stratégies de réduction

Échantillonnage des traces : gardez 100% des traces en erreur et des traces lentes. Échantillonnez 1 à 10% des traces normales. Le tail-based sampling du Collector OTel est idéal pour cela.

Filtrage des logs : tous les logs ne méritent pas d’être stockés. Les logs de debug, les health checks, les logs de load balancer ont rarement de la valeur. Filtrez-les au niveau du Collector.

Agrégation des métriques : réduisez la cardinalité. Une métrique avec 10 000 valeurs de labels uniques coûte 10 000 fois plus qu’une métrique avec un seul label. Surveillez la cardinalité comme un poste de coût.

Rétention différenciée : logs détaillés conservés 7 jours, métriques agrégées conservées 13 mois, traces conservées 7 jours. Adaptez la rétention à la valeur.

Par où commencer

Si vous partez de zéro, voici un plan pragmatique :

1. Semaine 1-2 : Déployez OpenTelemetry avec l’auto-instrumentation sur vos services principaux. Exportez vers Grafana Cloud (tier gratuit) ou un backend de votre choix.
2. Semaine 3-4 : Définissez 3 SLOs sur vos services critiques (disponibilité, latence, taux d’erreur). Configurez les alertes basées sur le burn rate.
3. Mois 2 : Ajoutez l’instrumentation custom pour les métriques métier. Mettez en place les dashboards par service avec les métriques RED.
4. Mois 3 : Activez le tracing distribué complet. Liez traces, logs et métriques via le correlation ID. Formez les équipes à l’investigation avec les traces.

L’observabilité est un investissement continu, pas un projet avec une date de fin. Chaque incident est une opportunité d’améliorer l’instrumentation.

FAQ

Quelle est la différence concrète entre monitoring et observabilité ?

Le monitoring vérifie des conditions prédéfinies (CPU > 80%, service down) et alerte quand elles sont violées. Il répond à des questions connues. L’observabilité permet d’investiguer des problèmes inconnus en corrélant métriques, logs et traces. Concrètement, avec du monitoring, vous savez que votre service est lent. Avec l’observabilité, vous pouvez naviguer jusqu’à la query SQL non indexée dans le troisième microservice de la chaîne qui cause la lenteur. L’observabilité ne remplace pas le monitoring, elle le complète en ajoutant la capacité d’investigation.

Datadog ou Grafana Stack : comment choisir ?

Le choix dépend de trois facteurs : budget, compétences et taille de l’équipe. Datadog est le choix optimal si votre équipe est petite (moins de 5 devs), si vous n’avez pas de compétences infra dédiées, et si le budget le permet (comptez 30 a 50 euros par host par mois). La Grafana stack (Prometheus, Loki, Tempo, Grafana) est le choix optimal si vous avez les compétences pour l’opérer, si vous voulez maîtriser les coûts à grande échelle, et si vous voulez éviter le vendor lock-in. Le point de bascule financier se situe généralement autour de 20 hosts : en dessous, Datadog est souvent plus économique (TCO incluant le temps d’opération) ; au-dessus, la Grafana stack devient plus rentable.

Comment mettre en place OpenTelemetry sans tout casser ?

L’approche progressive est la clé. Commencez par l’auto-instrumentation (un agent ou un SDK ajouté sans modifier le code applicatif) sur un seul service non critique. Validez que les données arrivent dans votre backend. Puis étendez service par service. L’auto-instrumentation OTel couvre automatiquement les frameworks HTTP, les clients SQL, les clients Redis, et les clients gRPC. L’impact sur les performances est minime (1 a 3% de overhead CPU). L’instrumentation custom (métriques métier, spans additionnels) vient dans un second temps, quand l’équipe est familière avec les outils.

Comment éviter l’alert fatigue ?

Trois règles strictes. Premièrement, chaque alerte doit être actionnable : si personne ne sait quoi faire quand elle se déclenche, supprimez-la. Deuxièmement, alertez sur les symptômes utilisateur (taux d’erreur, latence) et non sur les causes infra (CPU, RAM) : un CPU à 90% sans impact utilisateur n’est pas une urgence. Troisièmement, basez vos alertes sur les SLOs et le burn rate de l’error budget plutôt que sur des seuils fixes. Cette approche réduit typiquement le volume d’alertes de 80% tout en augmentant la pertinence. Dernier conseil : faites une revue mensuelle de toutes les alertes. Celles qui n’ont jamais été actionnées dans les 90 derniers jours sont candidates à la suppression.