3 min de lecture

L’essentiel en bref

• L’observabilité va au-delà de la surveillance : elle ne se contente pas de détecter les problèmes connus, mais permet de comprendre les problèmes inconnus.
• Les trois types de signaux — métriques, journaux (logs) et traces — forment ensemble la triade de l’observabilité.
• OpenTelemetry est la norme neutre en matière de collecte de données de télémétrie.
• Le suivi distribué (Distributed Tracing) visualise les chemins des requêtes à travers les microservices.
• Les coûts des plateformes d’observabilité peuvent atteindre 5 à 15 % des coûts d’infrastructure cloud.

---

La surveillance répond à la question : Mon système fonctionne-t-il ? L’observabilité répond à la question : Pourquoi ne fonctionne-t-il pas ? Dans les systèmes cloud distribués composés de centaines de microservices, la surveillance classique ne suffit plus. L’observabilité — la combinaison de métriques, journaux et traces — rend les systèmes complexes déboguables.

De la surveillance à l’observabilité

La surveillance classique vérifie des états connus : utilisation du processeur, consommation de mémoire, codes d’état HTTP. Les tableaux de bord affichent du rouge ou du vert. Cela fonctionne pour les applications monolithiques aux modes de défaillance prévisibles.

Dans les architectures basées sur les microservices, cette approche échoue : un appel API lent peut être causé par un service surchargé situé à trois sauts de distance. Les tableaux de bord CPU affichent du vert sur tous les services — le problème réside dans les interactions. L’observabilité permet de poser au système des questions arbitraires, sans avoir besoin de les définir à l’avance.

La triade de l’observabilité : métriques, journaux, traces

Les métriques sont des séries temporelles numériques : taux de requêtes, latence (p50, p95, p99), taux d’erreurs, profondeur de file d’attente. Prometheus s’est imposé comme standard de fait, complété par Grafana pour la visualisation. Les métriques répondent à la question : Qu’est-ce qui se passe en ce moment ?

Les journaux (logs) sont des entrées textuelles fournissant du contexte : messages d’erreur, journaux d’audit, informations de débogage. La journalisation structurée (JSON plutôt que texte libre) rend les logs exploitables par machine. ELK (Elasticsearch, Logstash, Kibana), Loki et Datadog Logs sont des plateformes courantes. Les journaux répondent à la question : Qu’est-ce qui s’est produit ?

Les traces suivent une requête à travers tous les services concernés. Chaque saut est documenté sous forme de « span », avec les durées, le nom du service et des métadonnées. Jaeger, Zipkin et Datadog APM permettent de visualiser les diagrammes temporels des traces. Les traces répondent à la question : Où se situe le problème ?

OpenTelemetry : la norme universelle

Avant l’existence d’OpenTelemetry, chaque outil d’observabilité créait une dépendance vis-à-vis d’un fournisseur : agent Datadog, agent New Relic, OneAgent de Dynatrace — tous basés sur une instrumentation propriétaire. Changer d’outil impliquait de réinstrumenter l’intégralité du code.

OpenTelemetry (OTel) résout ce problème en tant que norme indépendante des fournisseurs. L’application est instrumentée une fois avec les SDK OTel et peut envoyer des données de télémétrie à n’importe quelle solution compatible — Grafana Cloud, Datadog, Honeycomb, Jaeger. Le collecteur OTel reçoit, traite et exporte les données de manière flexible.

OTel est un projet du CNCF soutenu par tous les grands éditeurs d’outils d’observabilité. La recommandation est claire : toute nouvelle instrumentation doit toujours utiliser OpenTelemetry, jamais des agents propriétaires.

Maîtriser les coûts

Les coûts de l’observabilité peuvent exploser. Des factures Datadog de 50 000+ Euro par mois ne sont pas rares dans les entreprises de taille moyenne. Les facteurs responsables : chaque entrée de log, chaque métrique et chaque trace génère des coûts d’ingestion et de stockage.

