Quels sont les quatre signaux d'or, et lequel instrumenteriez-vous en premier sur un service tout neuf ?

La latence, le trafic, les erreurs et la saturation. La latence, c'est le temps que prennent les requêtes, en séparant les appels réussis des appels en échec. Le trafic, c'est la demande, par exemple les requêtes par seconde. Les erreurs, c'est le taux de requêtes en échec, y compris celles qui renvoient un 200 avec un corps cassé. La saturation, c'est le niveau de remplissage de votre ressource la plus contrainte. Instrumentez les erreurs et la latence en premier, parce qu'elles correspondent directement à la douleur de l'utilisateur.

Latence, trafic, erreurs, saturation. Sur un nouveau service, je câblerais d'abord les erreurs et la latence, parce que ce sont les deux qu'un utilisateur peut ressentir, et je m'assurerais que les histogrammes de latence soient séparés par issue. Ça nous a servi une fois : notre p99 s'est amélioré après un mauvais déploiement, et c'était uniquement parce qu'une partie des requêtes échouaient en 12ms au lieu de réussir en 800ms. Le trafic vient ensuite, surtout parce qu'il donne du contexte à tous les autres signaux, et qu'il permet de repérer une chute à zéro, l'alerte que les gens oublient d'écrire. La saturation est celle qui demande une vraie réflexion. Pour une API sans état, c'était en général notre pool de connexions à la base plutôt que le CPU, donc on exportait le temps d'attente sur le pool et les connexions en cours d'usage. Le CPU générique des nœuds ne nous a jamais rien appris d'utile. Une fois ces quatre en place, tout le reste est un raffinement plutôt qu'un nouveau tableau de bord.