Eine API hinter einem Login überwachen

Überwache eine API, die hinter einem Login liegt, damit du echte Fehler erkennst — nicht nur eine Health-Seite, die „OK“ sagt, während die wichtigen Teile kaputt sind. Das ist für alle gedacht, die eine API prüfen müssen, bei der zuerst eine Anmeldung nötig ist.

#Überblick

• Eine Health-Seite kann einwandfrei aussehen, selbst wenn Anmeldung, Tokens oder die eigentlichen Datenabrufe fehlschlagen.
• Ein API-Monitor verhält sich wie ein echter Nutzer: Er meldet sich an, behält das zurückgegebene Token und verwendet dieses Token, um deine API aufzurufen.
• Schlägt ein Schritt fehl, geht der Monitor auf „Down“ und zeigt genau, welcher Schritt fehlgeschlagen ist und warum — zum Beispiel „Step 2 of 3 (GET /orders): HTTP 401“.

#Einrichtung

1. Gehe zu Monitoring und klicke auf Add monitor.
2. Klicke auf Advanced monitors und wähle dann API monitor.
3. Fülle die erste Anfrage aus — meist deine Anmeldeadresse — mit Methode und Request-Body. Diese Anfrage ist Schritt 1.
4. Gib unter Save from this response den Namen des Werts an, den du später brauchst (zum Beispiel token), wähle, woher er stammt, und gib an, wo er zu finden ist:
   • JSON field — ein Pfad wie $.access_token;
   • Response header — ein Header-Name wie X-Session-Id;
   • Pattern in the text — ein Muster, dessen erste Gruppe der Wert ist, etwa token=([a-z0-9]+).
5. Füge unter Secret values alles hinzu, was du nicht erneut einsehen musst, etwa das Passwort, das beim Anmelden verwendet wird. Schreibe dann {{password}} im Body von Schritt 1 an der Stelle, an der das Passwort stehen soll.
6. Klicke für jeden folgenden Aufruf auf Add a step. Gib eine Methode und eine Adresse an — eine vollständige Adresse oder nur einen Pfad wie /orders, der relativ zur Adresse des Monitors gelesen wird — und verwende gespeicherte Werte mit doppelten geschweiften Klammern, zum Beispiel einen Header Authorization mit dem Wert Bearer {{token}}. Das Wertefeld listet alle Werte auf, die der Schritt verwenden kann.
7. Lege für jeden Schritt fest, welche Statuscodes als Erfolg zählen, und optional Prüfungen für das zurückgegebene JSON.
8. Klicke auf Test connection, um den gesamten Ablauf einmal zu testen, und speichere anschließend.

#Was du bekommst

• Der Monitor ist nur dann „Up“, wenn jeder Schritt erfolgreich ist. Der erste fehlgeschlagene Schritt beendet die Prüfung, und die Begründung nennt den Schritt, die Anfrage und was schiefgelaufen ist. Benachrichtigungen und Vorfälle verwenden dieselbe Formulierung.
• Auf der Seite des Monitors listet Steps jede Anfrage des letzten Checks auf, mit dem erhaltenen Status und der benötigten Zeit.
• Regionen, die Anzahl der Standorte, die übereinstimmen müssen, und Failover funktionieren genauso wie bei jedem anderen Monitor.

#Gut zu wissen

• Bis zu 5 Schritte insgesamt, einschließlich der ersten Anfrage, und bis zu 5 gespeicherte Werte pro Schritt.
• Alle Schritte zusammen haben höchstens 60 Sekunden Zeit und nie mehr als das Intervall des Monitors. Ein Schritt, der nach dieser Zeit starten würde, wird als „ran out of time“ gemeldet.
• Secret values werden verschlüsselt gespeichert und nie wieder angezeigt — weder im Formular noch über die API. Um einen Wert zu ändern, gib einen neuen Wert ein; um einen zu entfernen, lösche ihn und speichere.
• Gespeicherte Werte werden nie aufbewahrt. Die Schrittliste zeigt jede Anfrage so, wie du sie geschrieben hast (/orders/{{order_id}}), nicht mit eingesetzten Werten, und ein Wert, der in einer Fehlerbegründung auftaucht, wird durch [hidden] ersetzt.
• Die eigenen Anmeldeeinstellungen des Monitors (Basic, Digest oder Bearer) werden nur an Schritte mit derselben Site wie die Adresse des Monitors gesendet. Was ein Schritt auf einer anderen Site benötigt, gehört in die Header dieses Schritts.

WarningHeader, die ein Passwort, einen Key oder ein Token enthalten — Authorization, Cookie, X-Api-Key und Ähnliches — müssen einen Wert wie {{api_key}} oder Bearer {{token}} verwenden. Lege das Passwort oder den Key unter Secret values ab und verweise darauf; eine direkte Eingabe im Header wird beim Speichern abgelehnt.

#Fehlerbehebung

• „… has no value“ — ein Schritt verwendet einen Namen, den kein vorheriger Schritt gespeichert hat und der auch kein Secret value ist. Prüfe die Schreibweise und ob der speichernde Schritt tatsächlich vorher kommt.
• „Couldn't save …“ — die Antwort enthielt nicht das, worauf du verwiesen hast. Führe Test connection aus und vergleiche den Pfad mit dem, was deine API tatsächlich zurückgibt.
• „Step 1 of 2 …: HTTP 401“ — die Anmeldung selbst wurde abgelehnt. Prüfe den Secret value und den Request-Body.

TipVerwende Test connection nach jeder Änderung an den Schritten — dabei wird der gesamte Ablauf einmal ausgeführt, sodass du eine fehlerhafte Anmeldung oder einen falschen Pfad erkennst, bevor du speicherst.