Lorsque j’ai dû réduire le MTTR (Mean Time To Repair) d’une application Node.js en production, j’ai rapidement compris qu’un observability minimal bien pensé vaut mieux qu’un tableau de bord fourre-tout. L’objectif : détecter, comprendre et réparer plus vite. Dans cet article je partage la configuration pragmatique que j’ai retenue — Sentry pour les erreurs et la performance applicative, Prometheus pour les métriques d’infrastructure et d’application, et des traces distribuées (OpenTelemetry + Jaeger/Tempo) pour suivre le parcours d’une requête. Ce trio couvre les trois piliers de l’observabilité : logs/erreurs, métriques et traces.
Pourquoi ces trois outils et pas un tout-en-un ?
J’aime les solutions intégrées, mais en pratique j’ai trouvé qu’un mix ciblé apporte plus de flexibilité :
Chaque outil fait une chose et la fait bien. Ensemble, ils réduisent significativement le temps nécessaire pour localiser la source d’un incident.
Étapes pratiques pour une observability minimale
Voici le plan que j’ai mis en place sur une app Node.js Express, applicable à la plupart des stacks :
1 — Instrumentation des erreurs : Sentry
Pour moi, Sentry est le point de départ. Il regroupe les exceptions, donne le stacktrace, capture le contexte (en-têtes, utilisateur) et permet d’alerter via Slack/Email/PagerDuty.
Dans Node.js j’utilise @sentry/node. La configuration minimale :
Exemple de bootstrap Sentry :
Installation : npm install @sentry/node
Initialisation : Dans index.js — Sentry.init({ dsn: process.env.SENTRY_DSN, tracesSampleRate: 0.2, environment: process.env.NODE_ENV });
Points d’attention :
2 — Exposer des métriques Prometheus
Prometheus excelle pour l’alerting basé sur des seuils et tendances. En Node, j’utilise le package prom-client.
Installation : npm install prom-client
Exemples de métriques à exposer :
Endpoint /metrics à exposer et à protéger (auth ou IP whitelist). Prometheus fera le pull toutes les X secondes.
3 — Traces distribuées : OpenTelemetry + backend de traces
Les traces sont ce qui m’a permis le plus souvent de trouver le coupable (un appel externe lent, un middleware bloquant, une requête DB mal indexée). J’utilise OpenTelemetry JS pour instrumenter automatiquement Express, HTTP et les clients DB.
Principe :
Exemple succinct de setup :
Je veille à propager le traceparent (context propagation). Sentry et OpenTelemetry peuvent être corrélés en ajoutant l’ID de trace aux événements Sentry, ce qui permet de passer d’une erreur agrégée à la trace exacte.
4 — Alerting et dashboards essentiels
Un tableau de bord n’est utile que s’il contient les KPIs qui signalent un incident rapidement. Voici ce que j’affiche en priorité :
| Alert | Règle | Pourquoi |
| HighErrorRate | rate(http_requests_total{status=~"5.."}[5m]) > 0.01 | Montée soudaine d’erreurs |
| HighLatency | histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route)) > 2s | Dégradation perçue |
| HighMemory | node_memory_Active_bytes / node_memory_MemTotal_bytes > 0.9 | Risque d’out-of-memory |
Je fais remonter les incidents critiques sur Slack ou PagerDuty et j’ajoute un playbook basique dans la description de l’alerte (check logs, vérifier la trace, rollback possible?).
5 — Sampling, retention et coût
Le vrai défi en production, c’est le volume. Quelques recommandations :
Ces choix équilibrent visibilité et coût. J’ajuste régulièrement après incidents — le but est d’avoir juste assez de données pour diagnostiquer rapidement.
Bonnes pratiques opérationnelles
Quelques règles que j’applique systématiquement :
En pratique, après avoir déployé ce triptyque (Sentry + Prometheus + Traces), j’ai vu le temps moyen pour localiser la cause d’un incident tomber de plusieurs dizaines de minutes à souvent moins de 10 minutes pour des soucis courants. Ce n’est pas magique : il faut investir dans la mise en place et la maintenance, mais le retour sur temps gagné lors d’incidents est immédiat.
