Uptime-Monitoring für KI-Agenten und MCP-Server: so geht's

Um einen KI-Agenten oder MCP-Server zu überwachen, führen Sie regelmäßig einen HTTP-Check gegen einen echten Endpunkt aus. Testen Sie den ganzen Weg: Netzwerk, Authentifizierung und einen einfachen Tool-Aufruf. Beobachten Sie dazu Latenz und Fehlerrate, denn ein Server, der mit einem Fehler antwortet, ist nicht wirklich "online".

Ein einfacher Check, ob Port 443 offen ist, reicht nicht. Der Prozess kann laufen, während die Modell-API, die Datenbank oder die Anmeldung ausgefallen ist.

Warum KI-Endpunkte mehr als einen Ping brauchen

Eine normale Webseite wird entweder ausgeliefert oder nicht. Ein KI-Agent hat mehr bewegliche Teile. Er hängt von einer Sprachmodell-API ab, von Tools, von Zugangsdaten und oft von einer Warteschlange.

Jeder dieser Teile kann ausfallen, während die Eingangstür weiter HTTP 200 liefert. Ein Agent kann zum Beispiel jede Anfrage mit einer höflichen Fehlermeldung und dem Statuscode 200 beantworten. Ein einfacher Uptime-Check meldet dann "gesund".

Sie brauchen deshalb Checks auf drei Ebenen:

• Erreichbarkeit: Nimmt der Endpunkt eine Verbindung an und antwortet er?
• Korrektheit: Enthält die Antwort das, was Sie erwarten?
• Servicequalität: Ist die Antwort schnell genug, und schlägt sie selten genug fehl?

Was ein MCP-Server anbietet

Das Model Context Protocol (MCP) erlaubt es einem KI-Client, Tools auf einem Server aufzurufen. Viele Server nutzen den HTTP-Transport. Die Nachrichten sind JSON-RPC-Anfragen, die per HTTP POST gesendet werden.

Daraus ergeben sich zwei günstige Prüfungen:

• Die Anfrage initialize, die eine Sitzung startet.
• Die Anfrage tools/list, die die angebotenen Tools zurückgibt.

Prüfen Sie das genaue Anfrageformat in der MCP-Spezifikation und in der Dokumentation Ihres Servers. Transporte und Versionen ändern sich. Kopieren Sie daher keine Anfrage aus einem alten Blogbeitrag, auch nicht aus diesem.

Schritt 1: Den Endpunkt per HTTP prüfen

Beginnen Sie mit der einfachsten Prüfung und bauen Sie sie schrittweise aus.

1. Legen Sie einen Monitor für die öffentliche URL des Agenten oder MCP-Servers an.
2. Nutzen Sie dieselbe HTTP-Methode wie Ihre Clients. Bei MCP über HTTP ist das meist POST.
3. Senden Sie einen kleinen, gültigen Anfragekörper. Senden Sie keine leere Anfrage.
4. Legen Sie den erwarteten Statuscode fest, zum Beispiel 200.
5. Fügen Sie eine Inhaltsprüfung hinzu, zum Beispiel dass die Antwort den Namen eines bekannten Tools enthält.

Die Inhaltsprüfung ist der wichtigste Teil. Sie belegt, dass der Server Ihre Anfrage verstanden und echte Arbeit geleistet hat. Ein Statuscode allein belegt das nicht.

Schritt 2: Die Authentifizierung testen

Die meisten Agenten-Endpunkte brauchen ein Token oder einen API-Schlüssel. Die Authentifizierung fällt oft aus, und das geschieht leise.

Legen Sie ein eigenes Test-Zugangsdatum für das Monitoring an. Geben Sie ihm möglichst wenige Rechte, am besten nur Lesezugriff. Verwenden Sie keinen Schlüssel eines echten Kunden oder eines Entwicklers.

Führen Sie zwei Prüfungen aus:

• Gültiges Zugangsdatum: Erwartet wird Erfolg. Schlägt das fehl, ist Ihre Anmeldeschicht oder der Schlüsselspeicher gestört, oder der Schlüssel ist abgelaufen.
• Kein Zugangsdatum: Erwartet wird 401 oder 403. Kommt hier 200 zurück, haben Sie ein Sicherheitsproblem und kein Verfügbarkeitsproblem.

Tragen Sie außerdem das Ablaufdatum des Testschlüssels in Ihren Kalender ein. Viele "Ausfälle" sind nur abgelaufene Schlüssel.

Schritt 3: Die Latenz messen

Nutzer warten nicht auf langsame Agenten. Eine langsame Antwort ist ein Teilausfall.

Setzen Sie zwei Grenzen:

• Eine Warngrenze: Der Check ist langsam, funktioniert aber.
• Eine Ausfallgrenze: Der Check gilt als down. Sie sollte Ihrem Client-Timeout entsprechen.

