À quoi ressemble une bonne observabilité pour un service dont vous êtes responsable ?

Vous devez pouvoir répondre à des questions que vous n'aviez pas anticipées. Ça veut dire des logs structurés avec un identifiant de trace sur chaque ligne, des métriques couvrant le débit, les erreurs et la durée plus la saturation de vos ressources clés, et des traces distribuées qui suivent une requête d'un service à l'autre. Les alertes se déclenchent sur des symptômes visibles par l'utilisateur et rattachés à vos objectifs de niveau de service, les tableaux de bord partent de l'expérience client, et tous les signaux partagent des labels cohérents pour pouvoir passer de l'un à l'autre.

Le test que j'utilise, c'est de savoir si je peux répondre à une question que personne n'avait imaginée quand le service a été construit, par exemple pourquoi les requêtes sont lentes seulement pour un client sur un endpoint. Pour y arriver, les trois signaux doivent être reliés. Chaque ligne de log est structurée et porte l'identifiant de trace, comme ça depuis une trace lente je saute directement aux logs de cette requête au lieu de grepper par horodatage. Les métriques couvrent le débit, les erreurs et la durée de chaque endpoint en percentiles plutôt qu'en moyennes, plus la saturation des choses qui s'épuisent vraiment : pools de connexions, profondeur de file, disque. Les traces sont échantillonnées, mais je garde toujours les erreurs et la queue lente, parce que la requête moyenne ne m'apprend rien. Les alertes, c'est la partie que les gens ratent : j'alerte sur les symptômes que les clients ressentent, rattachés à l'objectif, pas sur un CPU à quatre-vingts pour cent. Et je surveille le coût, parce que mettre un identifiant utilisateur dans un label de métrique, c'est comme ça qu'une facture de deux cents dollars devient six mille du jour au lendemain ; le détail par utilisateur a sa place dans les traces et les logs.