Instrumenter son application

Une équipe reprend un service qu'elle n'a pas écrit. Le point de collecte existe, /metrics répond, et il contient quatre cent douze métriques : compteurs de garbage collector, statistiques de pool de connexions, taille des files internes de la bibliothèque HTTP, âge des certificats. Il manque une seule chose : le nombre de commandes qui échouent. Personne, dans cette liste, ne peut répondre à la question que se pose le métier depuis deux jours. L'instrumentation existe, elle est même abondante, et elle est inutile.

Le réflexe inverse est tout aussi coûteux. Instrumenter chaque fonction « au cas où » produit des dizaines de milliers de séries, une facture de stockage qui double chaque trimestre, et une latence supplémentaire mesurable sur les chemins chauds. L'instrumentation utile est un travail de sélection, pas d'exhaustivité : quelques métriques choisies pour répondre à des questions précises valent mieux que tout ce que la bibliothèque cliente sait produire par défaut. Cette leçon donne le critère de sélection, la façon de nommer ce qu'on garde, et l'ordre de grandeur du coût qu'on accepte.