Pourquoi votre dashboard de monitoring vous ment

Vous avez investi 50 000€ dans Datadog. Vous avez 200 dashboards. Et pourtant, vous découvrez les incidents par Twitter. Voici pourquoi votre monitoring vous ment.

Mensonge n°1 : les dashboards sont à jour

Vos dashboards affichent des données des 5 dernières minutes. Mais les alertes qui les alimentent sont configurées sur des seuils de 15 minutes. Entre le moment où un problème commence et le moment où le dashboard le montre, il y a un décalage. Vous regardez le passé, pas le présent.

Mensonge n°2 : tous les services sont monitorés

Vous pensez que tous vos services sont monitorés. En réalité, le service critique que personne ne veut maintenir n'a pas d'agent Datadog. Le legacy qui fait tourner 30% du CA n'est pas instrumenté. Les dashboards montrent les services modernes, pas les services importants.

Mensonge n°3 : les SLOs sont respectés

Votre SLO est 99.9% d'uptime. Votre dashboard montre 99.95%. Tout va bien. Sauf que le calcul exclut les maintenances planifiées, les déploiements, et les "incidents mineurs". En réalité, le SLO réel est 99.5%. Le dashboard ment par omission.

Mensonge n°4 : les alertes fonctionnent

Vous avez 500 alertes. La plupart sont en "warning" permanent. Votre équipe les ignore. Les alertes critiques sont noyées dans le bruit. Le jour où une vraie alerte critique arrive, personne ne la voit. Votre monitoring crie "loup" si souvent que quand le loup arrive, personne n'écoute.

Mensonge n°5 : la couverture est complète

Vous monitorez CPU, mémoire, disque, réseau. Mais vous ne monitorez pas : le taux de réussite des paiements, le temps de chargement perçu par l'utilisateur, le nombre de paniers abandonnés. Vous monitorez l'infrastructure, pas le business. Et c'est le business qui souffre quand l'infrastructure va mal.

Comment réparer

1. Réduire les alertes de 90%. Gardez seulement les alertes qui sont (a) critiques pour le business et (b) actionables. Tout le reste est du bruit.

2. Monitorer le business, pas juste l'infrastructure. Le taux de conversion, le temps de checkout, le nombre d'erreurs de paiement. Ce sont ces métriques qui vous disent si vos utilisateurs sont satisfaits.

3. Calculer les SLOs honnêtement. Inclure les maintenances, les déploiements, les incidents mineurs. Un SLO honnête vaut mieux qu'un SLO flatteur.

4. Instrumenter le legacy. Le service que personne ne veut toucher est souvent le plus critique. Mettez-y un agent de monitoring. Mieux vaut un monitoring imparfait que pas de monitoring.

5. Tester les alertes. Déclenchez volontairement une alerte en production (chaos engineering). Vérifiez que quelqu'un la voit, la comprend, et sait quoi faire. Si non, votre système d'alerte est défaillant.

Votre monitoring vous ment parce que vous l'avez configuré pour vous rassurer, pas pour vous informer. Changez de perspective : configurez-le pour vous alerter, pas pour vous flatter.