Die Dauer von Modellaufrufen schwankt stark. Führen Sie Ihren Latenz-Check deshalb nicht über das Modell selbst aus, außer Sie wollen das Modell testen. Prüfen Sie für die Verfügbarkeit einen leichten Endpunkt wie tools/list oder eine Health-Route. Nutzen Sie einen zweiten, selteneren Check für den vollständigen Modell-Durchlauf.

Betrachten Sie Verläufe, nicht einzelne Werte. Vergleichen Sie über eine Woche den Median und die langsamsten Anfragen. Wächst das langsame Ende, haben Sie ein Problem, bevor sich Nutzer beschweren.

Schritt 4: Die Fehlerrate verfolgen

Synthetische Checks zeigen den Zustand zu einem Zeitpunkt. Echter Verkehr zeigt, was Nutzer erleben. Protokollieren Sie jede Anfrage in Ihrem Agenten-Code und zählen Sie die Ergebnisse.

Nützliche Fehlerklassen:

• HTTP 4xx vom eigenen Server, oft ein Hinweis auf fehlerhafte Anfragen oder Auth-Probleme.
• HTTP 5xx vom eigenen Server.
• Fehler des Modellanbieters, etwa Ratenlimits (HTTP 429) oder Serverfehler.
• Tool-Fehler, bei denen ein Tool-Aufruf innerhalb einer sonst normalen Antwort scheitert.
• Timeouts.

Alarmieren Sie auf die Rate über ein Zeitfenster, nicht auf einen einzelnen Fehler. Zum Beispiel: Alarm, wenn die Fehler mehrere Minuten über einem festgelegten Anteil der Anfragen liegen. Wählen Sie die Werte anhand Ihres normalen Verkehrs. Einen allgemeingültigen "guten" Wert gibt es nicht.

Schritt 5: Heartbeats für Hintergrund-Agenten

Manche Agenten haben keine öffentliche URL. Sie laufen nach Zeitplan oder lesen aus einer Warteschlange.

Nutzen Sie dafür einen Heartbeat (auch Dead-Man's-Switch genannt). Der Job sendet nach jedem erfolgreichen Lauf einen kleinen Ping an eine Monitoring-URL. Kommt der Ping nicht rechtzeitig an, erhalten Sie einen Alarm.

Senden Sie den Ping erst, wenn der Job seine Arbeit wirklich beendet hat. Ein Ping zu Beginn beweist nichts.

Ein Tool wählen und Alarme einrichten

Jedes Uptime-Tool, das eigene HTTP-Methoden, Anfragekörper, Header und Inhaltsprüfungen unterstützt, erledigt diese Aufgabe. Uptrack (vom 2folk-Team) ist eine Option unter mehreren. Vergleichen Sie Tools anhand dieser Funktionen, nicht anhand der Zahl der Checks.

Senden Sie Alarme an einen Kanal, den Ihr Team wirklich liest. Nutzen Sie mindestens zwei Kanäle, zum Beispiel E-Mail und Chat. Testen Sie den Alarmweg einmal pro Quartal.

Eine kurze Checkliste

• Ein Monitor für den öffentlichen Endpunkt, mit Inhaltsprüfung.
• Ein Monitor für die Authentifizierung mit gültigem Test-Zugangsdatum.
• Eine Prüfung, dass Aufrufe ohne Anmeldung abgelehnt werden.
• Warn- und Ausfallgrenzen für die Latenz.
• Fehlerraten aus echtem Verkehr.
• Ein Heartbeat für jeden Hintergrund-Job.
• Alarme an zwei Kanäle, getestet.

Häufige Fragen

Wie oft sollte ich einen MCP-Server prüfen?

Prüfen Sie einen leichten Endpunkt alle ein bis fünf Minuten. Führen Sie einen vollständigen Tool-Aufruf seltener aus, zum Beispiel alle 15 Minuten, um Kosten und Last zu begrenzen. Wählen Sie das Intervall danach, wie schnell Sie von einem Ausfall wissen müssen.

Kann ich ein normales Uptime-Tool für einen KI-Agenten nutzen?

Ja, wenn es eine POST-Anfrage mit Körper und Headern senden und den Antworttext prüfen kann. Ein Tool, das nur HTTP 200 auf eine GET-Anfrage prüft, übersieht die meisten echten Fehler.

Sollen Monitoring-Aufrufe das echte Sprachmodell nutzen?

Tun Sie das sparsam. Jeder Modellaufruf kostet Geld und erzeugt Last. Prüfen Sie den Modellpfad mit einem seltenen, kurzen Testaufruf und nutzen Sie für häufige Checks leichte Endpunkte.

Was tue ich, wenn der Modellanbieter ausfällt?

Ihr eigener Server läuft, aber die Funktion nicht. Zeigen Sie Nutzern eine klare Meldung und nutzen Sie einen Ersatzweg, etwa eine gespeicherte Antwort oder die Übergabe an einen Menschen. Melden Sie den Status dann auf Ihrer Statusseite.