API-Monitoring-Tool: Uptime, Antwortzeit und Validierung aus 300+ Standorten

REST-API-Monitoring sieht oberflächlich wie Uptime-Monitoring aus, ist aber eine andere Aufgabe. Eine API wird von Code konsumiert, nicht von Menschen, und Code verzeiht auf eine Art nicht, wie es ein Browser tut. Ein menschlicher Besucher toleriert eine Seite, die leicht falsch gerendert wird; eine Integration, die ein Feld vom falschen Typ erhält, bricht schlicht ab. API-Monitoring muss deshalb mehr Ebenen prüfen als „Hat der Server geantwortet“, und HostTracker prüft sie der Reihe nach, wobei der Check bei der ersten nicht erfüllten Ebene fehlschlägt.

Die Ebenen eins bis drei sind das, was ein gewöhnlicher Uptime-Check liefert. Vier und fünf sind das, was daraus API-Monitoring macht - und genau dort spielen sich die meisten echten API-Vorfälle tatsächlich ab.

Bevor irgendetwas validiert werden kann, muss der Monitor die Anfrage stellen, die Ihre API erwartet. Der vollständige Anfrageumfang steht auf einem API-Monitor zur Verfügung:

Der ausdrucksstärkste Weg, eine Antwort zu validieren, ist, Regeln dafür zu schreiben. Jede Regel ist eine Zeile, Regeln werden mit UND verknüpft, und ein Monitor kann bis zu zwanzig davon tragen. Das ist das verifizierte Einstiegspaket für eine JSON-API:

status isOk
header("Content-Type") contains "json"
body.json.path("$.count") gt 0
time lt 5s

Vier Zeilen, und zusammen decken sie die vier Ebenen ab, auf die es ankommt: Der Endpunkt hat mit einem 2xx geantwortet, er hat mit JSON statt einer Fehlerseite geantwortet, der Payload enthält ein echtes Ergebnis statt eines leeren, und all das geschah innerhalb des Zeitbudgets. Einzeln nützliche Regeln aus demselben Katalog sind unter anderem body.json.path("$.status") eq "ok" für das eigene Health-Urteil einer API, body.json.path("$.error") absent für ein Error-Member, das in einer sonst erfolgreichen Antwort auftaucht, body.json.path("$.version") eq "2.4.1", um ein ungewolltes Rollback zu erkennen, redirects.count eq 0 für einen Endpunkt, der direkt antworten soll, und cert.days.left gt 14 für das Zertifikat auf derselben Verbindung.

Worüber eine Regel sprechen kann

Regeln lesen Subjekte aus der Antwort und vergleichen sie. Die Subjekte umfassen den Statuscode; die gesamte Antwortzeit und ihre Bestandteile Connect, TLS, DNS, Header und Body; den rohen Body samt seiner Größe und eines Hashes davon; strukturierte Abfragen in den Payload als JSON, XML, HTML oder YAML; einzelne Antwort-Header; die finale und die ursprüngliche URL sowie deren Bestandteile; die Weiterleitungskette Hop für Hop; die verbleibenden Tage, den Aussteller und die Namen des Zertifikats; das ausgehandelte TLS-Protokoll und den Cipher; die von DNS zurückgegebenen Adressen; und Set-Cookie. Vergleiche reichen vom Offensichtlichen - gleich, kleiner als, größer als - über contains, startsWith, endsWith, matches für einen regulären Ausdruck, containsAny und containsAll für eine Menge, in für eine Liste akzeptabler Werte, bis zu exists, isNumber und unique.

Es gibt außerdem eine Änderungserkennungs-Achse: Eine Regel kann den Wert dieses Laufs mit dem des vorherigen vergleichen, sodass Sie sicherstellen können, dass ein Zähler niemals zurückgeht oder sich ein Body-Hash nicht verändert hat - die Art von Regel, die ein stilles Rollback oder eine unautorisierte Inhaltsänderung erkennt statt eines Ausfalls.

Neben der Regelsprache gibt es einen einfacheren Ein-Wert-Pfad, der hier schon lange Teil des API-Monitorings ist und oft alles ist, was ein Check braucht. Sie sagen dem Monitor, wie er den Body parsen soll, wie er einen Wert daraus auswählt und was dieser Wert sein muss:

• Als JSON parsen, dann ist der Selektor ein JSONPath-Ausdruck.
• Als XML parsen, dann ist der Selektor ein XPath-Ausdruck - was SOAP und andere XML-Dienste unkompliziert prüfbar macht.
• Als Klartext behandeln, dann ist der Selektor ein mehrzeiliger, groß-/kleinschreibungsunabhängiger regulärer Ausdruck.

