Surveillance et observabilité : bonnes pratiques en matière d'APM, de journalisation et d'alerte

Les entreprises dotées de pratiques d'observabilité matures résolvent les incidents 69 % plus rapidement, selon le rapport sur l'état d'observabilité de Splunk. La surveillance vous indique que quelque chose ne va pas. L'observabilité vous indique pourquoi il est cassé et où chercher. La différence entre lutter contre chaque problème de production pendant des heures et les résoudre en quelques minutes dépend de la façon dont vous instrumentez vos systèmes, structurez vos journaux et concevez vos alertes.

Points clés à retenir

• Les trois piliers de l'observabilité (métriques, journaux et traces) répondent chacun à des questions différentes et travaillent ensemble pour fournir une compréhension complète du système.
• Alerte sur les symptômes (impact face à l'utilisateur) et non sur les causes (métriques internes) pour réduire la fatigue des alertes et détecter les nouveaux modes de défaillance
• La journalisation JSON structurée avec des ID de corrélation permet de rechercher parmi les services et de reconstruire les flux de demandes
• Les SLO (Service Level Objectives) transforment la surveillance de « quelque chose est-il cassé » à « respectons-nous nos engagements envers les utilisateurs »

---

Les trois piliers de l'observabilité

L’observabilité repose sur trois types de données complémentaires. Chaque pilier répond à différentes questions sur le comportement de votre système.

Métriques

Les métriques sont des mesures numériques collectées à intervalles réguliers. Ils répondent aux questions « que se passe-t-il » : combien de requêtes par seconde ? Quel est le temps de réponse moyen ? Quelle quantité de mémoire est utilisée ?

Caractéristiques :

• Agrégé et compact : des millions d'événements compressés dans des compteurs de séries chronologiques
• Peu coûteux à stocker : données de taille fixe quel que soit le volume de trafic
• Idéal pour les tableaux de bord et les alertes
• Contexte limité : vous savez que le temps de réponse a augmenté, mais vous ne savez pas quelles demandes spécifiques sont lentes.

Types de métriques clés :

• Compteur -- valeur croissante de façon monotone (total des requêtes, total des erreurs)
• Gauge -- valeur qui augmente et diminue (utilisation actuelle du processeur, connexions actives)
• Histogramme - distribution des valeurs (centiles de temps de réponse, tailles de charge utile)
• Résumé - centiles pré-calculés côté client

Journaux

Les journaux sont des enregistrements texte horodatés d'événements discrets. Ils répondent aux questions « que s'est-il passé » : quel message d'erreur l'utilisateur a-t-il vu ? Quels paramètres ont été transmis à la fonction défaillante ? Quel était l’état du système lorsque le problème est survenu ?

Caractéristiques :

• Contexte riche – détails arbitraires sur des événements individuels
• Cher à grande échelle : les systèmes à fort trafic génèrent des gigaoctets de journaux par heure - Recherchable : recherchez des événements spécifiques grâce à la recherche en texte intégral
• Nécessite une structure : les lignes de journal non structurées sont difficiles à analyser et à corréler

Traces

Les traces suivent une seule requête sur plusieurs services. Ils répondent aux questions « où est passé le temps » : quel appel de service est lent ? Où le chemin de la requête diverge-t-il ? Quelle requête de base de données constitue le goulot d'étranglement ?

Caractéristiques :

• Montrer la causalité – relations parent-enfant entre les opérations
• Révéler le comportement des systèmes distribués - latence au-delà des limites des services
• Échantillonnage requis à grande échelle : le suivi de chaque demande coûte cher
• Essentiel pour les microservices : sans traces, le débogage des flux multiservices n'est qu'une hypothèse

---

Écosystème d'outils d'observabilité

Choisir une pile

Pour la plupart des entreprises en croissance, nous recommandons de commencer par :

1. Sentry pour le suivi des erreurs : détecte les exceptions avec des traces de pile complètes, des cartes sources et un suivi des versions
2. Prometheus + Grafana pour les métriques – écosystème d'intégration étendu, open source et testé au combat
3. Journalisation structurée vers un service géré -- Datadog Logs, AWS CloudWatch ou Grafana Loki selon votre fournisseur de cloud
4. OpenTelemetry pour l'instrumentation – norme indépendante du fournisseur qui fonctionne avec n'importe quel backend

Pour les équipes qui souhaitent un fournisseur unique, Datadog offre la meilleure expérience tout-en-un, mais à un coût important à grande échelle. La pile open source de Grafana (Prometheus, Loki, Tempo) offre des fonctionnalités équivalentes avec un coût de licence inférieur mais une charge opérationnelle plus élevée.

---

Meilleures pratiques de journalisation structurée

Les lignes de journal non structurées comme Error processing order 12345 for user [email protected] sont lisibles par l'homme mais hostiles à la machine. Les journaux JSON structurés permettent la recherche, le filtrage, l'agrégation et l'alerte sur des champs spécifiques.

Structure du journal

Chaque entrée de journal doit inclure :

ID de corrélation

Un ID de corrélation est un identifiant unique généré au début de chaque demande et transmis à chaque appel de service en aval, requête de base de données et tâche en arrière-plan. Lors de l'enquête sur un problème, la recherche par ID de corrélation affiche chaque entrée de journal liée à cette demande spécifique dans tous les services.

Mise en œuvre : Générez un UUID au niveau de la passerelle API ou de l'équilibreur de charge, transmettez-le dans l'en-tête X-Request-ID et incluez-le dans chaque entrée de journal. Dans NestJS, utilisez un middleware qui extrait ou génère l'ID de corrélation et le stocke dans le contexte de stockage local asynchrone.

Niveaux de journalisation

Utilisez les niveaux de journalisation de manière cohérente :

• DEBUG -- informations de diagnostic détaillées, désactivées en production sauf en cas de débogage actif
• INFO -- événements commerciaux significatifs (commande passée, utilisateur enregistré, paiement traité)
• WARN -- situations inattendues que le système a gérées mais qui doivent faire l'objet d'une enquête (nouvelle tentative réussie, échec du cache, appel d'API obsolète)
• ERROR - échecs ayant affecté l'expérience utilisateur (échec de la demande, paiement refusé, service externe indisponible)
• FATAL -- l'application ne peut pas continuer (base de données inaccessible, configuration requise manquante)

Conservation des journaux et gestion des coûts

Les journaux sont les données d’observabilité les plus coûteuses à stocker. Mettre en œuvre une rétention à plusieurs niveaux :

• Stockage à chaud (30 jours) - recherche en texte intégral, requêtes rapides, coût élevé - Stockage à chaud (90 jours) – requêtes compressées et plus lentes, coût modéré
• Stockage frigorifique (1 an+) -- archivé, requête à la demande, faible coût
• Journaux de débogage -- ne pas stocker en production sauf en cas de dépannage actif

---

Conception d'alerte

Les mauvaises alertes créent une lassitude face aux alertes : les équipes cessent de répondre aux alertes car la plupart sont des faux positifs ou des bruits de faible priorité. Une bonne alerte fait apparaître de véritables problèmes qui nécessitent une intervention humaine.

Alerte sur les symptômes, pas sur les causes

Alerte basée sur les symptômes (bonne) : "Le taux d'erreur sur /api/orders a dépassé 1 % pendant 5 minutes" : cela indique directement l'impact sur l'utilisateur, quelle que soit la cause sous-jacente.

Alerte basée sur la cause (mauvaise) : "Le processeur de la base de données a dépassé 90 %" : cela peut affecter ou non les utilisateurs. La base de données peut très bien gérer 95 % du processeur, ou elle peut être à 50 % du processeur mais complètement bloquée.

Les métriques basées sur les causes appartiennent aux tableaux de bord à des fins d'investigation, et non aux règles d'alerte.

Niveaux de gravité des alertes

Réduire le bruit des alertes

1. Alertes liées au groupe -- si la base de données tombe en panne, vous recevez une alerte « base de données indisponible », et non 50 alertes de chaque service qui en dépend 2. ** Exiger une violation soutenue ** – « CPU supérieur à 90 % pendant 5 minutes » et non « CPU supérieur à 90 % pendant 1 seconde » pour éviter les pics transitoires.
2. Résolution automatique : les alertes devraient s'effacer automatiquement lorsque la condition est résolue.
3. Examen hebdomadaire des alertes : examinez toutes les alertes déclenchées, identifiez et corrigez ou faites taire celles qui n'ont pas nécessité d'action humaine.
4. Boucle de rétroaction sur appel : après chaque rotation d'astreinte, l'ingénieur documente quelles alertes étaient exploitables et lesquelles nécessitent un réglage.

---

SLO : objectifs de niveau de service

Les SLO transforment la surveillance de réactive ("quelque chose est cassé, réparez-le") à proactive ("nous consommons notre budget d'erreurs, enquêtons avant que les utilisateurs ne s'en aperçoivent").

Définir les SLO

Un SLO définit la fiabilité cible d'un service. Il se compose de :

- SLI (Service Level Indicator) – la métrique mesurée (taux de réussite des requêtes, centile de latence)

• Target - le seuil qui définit des performances acceptables (taux de réussite de 99,9 %, P95 inférieur à 200 ms) - Fenêtre - la période sur laquelle la cible est évaluée (30 jours glissants)

Exemples de SLO pour une plateforme de commerce électronique

Budgets d'erreur

Le budget d’erreur est l’inverse de votre objectif SLO. Un SLO de 99,9 % autorise 0,1 % d'erreurs, soit environ 43 minutes d'arrêt par mois. Lorsque le budget d’erreurs est épuisé, l’équipe se concentre davantage sur les fonctionnalités que sur la fiabilité.

Les budgets d'erreur fournissent un langage partagé entre les équipes d'ingénierie et de produit. Au lieu de débattre pour savoir si un service est « suffisamment fiable », les deux équipes peuvent voir exactement combien de marge d'erreur il reste et prendre des décisions fondées sur les données concernant la fourniture de nouvelles fonctionnalités ou l'investissement dans la stabilité.

---

Questions fréquemment posées

Combien coûte l'observabilité à grande échelle ?

Les coûts d'observabilité varient de 10 à 50 $ par hôte et par mois pour les piles open source (Prometheus, Grafana, Loki) à 30 à 100 $ et plus par hôte pour les solutions commerciales (Datadog, New Relic). Le principal facteur de coût est le volume des journaux : optimisez-le en échantillonnant les journaux de débogage, en compressant les journaux stockés et en définissant des périodes de conservation appropriées. Pour la plupart des entreprises de moins de 50 serveurs, le coût est compris entre 500 et 2 000 $ par mois.

Dois-je utiliser OpenTelemetry ou des agents spécifiques au fournisseur ?

Utilisez OpenTelemetry. Il s'agit de la norme industrielle en matière d'instrumentation, prise en charge par tous les principaux fournisseurs d'observabilité, et évite la dépendance vis-à-vis d'un fournisseur. Vous pouvez changer de backend (de Datadog à Grafana, par exemple) sans réinstrumenter votre code. Les agents spécifiques au fournisseur offrent parfois une intégration plus poussée, mais le compromis en matière de portabilité n'en vaut pas la peine.

Comment configurer la surveillance d'une application NestJS ?

Dans NestJS, utilisez des intercepteurs pour la synchronisation des requêtes, des filtres d'exception pour le suivi des erreurs et un middleware pour la propagation des ID de corrélation. Intégrez Sentry avec @sentry/nestjs pour le suivi des erreurs. Exportez les métriques Prometheus avec la bibliothèque prom-client exposée sur un point de terminaison /metrics. Utilisez la journalisation structurée avec nestjs-pino ou winston configuré pour la sortie JSON.

Quelle est la différence entre la surveillance et l'observabilité ?

La surveillance vous indique quand des problèmes prédéfinis se produisent (CPU élevé, taux d'erreur en hausse, disque plein). L'observabilité vous permet de poser de nouvelles questions sur le comportement du système sans déployer de nouvelles instruments. Un système est observable lorsque vous pouvez comprendre son état interne à partir de ses sorties externes (métriques, journaux, traces). En pratique, une bonne surveillance est un sous-ensemble de l’observabilité.

Comment convaincre mon équipe d'investir dans l'observabilité ?

Suivez le temps moyen de résolution (MTTR) des incidents de production avant et après les améliorations de l’observabilité. Les équipes avec une bonne observabilité réduisent généralement le MTTR de 60 à 70 %. Multipliez le temps gagné par les coûts d’ingénierie pour afficher le retour sur investissement. Suivez également le nombre d'incidents détectés par la surveillance par rapport aux rapports des utilisateurs : la détection proactive renforce la confiance des clients.

---

Quelle est la prochaine étape

Commencez par le suivi des erreurs (Sentry) si vous n'avez rien : il fournit la valeur la plus immédiate en détectant et en alertant sur les erreurs de production. Ensuite, ajoutez une journalisation structurée avec des ID de corrélation. Implémentez ensuite la collecte de métriques avec les tableaux de bord Prometheus et Grafana. Enfin, ajoutez un traçage distribué lorsque vous disposez de plusieurs services.

Pour le contexte complet de l'ingénierie des performances, consultez notre guide des piliers sur [la mise à l'échelle de votre plateforme d'entreprise] (/blog/scaling-business-platform-performance). Pour optimiser l'infrastructure sur laquelle veille votre surveillance, lisez notre guide de mise à l'échelle de l'infrastructure.

ECOSIRE implémente des piles d'observabilité pour les plateformes métiers fonctionnant sur Odoo ERP et des architectures personnalisées. Contactez notre équipe DevOps pour une évaluation de surveillance et d'observabilité.

---

Publié par ECOSIRE — aider les entreprises à évoluer grâce à des solutions basées sur l'IA dans Odoo ERP, Shopify eCommerce et OpenClaw AI.