Qu'est-ce que le monitoring ?
Le monitoring (surveillance) est la pratique de collecter, agreger et analyser en temps réel les données de fonctionnement des systèmes informatiques. L'objectif est de détecter les problèmes avant qu'ils n'impactent les utilisateurs, de comprendre les performances du système, et de faciliter le diagnostic en cas d'incident. Le monitoring est un pilier de la fiabilité des systèmes en production.
Les trois piliers de l'observabilité
Métriques
Les métriques sont des mesures numériques echantillonnees dans le temps : CPU, mémoire, latence des requêtes, taux d'erreur, nombre de connexions. Elles répondent a "que se passe-t-il ?". Les outils principaux sont Prometheus (collecte et stockage de métriques, PromQL), Grafana (visualisation, dashboards), Datadog (plateforme SaaS complete), et CloudWatch (natif AWS).
Logs
Les logs sont des enregistrements textuels d'événements discrets : erreurs, requêtes, actions utilisateur. Ils répondent a "pourquoi cela s'est-il passe ?". La centralisation est essentielle : ELK Stack (Elasticsearch, Logstash, Kibana), Loki (par Grafana, léger), Datadog Logs, ou CloudWatch Logs. Les logs structures (JSON) facilitent la recherche et l'analyse.
Traces distribuees
Les traces suivent une requête à travers les différents services d'une architecture distribuee. Elles répondent a "ou est le problème ?". Chaque service ajoute un span avec les détails de son traitement. Jaeger, Zipkin, et OpenTelemetry (standard ouvert) sont les outils de référence. Les traces sont indispensables dans les architectures microservices pour identifier les goulots d'etranglement.
Alerting et on-call
Le monitoring sans alerting est inutile. Les alertes doivent être actionnables (pas de bruit), contextualisees (inclure les informations nécessaires au diagnostic), et priorisees (critique vs warning). Les canaux : PagerDuty, OpsGenie, Slack, SMS. Les bonnes pratiques : alerter sur les symptomes (latence elevee) plutôt que les causes (CPU eleve), utiliser des seuils dynamiques, et définir des runbooks (procédure de résolution) pour chaque alerte.
Métriques clés (Golden Signals)
Les Four Golden Signals de Google SRE sont les métriques essentielles : Latency (temps de réponse), Traffic (volume de requêtes), Errors (taux d'erreur), Saturation (utilisation des ressources). Pour les applications web, les Core Web Vitals (LCP, FID, CLS) mesurent l'expérience utilisateur réelle. Les SLI/SLO/SLA définissent les objectifs de fiabilité (99.9% de disponibilité = 8.7 heures de downtime par an).