La méthode RED pour les services pilotés par requêtes, avec des exemplaires reliant un bucket lent à une trace

Objectif

Donner à chaque service piloté par requêtes les trois mêmes signaux, afin que les tableaux de bord, les alertes et les questions d'incident se ressemblent à travers l'architecture : Rate (requêtes par seconde), Errors (requêtes en échec) et Duration (durée des requêtes) — la méthode RED, que l'article de blog Grafana cité attribue à Tom Wilkie comme pendant orienté microservices de la méthode USE, qui s'applique aux ressources matérielles.

Prérequis

Une bibliothèque de métriques dotée de compteurs et d'histogrammes, des gabarits de route à faible cardinalité, et éventuellement une configuration de traçage dont les ID de trace peuvent être attachés aux observations de métriques.

Étapes

1. Pour chaque service, exposer un compteur <svc>_requests_total{route, method, code} incrémenté à la fin de chaque requête, et un histogramme <svc>_request_duration_seconds avec les mêmes étiquettes. Les erreurs se dérivent de code (5xx, ou une étiquette d'échec propre au domaine) plutôt que d'un compteur séparé susceptible de dériver par rapport au total.
2. Construire une ligne de tableau de bord par service : taux de requêtes, ratio d'erreurs (erreurs divisées par le total sur la même fenêtre), et centiles de durée tirés de l'histogramme. Ordonner les lignes selon le flux de données, de sorte que la ligne du dessus soit l'appelant de la ligne du dessous.
3. Alerter sur le ratio d'erreurs et sur l'objectif de durée, pas sur le taux ; les variations de taux ne sont que du contexte.
4. Attacher des exemplaires. OpenMetrics définit un exemplaire comme une référence à des données extérieures au jeu de métriques, le plus souvent un ID de trace, composée d'un jeu d'étiquettes et d'une valeur avec un horodatage facultatif, la longueur combinée des noms et valeurs d'étiquettes étant limitée à 128 points de code. La spécification du SDK de métriques OpenTelemetry décrit un exemplaire comme une mesure enregistrée qui expose la valeur, l'instant de l'appel, les attributs abandonnés par l'agrégation et, pour les instruments synchrones, l'ID de trace et l'ID de span de la portée (span) active ; son filtre d'exemplaires par défaut doit être TraceBased, si bien que seules les mesures effectuées à l'intérieur d'une portée échantillonnée sont éligibles à devenir des exemplaires. D'autres bibliothèques clientes peuvent nécessiter que l'ID de trace soit transmis avec l'observation ; vérifier la documentation de la bibliothèque.
5. Activer le stockage des exemplaires dans le backend de métriques et configurer les panneaux d'histogramme du tableau de bord pour afficher les points d'exemplaires qui ouvrent la trace au clic.
6. Vérifier la jointure : choisir un bucket lent sur le tableau de bord, ouvrir l'exemplaire, et confirmer que la trace montre bien la requête ayant produit l'observation.

Résultat attendu

N'importe quel intervenant peut lire l'état de santé de n'importe quel service dans les trois mêmes panneaux, et peut passer de « le p99 a grimpé à 14h02 » à une trace concrète d'une requête lente sans avoir à chercher.

Limites et base de vérification

RED couvre les composants pilotés par requêtes ; les files d'attente et les traitements par lots ont besoin d'indicateurs de fraîcheur et de dernier succès, et l'épuisement des ressources relève de USE. Les exemplaires ne valent que ce que vaut l'échantillonnage de traçage : une requête lente non échantillonnée ne laisse aucun exemplaire. Les bornes des buckets déterminent quels centiles un histogramme classique peut restituer.