Das auf den ausgewählten Wert angewendete Prädikat umfasst gleich und ungleich, kleiner-als und größer-als jeweils in strikter und einschließender Form, Zugehörigkeit zu einer Liste akzeptabler Werte oder Ausschluss davon, innerhalb oder außerhalb eines numerischen Bereichs, sowie einen Test darauf, ob der Wert null oder vollständig fehlend ist.

Jeder Fehler in dieser Tabelle liefert HTTP 200. Das ist das gesamte Problem, wenn man eine API nur anhand ihres Statuscodes überwacht: Der Transport war erfolgreich, also meldet der Transport Erfolg.

Diese letzte Zeile lohnt sich, bewusst umzusetzen. Ein zweiter Monitor, der keine Zugangsdaten sendet und auf einen 401 prüft, ist der günstigste Weg herauszufinden, dass eine Autorisierungsschicht versehentlich deaktiviert wurde - ein Fehler, den kein noch so umfangreiches positives Testen jemals zutage fördern würde.

API-Monitore laufen über das öffentliche Prüfstationsnetz von HostTracker - über 300 Prüfpunkte in 158 Städten -, und Sie wählen aus, welche Standorte ein bestimmter Monitor nutzt. Geografie ist bei einer API noch wichtiger als bei einer Website: Ein Endpunkt hinter einem CDN oder einem geo-basierten Load Balancer kann in Frankfurt gesund sein und in São Paulo ausfallen, und ein Check von nur einem Standort kann das gar nicht sehen. Dasselbe gilt für DNS - ein veralteter oder falsch konfigurierter Eintrag verbreitet sich oft ungleichmäßig, was von innen wie ein sporadischer Ausfall aussieht und von außen wie ein regionaler.

Die Prüfung von vielen Standorten aus birgt ein offensichtliches Risiko: mehr Prüfpunkte, mehr Gelegenheiten für einen einzelnen instabilen Netzwerkpfad, Fehlalarm zu schlagen. HostTracker begegnet dem mit einem Bestätigungs-Quorum. Meldet ein Prüfpunkt einen Fehler, wird der Check an zusätzlichen, unabhängigen Prüfpunkten wiederholt, und der Statuswechsel wird erst bestätigt, wenn sie sich einig sind - standardmäßig ein Mehrheitsvotum über bis zu sieben Agenten, mit einem Minimum von drei. Sie können das strenger einstellen und eine feste Anzahl von Agenten verlangen, die den Fehler melden müssen, oder volle Übereinstimmung unter ihnen, für einen Endpunkt, bei dem eine falsche Benachrichtigung schlimmer ist als eine langsame.

Nach der Bestätigung folgt die Benachrichtigung der von jedem Kontakt gewählten Verzögerung - sofort, oder nach 3, 5, 15, 30 oder 60 Minuten, oder nach 3, 6, 12 oder 24 Stunden ununterbrochenen Fehlers - über die neun Benachrichtigungskanäle: E-Mail, SMS, Anruf, Webhook, Slack, Web-Push und die Messenger-Apps Telegram, Discord und Viber. Der Webhook-Kanal ist der Weg, auf dem Benachrichtigungen einen Incident-Manager oder ein Team-Chat-Tool erreichen.

Der Check ist eine konfigurierbare HTTP-Anfrage plus Antwortanalyse, und daraus ergibt sich direkt, wofür er sich eignet.

• REST- und JSON-APIs sind der Alltagsfall, und REST-API-Monitoring ist das, was die meisten Konten zuerst einrichten: ein GET oder POST, Header für die Zugangsdaten und JSONPath- oder Assertion-Regeln über den Payload.
• GraphQL funktioniert als POST mit der Query im Body, dann JSONPath in data hinein - und es lohnt sich, zu prüfen, dass das errors-Element fehlt, denn GraphQL antwortet bekanntlich mit 200, obwohl Fehler enthalten sind.
• SOAP- und XML-Dienste sind ein POST mit dem Envelope als Body und XPath als Selektor, der genau so in die Antwort hineingreift, wie es die Spezifikation vorsieht.
• Webhook-Empfänger und Callback-Endpunkte lassen sich auf Erreichbarkeit prüfen sowie auf die Antwort, die sie auf eine wohlgeformte Anfrage geben - wertvoll, denn ein Empfänger, der still aufgehört hat, Zustellungen anzunehmen, erzeugt in Ihrem eigenen System nirgendwo einen Fehler.
• Health- und Readiness-Endpunkte sind, sofern vorhanden, das wertvollste Ziel überhaupt: Ihre Anwendung weiß bereits, ob ihre Abhängigkeiten gesund sind, und eine Assertion auf dieses Urteil macht aus diesem Wissen eine Benachrichtigung.

