Indicateurs de niveau de service pour les files d'attente et les traitements par lots : âge du message le plus ancien, fraîcheur, couverture et dernier succès

Objectif

Définir des indicateurs de niveau de service pour le travail asynchrone, afin que « la file d'attente va bien » et « le job de nuit a tourné » deviennent des affirmations mesurées assorties d'un seuil.

Prérequis

Une liste des files d'attente et des jobs planifiés, l'attente que les utilisateurs ont de chacun (jusqu'à quel point le résultat peut-il être périmé, à quelle heure l'exécution doit-elle se terminer), et un système de métriques stockant des jauges et des ratios. Les types de composants du SRE workbook (piloté par requêtes, pipeline, stockage) fournissent le vocabulaire ; ses indicateurs de pipeline sont la fraîcheur, l'exactitude et la couverture.

Étapes

1. Classer chaque composant. Une file consommée et un job planifié sont tous deux des pipelines au sens du workbook : des enregistrements entrent, des résultats sortent plus tard.
2. Pour une file d'attente, écrire d'abord l'indicateur orienté utilisateur : la proportion d'éléments traités dans les N secondes suivant leur mise en file (fraîcheur). L'indicateur de substitution pratique est l'âge de l'élément non traité le plus ancien ; les files hébergées l'exposent (Amazon SQS rapporte ApproximateAgeOfOldestMessage en secondes). La taille de la pile en attente est un indicateur de cause, utile pour le dimensionnement, mais ce n'est pas l'indicateur de niveau de service.
3. Pour un job par lots, exporter l'horodatage de la dernière exécution réussie sous forme de jauge ; le guide d'instrumentation de Prometheus appelle cela la métrique clé d'un job par lots et recommande de la pousser, avec les durées d'étapes et le nombre d'enregistrements traités, car un job qui ne tourne pas en continu est difficile à scraper.
4. Ajouter la couverture : pour le traitement par lots, la proportion d'exécutions ayant traité au moins la quantité de données attendue ; pour le streaming, la proportion d'enregistrements entrants traités dans la fenêtre. Une exécution qui se termine instantanément parce que son entrée était vide est un échec de couverture, pas un succès.
5. Ajouter l'exactitude là où un vérificateur existe : la proportion d'enregistrements en entrée dont la sortie est correcte, mesurée sur un échantillon par rapport à un calcul de référence.
6. Transformer chaque indicateur en ratio sur une fenêtre (événements bons divisés par événements totaux), fixer une cible, et écrire l'alerte comme « le temps depuis le dernier succès dépasse deux fois la période planifiée » ou « l'élément le plus ancien est plus vieux que le seuil de fraîcheur pendant M évaluations consécutives ».
7. Consigner l'indicateur, son implémentation, sa cible et sa fenêtre dans le document de SLO.

Résultat attendu

Chaque file d'attente et chaque job dispose d'un indicateur de fraîcheur ou de dernier succès avec un seuil, d'une vérification de couverture qui repère les exécutions vides, et d'une alerte qui se déclenche aussi bien sur l'absence de données que sur de mauvaises données.

Limites et base de vérification

Les métriques d'âge des files hébergées sont documentées comme approximatives ; le guide SQS note qu'un message de file standard reçu trois fois ou plus sans être supprimé repasse à l'arrière de la file et quitte la métrique d'âge, si bien qu'un message empoisonné n'apparaît pas comme un âge croissant. Un job qui ne démarre jamais n'émet rien, donc les alertes doivent traiter une série absente comme un échec. L'exactitude nécessite une référence indépendante et est généralement échantillonnée.

Alertes basées sur une échéance pour les jobs planifiés

La règle du « double de la période planifiée » convient aux jobs dont la seule exigence est la régularité. Un job avec une échéance côté consommateur (un rapport dû à 06 h 00 issu d'une exécution à 03 h 00) a besoin d'une alerte dérivée de l'indicateur de fraîcheur à la place : se déclencher lorsque l'échéance est passée et que le dernier succès est plus ancien que le début planifié, par exemple hour() >= 6 and time() - job_last_success_timestamp_seconds > 3 * 3600, évaluée dans les heures suivant l'exécution et exprimée dans le fuseau horaire utilisé par la planification. Écrire l'échéance à côté de la planification dans le document de SLO, garder la règle basée sur la période comme filet de sécurité plus grossier pour les jobs sans consommateur déclaré, et faire en sorte que les deux règles traitent une série absente comme un échec avec absent().