Stratégies d’optimisation des coûts : Échantillonnage (Sampling) – ne pas tracer chaque requête, mais le faire de manière intelligente (le Tail-Based Sampling ne trace que les requêtes atypiques). Gestion des niveaux de logs – les logs de débogage uniquement en développement, niveau Info en production. Politiques de rétention – déplacer ou supprimer les logs et traces après 30 jours vers un stockage froid.

Les stacks open source (Prometheus + Grafana + Loki + Tempo) éliminent les coûts de licence, mais nécessitent un effort opérationnel accru. Le compromis : SaaS (plus cher, moins de travail) contre auto-hébergé (moins cher, plus d’effort opérationnel).

Alerting : l’essentiel au bon moment

Trop d’alertes est pire que pas d’alertes – la fatigue d’alerte fait que les alertes critiques passent inaperçues. Bonne pratique : baser les alertes sur des SLO (objectifs de niveau de service), pas sur des métriques isolées.

Au lieu de déclencher une alerte sur « CPU > 80 % » (souvent inoffensif), on définit : « 99 % des requêtes doivent être traitées en moins de 200 ms ». Lorsque le budget d’erreur est épuisé, le système alerte – indépendamment que la cause soit la CPU, la mémoire ou un service externe. Des outils comme Sloth et Pyrra automatisent l’alerting basé sur les SLO à partir de Prometheus.

Questions fréquentes

Quel est le coût d’une plateforme d’observabilité ?

Les solutions SaaS (Datadog, New Relic, Dynatrace) coûtent typiquement 5 à 15 % des coûts d’infrastructure cloud. Pour une dépense cloud de 100 000 €/mois, cela représente 5 000 à 15 000 €/mois. Les stacks open source (Prometheus + Grafana + Loki) éliminent les coûts de licence, mais nécessitent 0,5 à 1 ETP pour leur exploitation.

OpenTelemetry est-il prêt pour la production ?

Oui. Les traces et métriques sont stables (GA) depuis 2023. Les logs ont atteint le statut GA en 2024. Tous les grands éditeurs d’observabilité prennent en charge OTel. Recommandation : démarrer systématiquement les nouveaux projets avec OTel. Migrer progressivement les instrumentations existantes.

Quelle quantité de trafic faut-il tracer ?

Pas tout. Le Tail-Based Sampling ne trace que les requêtes inhabituelles – latence élevée, erreurs, chemins rares. Cela réduit le volume de données de 90 à 99 % avec une perte d’information minimale. Le Head-Based Sampling (par exemple 10 % de toutes les requêtes) est plus simple, mais moins intelligent.

Quelle plateforme d’observabilité est la meilleure ?

Cela dépend du contexte. Datadog offre la meilleure expérience tout-en-un, mais est coûteux. Grafana Cloud est plus économique et compatible open source. Honeycomb excelle pour l’exploration basée sur les requêtes. Pour les petites équipes : Grafana Cloud en version gratuite ou un stack Prometheus + Grafana auto-hébergé.

L’observabilité est-elle nécessaire pour les monolithes ?

Oui, mais moins critique que pour les microservices. Les métriques et les logs suffisent souvent pour les monolithes. Les traces deviennent pertinentes dès que le monolithe appelle des services externes (base de données, APIs, files de messages). Le démarrage via Prometheus + Grafana est pertinent pour tout stack technologique.

Source de l’image principale : Pexels / AS Photography

Lectures recommandées par la rédaction

• Lenovo ThinkCentre M75q Tiny Gen 5 : mini-PC entreprise avec AMD PRO et 5 watts au repos, idéal pour Edge et kiosque
• L’IA serverless est-elle surévaluée ? Voici ce qui compte vraiment à la place
• QNAP TS-464 : NAS 4 baies avec Docker, HDMI et emplacement PCIe – ce que Synology n’offre pas dans cette gamme

Plus du réseau MBF Media

SecurityToday | MyBusinessFuture | Digital Chiefs