Explique les pièges de surveiller les métriques d'utilisation des ressources plutôt que la latence ou les taux d'erreur des utilisateurs.
Il est 3h15. Votre téléphone vibre avec un incident haute priorité PagerDuty : CRITIQUE : Utilisation CPU du serveur API > 95 %. Vous ouvrez votre ordinateur portable, consultez le tableau de bord Grafana et remarquez que même si la CPU a fortement grimpé pendant 4 minutes, le taux d'erreurs HTTP 500 est resté à 0 % et la latence de l'API est restée parfaitement stable.
Vous acquittez l'alerte, soupirez profondément et vous rendormez. Vous venez de vivre la définition classique d'une mauvaise alerte.
Pendant des décennies, la surveillance d'infrastructure a fortement reposé sur des métriques d'utilisation comme la CPU et la mémoire. Mais à l'ère des microservices conteneurisés et de l'infrastructure cloud avec autoscaling, alerter sur la consommation des ressources est un anti-pattern. Cet article explore pourquoi.
Pour comprendre pourquoi nous configurons encore des alertes de seuil CPU, il faut revenir à l'ère des serveurs bare-metal. Quand vous aviez un seul serveur de base de données dans un rack, une CPU à 99 % signifiait que la machine n'avait plus aucune marge de calcul. Si le trafic augmentait même légèrement, le serveur s'effondrerait inévitablement.
L'architecture cloud moderne fonctionne différemment. Nous déployons explicitement des groupes d'autoscaling pour maximiser l'utilisation des ressources et réduire les coûts de cloud computing. Si un nœud fonctionne constamment à 40 % de CPU, vous êtes sur-provisionné. Vous voulez en réalité que les nœuds fonctionnent efficacement près de leurs limites, permettant à la mise à l'échelle horizontale de gérer le surplus.
Lorsque votre couche d'orchestration gère l'afflux, une CPU élevée est le signe d'un système sain et rentable — pas une urgence.
Lors de la conception d'une alerte, vous devez différencier la cause d'un problème et le symptôme que les utilisateurs vivent.
Un pic de mémoire élevé est une cause (ou un état sous-jacent). Un utilisateur recevant un 502 Bad Gateway est un symptôme (la vraie douleur).
Si un cron job en arrière-plan consomme 100 % de la CPU d'un nœud pendant deux minutes en analysant un fichier volumineux, mais s'exécute sur une file de workers dédiée, l'utilisateur subit exactement zéro dégradation de performances. Alerter un ingénieur pour cela crée du bruit pur.
À l'inverse, un deadlock dans votre base de données pourrait ne consommer que 5 % de la CPU de la base de données, mais stopper toutes les transactions utilisateur. Si vous n'alertez que sur la CPU, vous manquerez complètement la panne critique.
Examinons trois scénarios courants où des pics d'utilisation des ressources déclenchent des faux positifs :
Dans des langages comme Java ou Go, des pics de mémoire intermittents sont attendus à mesure que les objets sont alloués avant qu'une pause GC les nettoie. Déclencher des alertes de mémoire basées sur ces formes d'onde en dent de scie est notoirement instable.
Une sauvegarde nocturne de base de données ou une rotation de journaux nécessite naturellement un I/O disque et CPU intense. À moins qu'elle ne prévienne les fonctions principales de l'application, elle ne justifie pas une alerte.
Un afflux soudain de connexions sollicitera immédiatement la CPU lors de la négociation des handshakes TLS et du réchauffement des pools de connexions. Tant que l'application se met à l'échelle horizontalement efficacement en quelques minutes, la saturation brève est une procédure opérationnelle standard.
Les alertes de pager doivent être exclusivement réservées aux « Signaux Dorés » : Latence, Trafic, Erreurs et Saturation.
Au lieu de : CPU > 90 %
Alertez sur : Latence P99 > 1500 ms pendant 5 m
Si la CPU atteint 99 % mais que la latence reste prudemment sous votre seuil de 1500 ms, laissez l'Ă©quipe dormir.
Au lieu de : MĂ©moire > 85 %
Alertez sur : Taux d'Erreurs HTTP 5xx > 2 %
Si une fuite mémoire provoque éventuellement des redémarrages de Pods entraînant des requêtes abandonnées, l'alerte sur le taux d'erreurs 5xx capturera le symptôme et alertera l'équipe avec précision.
Les métriques de CPU et de mémoire ne sont pas inutiles — elles ne méritent simplement pas une alerte urgente.
Ces métriques appartiennent à deux endroits :
Cessez de créer des plannings d'astreinte basés sur la santé de l'infrastructure. Construisez-les autour de la santé des utilisateurs. En éliminant les seuils matériels bruts et en s'engageant dans des alertes de latence et d'erreur basées sur les symptômes, les ingénieurs souffrent moins de fatigue et font confiance aux alertes qui se déclenchent réellement.
La transition nécessite une télémétrie externe fiable. Des plateformes comme Heimdall surveillent exactement ce que l'utilisateur vit — appliquant des alertes basées sur les latences HTTP réelles et les capacités de résolution DNS réelles — permettant aux équipes de désactiver en toute sécurité les règles bruyantes de seuil CPU à l'intérieur de leurs clusters.
Rejoignez des milliers d'équipes qui comptent sur Heimdall pour maintenir leurs sites web et API en ligne 24h/24 et 7j/7. Commencez avec notre plan gratuit dès aujourd'hui.
Commencer la surveillance gratuitement
Ingénieur senior en fiabilité des systèmes (SRE) axé sur la disponibilité, la réponse aux incidents et la construction de systèmes de surveillance qui révèlent les problèmes avant que les utilisateurs ne s'en aperçoivent.
