Schnittstellen beobachten, bevor Störungen zu Ausfällen werden

Ein HTTP-Status 200 bedeutet nach RFC 9110, dass die Anfrage auf HTTP-Ebene erfolgreich war; was genau dieser Erfolg umfasst, hängt von der verwendeten Methode ab. Er beweist nicht, dass ein nachgelagerter Geschäftsprozess abgeschlossen ist. Das Google-SRE-Handbuch bezeichnet eine formal erfolgreiche 200-Antwort mit falschem Inhalt als impliziten Fehler.

Auch ein Healthcheck besitzt nur die Aussage, für die er gebaut wurde. Eine erreichbare Anwendung kann grün erscheinen, während eine Warteschlange festliegt.

Zu den von OpenTelemetry beschriebenen Signalen gehören Metriken, Traces und Logs; die aktuelle Dokumentation führt darüber hinaus weitere Signale wie Baggage und Profiles. Metriken verdichten Laufzeitmessungen, ein Trace bildet den Pfad einer Anfrage ab, Logs zeichnen Ereignisse auf. Diese Rollen sind typische Sichten, keine exklusiven Grenzen. Eine auffällige Metrik kann den Zeitraum eingrenzen, ein Trace den betroffenen Pfad und ein Logeintrag den Grund einer Ablehnung; durch Korrelation können die Sichten ineinandergreifen.

Korrelation und Fehlerverträge

Der Zusammenhang funktioniert nur mit konsistenten Kennungen und vergleichbaren Zeitangaben. W3C Trace Context standardisiert dafür die Felder traceparent und tracestate. Personenbezogene oder sensible Informationen gehören nach der Spezifikation nicht hinein. Auch zufällige Kennungen können durch die Verknüpfung vieler Aufrufe datenschutzrelevant werden. Zugriff, Aufbewahrung und Löschung der verbundenen Telemetriedaten bleiben daher Teil der Architektur. Trace-Kontext überschreitet zudem Vertrauensgrenzen. Ein externer Aufrufer kann ihn mitsenden; interne Systeme sollten ihn nicht ungeprüft als privilegierte oder verlässliche Herkunftsangabe behandeln. Die Schnittstelle legt fest, welche Felder übernommen, neu erzeugt oder entfernt werden. Eine Trace-ID kann einen technischen Vorgang verbinden, ist aber kein Grund, Kunden-, Rechnungs- oder Aktennummern im Klartext in Telemetrie zu kopieren.

RFC 9457 definiert Problem Details als maschinenlesbares Format für HTTP-Fehler. Problemtyp, Status und eine Kennung der konkreten Instanz können dem Empfänger einen stabilen Fehlervertrag geben.

Das Format ist kein Kanal für Stacktraces, interne Pfade oder vertrauliche Serverdetails. Die interne Diagnose darf umfangreicher sein, muss sich jedoch eindeutig dem nach außen bezeichneten Fall zuordnen lassen. Für die maschinelle Verarbeitung von Problem Details unterscheidet RFC 9457 den stabilen Problemtyp in type von der konkreten Instanz in instance. Die Texte in title und detail dienen Menschen. Ein Client sollte deshalb seine Fehlerbehandlung nicht vom Wortlaut einer Beschreibung abhängig machen, die sich etwa durch Übersetzung ändern kann. Diese Trennung erlaubt verständliche Meldungen, ohne den maschinellen Vertrag bei jeder Textkorrektur zu verändern.

Welche Anfragen in den Traces fehlen

Tracing kann mit Stichproben arbeiten. Beim Head Sampling fällt die Auswahl früh, bevor der vollständige Verlauf bekannt ist. Ein erst später auftretender Fehler kann deshalb zu einer Anfrage gehören, deren Trace nicht aufbewahrt wird.

