Le vrai test de la surveillance n'est pas le dashboard
N'importe quelle équipe sait faire des dashboards. Le vrai test d'un système de surveillance, c'est 3 h du matin quand le pager sonne : l'ingénieur sait-il exactement quoi faire, ou passe-t-il 20 minutes à fouiller des graphes hors-sujet ? Si c'est le second cas, votre monitoring est du théâtre.
Ce guide est un parcours structuré d'un monitoring qui ne crie pas au loup : quatre signaux d'or en fondation, SLI/SLO/error budgets en clair, règles d'hygiène des alertes et checklist d'audit du monitoring existant.
Plan
- Les quatre signaux d'or
- SLI, SLO et error budgets sans jargon
- Hygiène des alertes — les règles qui protègent les humains
- Logs vs métriques vs traces : quand utiliser quoi
- Monitoring synthétique et RUM
- Choisir une pile d'outils
- Une astreinte saine pour petite équipe
- Checklist d'audit du monitoring existant
1. Les quatre signaux d'or
Pour chaque service exposé aux utilisateurs, mesurez d'abord ces quatre — et rien d'autre :
- Latence — temps pour servir une requête réussie. p50, p95, p99.
- Trafic — requêtes par seconde, ou équivalent métier (commandes/min).
- Erreurs — taux de requêtes en échec, par catégorie.
- Saturation — niveau de remplissage (CPU, RAM, profondeur de file, pools).
Ces quatre bien réglés couvrent 80 % des incidents. N'ajoutez les métriques d'infrastructure (disque, réseau, santé hôte) que lorsqu'elles prédisent un impact métier.
2. SLI, SLO et error budgets en clair
- SLI est ce que vous mesurez : « % de requêtes sous 300 ms ».
- SLO est la cible : « 99,5 % des requêtes sous 300 ms sur 30 jours ».
- Error budget est ce que vous avez le droit de dépenser : 0,5 % ici.
Les error budgets ne sont pas une punition. Ils rendent explicite l'arbitrage entre fiabilité et vélocité produit. Budget consommé du mois : on gèle les nouveautés et on investit dans la stabilité — décision de leadership, pas drame d'ingénieur.
3. Hygiène des alertes — règles qui protègent les humains
- Chaque alerte exige un runbook. Sinon c'est un ticket, pas une alerte.
- Chaque alerte réveille un humain ou va en backlog. Pas de troisième catégorie.
- Alertes sur taux de variation plutôt que seuils fixes, quand les baselines sont propres.
- Alertes symptômes avant alertes causes. « Le service ne répond pas » bat « CPU > 80 % ».
- Revue hebdomadaire des 5 alertes les plus bruyantes — en désactiver ou en tuner trois.
Une équipe paged deux fois par semaine sur de vrais incidents actionnables est en meilleure santé qu'une équipe paged 30 fois sur du bruit.
4. Logs vs métriques vs traces
| Signal | Idéal pour | Mauvais pour |
|---|---|---|
| Métriques | Alerting, SLOs, dashboards | Pourquoi une requête précise a échoué |
| Logs | Forensic, audit, debug | Dashboards à forte cardinalité (coût explose) |
| Traces | Root cause de latence inter-services | Stockage long-terme économe |
Ne loggez pas ce qui doit être une métrique. Ne tracez pas ce qui doit être un log.
5. Monitoring synthétique et RUM
Le synthétique (checks scriptés depuis l'externe chaque minute) attrape les pannes et expirations de certificats avant les utilisateurs. Le RUM dit ce que les utilisateurs vivent vraiment — réseaux lents et vieux navigateurs que votre staging n'a pas.
Lancez les deux. Alertez depuis le synthétique. Investiguez depuis le RUM.
6. Choisir une pile d'outils
Pas de pile uniquement correcte. Matrice honnête :
- Prometheus + Grafana + Loki + Tempo — meilleur TCO pour les équipes avec un ingénieur qui aime opérer. Pire pour celles sans.
- Zabbix — fort pour infrastructure-lourd, on-premise, parcs Linux/Windows mélangés. Plus faible côté application.
- Datadog / New Relic / Dynatrace — time-to-value le plus rapide, prix affiché élevé, verrouillage par modèle de données. Souvent correct pour 20–100 personnes qui ne veulent pas opérer la plateforme.
- Natif hyperscaler (CloudWatch, Azure Monitor, GCP Cloud Monitoring) — pratique, faible en cross-cloud ou cross-on-prem.
Trois critères : TCO 3 ans (temps ingénieur inclus), portabilité des données, l'astreinte veut-elle vraiment utiliser l'outil ?
7. Une astreinte saine pour petite équipe
- Au minimum deux ingénieurs d'astreinte. Un seul est SPOF humain.
- Primary tourne chaque semaine. Secondary couvre le primary. Pas de héros 24/7 à pager unique.
- Réunion de passation chaque lundi : incidents ouverts, alertes les plus bruyantes, à fixer cette semaine.
- Politique de compensation écrite.
- Après chaque incident : postmortem cinq lignes dans des docs partagés. Blameless, centré systèmes.
8. Checklist d'audit du monitoring existant
- Les quatre signaux d'or sont-ils en place pour chaque service exposé ?
- Chaque alerte active a-t-elle un runbook écrit ?
- Volume d'alertes hebdo vs incidents nécessitant un humain ?
- Quand le dernier monitor synthétique de votre flow critique a-t-il réussi ?
- Logs et métriques au même endroit (au moins même UI) ?
- Votre outil coûtera-t-il toujours ce qu'il doit dans 12 mois à croissance prévue ?
- L'astreinte est-elle documentée, compensée et sans SPOF ?
Une réponse non immédiate à l'une d'elles indique où commencer.
À retenir
- Construisez sur les quatre signaux d'or, pas sur des trivia d'infrastructure.
- Les error budgets sont une conversation de leadership sur vélocité vs fiabilité.
- Chaque alerte exige runbook et action ; tout le reste est un ticket.
- Logs, métriques et traces se complètent — jamais ne se substituent.
- Le choix d'outil est une décision TCO 3 ans, pas une checkbox de fonctionnalités.
Pour une revue externe de votre monitoring contre cette checklist, contactez-nous — vous parlerez à un ingénieur, pas à un commercial.