Observabilité : logs, métriques et traces pour le debugging en production

Monitoring vs Observabilité

Le monitoring répond à "est-ce que le système fonctionne ?". L'observabilité répond à "pourquoi le système ne fonctionne pas ?". Le monitoring est réactif (alertes quand un seuil est dépassé), l'observabilité est exploratoire (investiguer un problème inconnu a priori).

Les trois piliers

L'observabilité repose sur trois types de données complémentaires qui, corrélés, permettent de diagnostiquer n'importe quel problème.

• Logs : événements textuels horodatés — le "quoi s'est passé". Structurés en JSON pour le parsing automatique.
• Métriques : valeurs numériques agrégées dans le temps — le "combien". Latence P99, taux d'erreur, CPU usage.
• Traces : parcours d'une requête à travers les services — le "où est le bottleneck". Chaque span = une étape.

Stack d'observabilité

Une stack moderne d'observabilité combine plusieurs outils spécialisés.

Métriques : Prometheus (collecte) → Grafana (visualisation)
Logs     : Fluentd/Vector (collecte) → Elasticsearch (stockage) → Kibana (recherche)
Traces   : OpenTelemetry (instrumentation) → Jaeger/Tempo (stockage/visualisation)

Alternative unifiée : Grafana Stack (Mimir + Loki + Tempo + Grafana)

Alerting efficace

Les alertes sont la passerelle entre l'observabilité et l'action. Trop d'alertes = alert fatigue = alertes ignorées. L'objectif est d'alerter uniquement sur les symptômes (latence élevée, taux d'erreur) et non sur les causes (CPU élevé, mémoire).

• Alerter sur les SLO (Service Level Objectives) : "le P99 de latence dépasse 500ms depuis 5 minutes"
• Utiliser des burn rates plutôt que des seuils fixes pour éviter les faux positifs
• Chaque alerte doit avoir un runbook associé : quoi vérifier, quoi faire, qui contacter
• Implémenter des silences programmés pour la maintenance planifiée