Zum Hauptinhalt springen

Runtime-Events untersuchen

Runtime-Events zeigen, was LightNow Proxy während einer AI-Client-Session erreicht hat. Nutze sie, nachdem Client-Status und Proxy-Health feststehen: Events erklären den Request-Pfad, lokale Checks die aktuelle Konfiguration.

Was ein Event belegen kann​

FrageNützliche Felder
Hat der Client LightNow erreicht?Zeitpunkt, MCP-Client, Runner, Profil, Eventtyp
Wohin wurde der Request geroutet?Server-Alias, Servername, Tool-Name, ursprünglicher Tool-Name, Resource-URI
War er erfolgreich?Status, Fehlertyp, Fehlermeldung
War er langsam?Dauer, Request- und Response-Größe, Anzahl der Response-Elemente

LightNow speichert freigegebene Metadaten wie die Namen von Argumenten und die Response-Form. Rohe Tool-Argumente, Tool-Ergebnisse, Resource-Inhalte, Authorization-Header und Secret-Werte werden nicht als Runtime-Events gespeichert.

1. Telemetrie und Erreichbarkeit bestätigen​

Runtime-Events entstehen nur, wenn Telemetrie für LightNow Proxy aktiviert ist. Die lokale Proxy-Konfiguration speichert dies als local_proxy.telemetry_enabled.

Status, Telemetrie und Health prüfen
lightnow config-status --client codex --json
grep -n "telemetry_enabled" ~/.lightnow/lightnow-proxy/codex.yaml
lightnow-proxy --config ~/.lightnow/lightnow-proxy/codex.yaml --health --json

Bei deaktivierter Telemetrie funktionieren lokale Status- und Health-Checks weiterhin, neue Requests erscheinen aber nicht in Insights. Ist der Client nicht verwaltet oder Health fehlerhaft, korrigiere zuerst diese Grenze.

2. Eine Aktion reproduzieren​

  1. Öffne Insights in der LightNow App.
  2. Wähle das Runtime Profile des betroffenen Clients.
  3. Wähle ein kurzes Fenster wie 15m und grenze Eventtyp oder Status ein.
  4. Löse genau eine Client-Aktion aus.
  5. Warte auf die Aktualisierung und öffne das neueste passende Event.

Insights aktualisiert sich alle 10 Sekunden. Eine einzelne Reproduktion lässt sich leichter zuordnen als eine lange Session mit mehreren Agents oder Tool Calls.

3. Das erste brauchbare Signal lesen​

BeobachtungBedeutungNächster Schritt
Kein passendes EventDer Client hat diesen Proxy beziehungsweise dieses Profil nicht erreicht, Telemetrie ist aus oder die Session nutzt alte Config.Kehre zu config-status zurück, starte den Client neu und prüfe den Kontext.
list_tools ist erfolgreichProxy-Routing und Upstream-Discovery funktionieren.Untersuche Client-Cache oder Darstellung.
call_tool schlägt fehlDer Request erreichte den gewählten Server, die Ausführung scheiterte jedoch.Vergleiche Server-Alias, Fehlertyp, Laufzeit und aktuellen Proxy-Health-Status.
Events sind erfolgreich, aber langsamDas Routing funktioniert; die Latenz ist das Problem.Vergleiche das Event mit der Insights-Latenzanalyse für denselben Server und Zeitraum.

Resource-Aktivität verwendet list_resources, list_resource_templates und read_resource. Tool-Aktivität verwendet list_tools und call_tool.

Bei Bedarf die API abfragen​

Nutze die API für einen kleinen Support-Auszug oder eine skriptbare Diagnose. Das gewählte Konto benötigt Zugriff auf den Personal- oder Organisationskontext.

Fehlerhafte Tool Calls der letzten Stunde auflisten
curl -sS -H "Authorization: Bearer $LIGHTNOW_TOKEN" "https://registry-api.lightnow.ai/v0.1/integrations/runtime-events?profile=default&event_type=call_tool&status=error&window=1h&limit=20" | jq '.events[] | {created_at, server_alias, original_tool_name, error_type, duration_ms, argument_keys}'

Unterstützte Filter sind profile, event_type, status, client_name, mcp_client_name, runner_name, server_alias, tool_name, resource_uri, window und limit. Zeitfenster sind 15m, 1h, 6h, 24h, 7d und 30d; limit akzeptiert 1 bis 100.

Untersuchung abschließen​

Notiere Zeitpunkt, Profil, Client, Server-Alias, Eventtyp, Status, Dauer und gegebenenfalls die Korrelations-ID. Ordne den Fix danach der verantwortlichen Grenze zu: Client- und Proxy-Status, Runtime-Secrets und Konfiguration oder dem Upstream-MCP-Server.