Was nicht passt, ist eine Abfolge - ein Token holen, es verwenden, dann die Ressource löschen. Ein API-Monitor stellt eine Anfrage pro Lauf. Für einen echten mehrstufigen Ablauf ist der browsergesteuerte Transaktionscheck das richtige Werkzeug; für die Zeitmessung einer Seite statt eines Endpunkts siehe Browser-Zugriff und Seitenladezeit.

1. Testen Sie den Endpunkt zunächst mit dem kostenlosen Sofort-HTTP-Check - ohne Login -, damit Sie Status, Zeitverhalten und Antwort sehen, gegen die Sie gleich Regeln schreiben werden.
2. Legen Sie einen Monitor an und wählen Sie den API-Monitoring-Typ. Setzen Sie die Methode, und fügen Sie die Header oder den Body hinzu, die der Endpunkt braucht; stellen Sie dem Monitor eigene Zugangsdaten aus, statt die einer Person wiederzuverwenden.
3. Schreiben Sie die Assertions. Beginnen Sie mit dem obigen Vier-Zeilen-Paket - Status, Content-Type, ein aussagekräftiger Wert aus dem Payload und ein Antwortzeit-Budget -, das für nahezu jede JSON-API eine wirklich gute Standardeinstellung ist.
4. Wählen Sie ein Intervall zwischen einer Minute und 24 Stunden. Drei Minuten sind der Standard und ein vernünftiger Startpunkt; reservieren Sie eine Minute für die Endpunkte, deren Ausfall ein echter Vorfall wäre.
5. Wählen Sie die Standorte. Zwei oder drei Regionen, in denen Ihre Konsumenten tatsächlich sitzen, schlagen einen einzelnen Standort - und genau das macht einen regionalen Ausfall sichtbar.
6. Fügen Sie die Kontakte hinzu, und legen Sie für jeden die Alarmverzögerung fest. Nicht jeder muss schon in der ersten Minute davon erfahren.
7. Lassen Sie ihn einen Tag laufen, und schauen Sie sich dann die Antwortzeit-Historie an, bevor Sie die Zeitregel verschärfen. Ein aus echten Daten abgeleitetes Budget hält; eines, das geraten wurde, wird stummgeschaltet.

Beide ergänzen sich und werden häufig verwechselt. Eine Observability- oder APM-Plattform instrumentiert Ihren Code und sagt Ihnen, was innerhalb einer Anfrage passiert ist. Externes API-Monitoring steht außerhalb Ihrer Infrastruktur und sagt Ihnen, was ein Konsument tatsächlich erhält. Beides lohnt sich; keines ersetzt das andere.

Das Muster, bei dem die meisten Teams landen, ist externes Monitoring für die Erkennung und interne Telemetrie für die Diagnose: HostTracker sagt Ihnen, dass ein Endpunkt kaputt ist, von wo aus, und gegen welche Regel, und Ihr eigenes Tracing sagt Ihnen, warum. Ergänzend dazu erklärt oft ein Datenbank-Query-Monitor, warum eine API langsam geworden ist, und Server-Lastüberwachung erklärt den Host, auf dem sie läuft.

• Eine Anfrage pro Lauf. Kein Token-Austausch, keine verketteten Aufrufe. Richten Sie den Monitor auf einen Endpunkt, dessen Authentifizierung nicht abläuft, und verwenden Sie einen Transaktionscheck, wenn Sie eine Abfolge nachweisen müssen.
• Zwanzig Assertion-Regeln pro Monitor. In der Praxis reichlich - das Vier-Zeilen-Paket deckt die meisten Endpunkte ab -, aber gut zu wissen, bevor Sie einen Contract-Test mit hundert Regeln planen.
• Der Assertion-Modus ersetzt die älteren Stichwort- und Status-Einstellungen. Die beiden Modelle lassen sich nicht auf einem Monitor kombinieren; wählen Sie entweder die Regelsprache oder den alten Stichwort-Modus, nicht beides.
• Keine OpenAPI- oder JSON-Schema-Validierung. Sie prüfen auf konkrete Werte und Strukturen, nicht auf ein vollständiges Schema-Dokument.
• Der Request-Body hat eine Längenbegrenzung, ein sehr großer POST-Payload ist also nicht die Form, für die dieser Check gebaut ist.
• Es ist Monitoring, kein Testing. Das richtige Ziel ist ein schreibgeschützter oder idempotenter Endpunkt. Ein Monitor, der alle drei Minuten von mehreren Standorten aus Daten verändert, wird irgendwann der Grund für einen Vorfall sein statt das, was einen erkennt.