SLIs für Queues und Batch-Jobs: Alter der ältesten Nachricht, Aktualität, Abdeckung und letzter Erfolg

Ziel

Service-Level-Indikatoren für asynchrone Arbeit definieren, damit „die Queue ist in Ordnung“ und „der nächtliche Job ist gelaufen“ zu gemessenen Aussagen mit einem Schwellenwert werden.

Voraussetzungen

Eine Liste der Queues und geplanten Jobs, die Erwartung, die Nutzerinnen und Nutzer an jeden haben (wie veraltet darf das Ergebnis sein, bis wann muss der Lauf fertig sein), und ein Metriksystem, das Gauges und Verhältnisse speichert. Die Komponententypen des SRE-Workbooks (anfragegetrieben, Pipeline, Storage) liefern das Vokabular; seine Pipeline-SLIs sind Aktualität, Korrektheit und Abdeckung.

Schritte

1. Jede Komponente klassifizieren. Eine konsumierte Queue und ein geplanter Job sind im Sinne des Workbooks beides Pipelines: Datensätze gehen hinein, Ergebnisse kommen später heraus.
2. Bei einer Queue zuerst den nutzerseitigen Indikator formulieren: den Anteil der Elemente, die innerhalb von N Sekunden nach dem Einreihen verarbeitet wurden (Aktualität). Der praktische Ersatzwert ist das Alter des ältesten unverarbeiteten Elements; gehostete Queues legen es offen (Amazon SQS meldet ApproximateAgeOfOldestMessage in Sekunden). Die Backlog-Grösse ist ein Ursachenindikator, nützlich für die Kapazitätsplanung, aber nicht der SLI.
3. Bei einem Batch-Job den Zeitstempel des letzten erfolgreichen Abschlusses als Gauge exportieren; der Prometheus-Instrumentierungsleitfaden bezeichnet dies als die Schlüsselmetrik eines Batch-Jobs und empfiehlt, sie zusammen mit Stufendauern und verarbeiteten Datensätzen zu pushen, da ein nicht kontinuierlich laufender Job schwer zu scrapen ist.
4. Abdeckung hinzufügen: bei Batch-Verarbeitung den Anteil der Läufe, die mindestens die erwartete Datenmenge verarbeitet haben; bei Streaming den Anteil der eingehenden Datensätze, die innerhalb des Zeitfensters verarbeitet wurden. Ein Lauf, der sofort endet, weil seine Eingabe leer war, ist ein Abdeckungsfehlschlag, kein Erfolg.
5. Korrektheit hinzufügen, wo ein Prüfmechanismus existiert: den Anteil der Eingabedatensätze, deren Ausgabe korrekt ist, gemessen an einer Stichprobe gegen eine Referenzberechnung.
6. Jeden Indikator in ein Verhältnis über ein Zeitfenster umwandeln (gute Ereignisse geteilt durch Gesamtereignisse), ein Ziel festlegen und den Alarm formulieren als „Zeit seit letztem Erfolg übersteigt das Doppelte der Planungsperiode“ oder „ältestes Element älter als der Aktualitätsschwellenwert bei M aufeinanderfolgenden Auswertungen“.
7. Indikator, Implementierung, Ziel und Zeitfenster im SLO-Dokument festhalten.

Erwartetes Ergebnis

Jede Queue und jeder Job hat einen Aktualitäts- oder Letzter-Erfolg-Indikator mit einem Schwellenwert, eine Abdeckungsprüfung, die leere Läufe erkennt, und einen Alarm, der sowohl bei fehlenden als auch bei schlechten Daten auslöst.

Grenzen und Prüfbasis

Altersmetriken gehosteter Queues sind als Näherungswerte dokumentiert; der SQS-Leitfaden weist darauf hin, dass eine Standard-Queue-Nachricht, die dreimal oder öfter ohne Löschung empfangen wurde, ans Ende der Queue wandert und die Altersmetrik verlässt, sodass eine Giftnachricht nicht als wachsendes Alter erscheint. Ein Job, der nie startet, gibt nichts aus, weshalb Alarme eine fehlende Zeitreihe als Fehlschlag behandeln müssen. Korrektheit braucht eine unabhängige Referenz und wird meist stichprobenartig gemessen.

Fristbasierte Alarme für geplante Jobs

Die Regel „das Doppelte der Planungsperiode“ passt zu Jobs, deren einzige Anforderung Regelmässigkeit ist. Ein Job mit einer Frist für Konsumierende (ein um 06:00 fälliger Bericht aus einem Lauf um 03:00) braucht stattdessen einen aus dem Aktualitätsindikator abgeleiteten Alarm: Auslösen, wenn die Frist verstrichen ist und der letzte Erfolg älter als der geplante Start ist, zum Beispiel hour() >= 6 and time() - job_last_success_timestamp_seconds > 3 * 3600, ausgewertet in den Stunden nach dem Lauf und in der von der Planung verwendeten Zeitzone ausgedrückt. Die Frist neben der Planung im SLO-Dokument festhalten, die periodenbasierte Regel als gröberen Rückfall für Jobs ohne genannten Konsumenten beibehalten, und beide Regeln eine fehlende Zeitreihe mit absent() als Fehlschlag behandeln lassen.