Fehlerbehandlung
Teil von API-Limits und Leistung
Verzögerungen zwischen Auslöser und Ergebnis messen
Zeitpunkte für Auslöser, Queue, API und bestätigtes Ergebnis definieren und Verzögerungen je Vorgang richtig einordnen.
Messen Sie die Zeit vom fachlich gültigen Auslöser bis zum bestätigten Ergebnis eines Vorgangs. Erfassen Sie getrennte Zeitpunkte für Annahme, Beginn, Zielaufruf und spätere Bestätigung. So grenzen Sie ein, wo Zeit vergeht, und verwechseln eine schnelle API-Antwort nicht mit einem fertigen Geschäftsvorgang.
Start und Ende festlegen
Der Start kann die gültige Abgabe einer Materialanforderung sein, nicht schon das Öffnen des Formulars. Das Ende ist der zuvor vereinbarte Zustand im maßgeblichen Zielsystem. Eine angenommene Nachricht oder ein gestarteter Worker liegt davor. Auch eine HTTP-Antwort bestätigt nur das, was die konkrete API-Operation laut ihrem Vertrag bestätigt.
Halten Sie pro Fall eine stabile Vorgangskennung und diese Zeitpunkte fest:
| Zeitpunkt | Bedeutung |
|---|---|
| Auslöser | Der fachlich gültige Vorgang ist entstanden. |
| Annahme | Der Workflow hat ihn zur Verarbeitung übernommen. |
| Beginn | Ein Worker beginnt die Bearbeitung. |
| API-Start | Die betreffende Zielanfrage wird gesendet. |
| API-Antwort | Eine verwertbare Antwort auf diese Anfrage liegt vor. |
| Ergebnis | Der vereinbarte Zielzustand ist bestätigt oder ein anderer Endzustand wurde begründet festgelegt. |
Damit lassen sich Wartezeit bis zum Worker, Arbeit vor dem API-Aufruf, Dauer des Aufrufs und Zeit bis zur Ergebnisbestätigung getrennt betrachten. Wenn es mehrere Zielaufrufe gibt, erfassen Sie Start und Ende je Versuch.
Definieren Sie auch, wie abgelehnte, abgelaufene und weiterhin offene Fälle ausgewertet werden. Eine Auswertung nur abgeschlossener Fälle übersieht lange offene Vorgänge.
Versuche demselben Vorgang zuordnen
Ein Retry ist ein neuer technischer Versuch, aber kein neuer fachlicher Auslöser. Verbinden Sie alle Versuche mit der ursprünglichen Vorgangskennung und erfassen Sie ihren Grund. Für die Fehlersuche hilft die Dauer jedes Aufrufs; für die wartende Person zählt die gesamte Zeit einschließlich Queue und Pausen.
OpenTelemetry ermöglicht die Weitergabe von Trace-Kontext über Dienstgrenzen. Seine Messaging-Konventionen beschreiben eine Metrik für die Dauer einer Nachrichtenverarbeitung; diese Konvention ist als „Development“ gekennzeichnet.
Die gemessene Verarbeitung umfasst nicht automatisch Wartezeit vor dem Worker oder eine spätere fachliche Bestätigung. Diese Grenzen müssen im eigenen Messkonzept ergänzt werden.
Entstehen Zeitpunkte in verschiedenen Systemen, prüfen Sie Uhrzeitbasis, Zeitzonen und Uhrabweichungen. Für die Dauer eines einzelnen laufenden Schritts kann eine monotone Uhr helfen. Negative oder unplausible Abstände sind Anlass, die Messung zu prüfen.
Verteilungen und offene Fälle lesen
Betrachten Sie für denselben fachlichen Ablauf die Zahl begonnener und beendeter Fälle, die Verteilung der Ergebnisdauer und das Alter offener Fälle. Ein Mittelwert allein kann stark verzögerte Fälle verdecken. Histogramme eignen sich für Dauerverteilungen; die OpenTelemetry Metrics API nennt Anfragedauer als Beispiel.
Queue-Metriken helfen beim Eingrenzen. Amazon SQS veröffentlicht unter anderem ungefähre Werte für das Alter der ältesten unverarbeiteten Nachricht, für Nachrichtengruppen mit laufenden Nachrichten in FIFO-Queues und für verzögerte Nachrichten. Diese Werte ersetzen keine Zeitmessung je Geschäftsvorgang; insbesondere kann die Altersmetrik bei wiederholt fehlgeschlagenen Standard-Queue-Nachrichten irreführen.
Steigt vor allem die Wartezeit, prüfen Sie Eingang und verfügbare Verarbeitungskapazität. Steigt die Dauer einer Zielanfrage, untersuchen Sie diese Operation. Liegt die Verzögerung nach der API-Antwort, verfolgen Sie die fachliche Bestätigung. Ein Metrikverlauf liefert zunächst einen Hinweis; die betroffenen Vorgänge und Schritte müssen die Ursache zeigen.