Tail Sampling entscheidet anhand größerer Teile des Verlaufs und kann beispielsweise Fehler oder hohe Latenzen als Auswahlkriterium nutzen. Dafür muss die Verarbeitung Zustände vorhalten und ihren Speicherbedarf beherrschen. Auch dieser Weg ist kein Vollständigkeitsversprechen. Für die Untersuchung einer fehlenden Bestellung ergibt sich daraus eine Grenze: Ein nicht gefundener Trace beweist nicht, dass der Aufruf nie stattgefunden hat. Die Stichprobenregel und mögliche Verluste bei Erfassung oder Transport gehören zur Diagnose. Benötigt der Prozess einen vollständigen fachlichen Nachweis, muss dieser unabhängig von einer möglicherweise ausgedünnten Telemetrie geführt werden. Diese Empfehlung folgt aus den von OpenTelemetry beschriebenen Grenzen des Samplings; sie schreibt keine bestimmte Speicherarchitektur vor.

Alarmierung

Google SRE trennt bei Alarmen das sichtbare Symptom von Hinweisen auf die Ursache. Der Bereitschaftsdienst muss zuerst erkennen können, welcher Dienst seit wann welche Wirkung zeigt. Niedriger Ressourcenverbrauch ist keine Entwarnung, wenn Aufträge unvollständig verarbeitet werden. Folgt auf ein Ereignis stets dieselbe vorgegebene Reaktion, sollte geprüft werden, ob sich diese Reaktion automatisieren lässt, statt dafür den Bereitschaftsdienst zu wecken.

Schwellenwerte benötigen eine Bezugsgröße. Bei stark wechselndem Tagesvolumen kann eine starre Fehlerzahl irreführen; eine Quote erklärt bei sehr kleinen Mengen ebenfalls wenig.

Ein betrieblich gewähltes Alarmformat kann deshalb beobachteten Wert, Nenner und eine erste Handlung dokumentieren. Die Ursache muss zu diesem Zeitpunkt noch nicht bewiesen sein. Beginn, Reichweite, betroffene Versionen und sichtbare fachliche Vorgänge helfen bei der ersten Eingrenzung; Google schreibt diese konkrete Felderliste nicht als Standard vor.

Bei einem vereinbarten Service Level Objective kann die Alarmierung zusätzlich den Verbrauch des Fehlerbudgets berücksichtigen. Die Burn Rate beschreibt, wie schnell dieses Budget relativ zum zulässigen Verbrauch aufgebraucht wird. Das Google SRE Workbook kombiniert dafür längere und kürzere Beobachtungsfenster: Das längere Fenster erfasst anhaltenden Verbrauch, das kürzere zeigt, ob die Störung noch besteht. Die dort genannten Werte sind Beispiele, keine universell passenden Schwellen für eine B2B-Schnittstelle.

Gerade bei geringem Auftragsvolumen muss die Auswertung vorsichtig bleiben. Ein einziger fehlgeschlagener Aufruf kann eine hohe Fehlerquote erzeugen. Synthetische Anfragen können zusätzliche Signale liefern, bilden aber nur die dafür entworfenen Fälle ab. Werden sie mit echten Nutzeraufrufen unbesehen zusammengezählt, können viele erfolgreiche Testanfragen reale Fehler rechnerisch verdecken. Für die Betriebsentscheidung müssen diese Populationen unterscheidbar bleiben.

Inventar und Stilllegung

OWASP führt unvollständige API-Inventare und fehlende Ablösestrategien als Risiko. Zum Endpunkt gehören Umgebung, Version, der vorgesehene Netzwerkzugriff - etwa öffentlich, intern oder durch Partner - und sensible Datenflüsse. Dass eine Schnittstelle organisatorisch als abgeschaltet gilt, macht sie technisch nicht unerreichbar. Ältere Schutzvorgaben oder ungepatchte Komponenten können weiterwirken, solange Aufrufer oder Zugänge bestehen. Als betriebliche Ergänzung kann das Inventar den Endpunkt mit seinen Signalen und einer zuständigen Stelle verbinden. Änderungen sollten den bestehenden Trace- und Fehlervertrag erhalten oder Abweichungen ausweisen. Für die Ablösung empfiehlt sich, Aufrufer zu migrieren, Zugänge zu entziehen und die Nichterreichbarkeit des alten Pfads zu prüfen. Bei der Betriebsübergabe ist ein reproduzierbarer Test mit dem Ort der Rohsignale und dem nächsten Prüfschritt belastbarer als ein einzelner Dashboard-Screenshot.

Hinweis: Diese Einordnung ersetzt keine Prüfung des Einzelfalls.