MCP als Beobachtbarkeitsschnittstelle: Verbindung von KI-Agenten mit Kernel-Tracepoints

Das Model Context Protocol (MCP) wird zur Schnittstelle zwischen KI-Agenten und Infrastrukturdaten. Im März 2026 verdeutlichten drei bedeutende Entwicklungen diesen Trend: Datadog lieferte einen MCP-Server aus, der Echtzeit-Observability-Daten mit KI-Agenten für automatisierte Erkennung und Behebung verbindet, Qualys veröffentlichte eine Sicherheitsanalyse, die MCP-Server als "das neue Schatten-IT für KI" bezeichnete, und Microsoft Retina demonstrierte eBPF-basierte Kubernetes-Netzwerkobservability.

Zwei Ansätze für MCP-Observability

Es gibt zwei Möglichkeiten, Observability-Daten über MCP mit KI-Agenten zu verbinden:

• Ansatz 1: Bestehende Plattformen einbinden - Datadogs Strategie nimmt bereits gesammelte und aggregierte Metriken, Logs und Traces und stellt sie über MCP-Tools bereit. Der KI-Agent fragt die Dashboard-API ab, erhält vorverarbeitete Daten und handelt darauf. Dies funktioniert für Teams mit ausgereiften Observability-Stacks, die KI-gestützte Automatisierung darauf aufbauen möchten.
• Ansatz 2: MCP-native Observability aufbauen - Anstatt eine bestehende Plattform einzubinden, wird ein eBPF-Agent erstellt, der Systemaufrufe über Uprobes verfolgt, Ergebnisse in SQLite speichert und alles über MCP-Tools verfügbar macht. Die MCP-Schnittstelle wird zur primären Schnittstelle, nicht zu einer Adapter-Schicht.

MCP-native Observability in der Praxis

Der Artikel beschreibt ein konkretes Beispiel zur Verfolgung einer vLLM-TTFT-Regression, bei der das erste Token 14,5-mal länger als der Basiswert dauerte. Die Trace-Datenbank erfasste jeden CUDA-API-Aufruf, jeden Kernel-Kontextwechsel und jede Speicherzuweisung. Wenn Claude sich mit dem MCP-Server verbindet und diese Datenbank lädt, kann er vier spezifische Tools nutzen:

• get_trace_stats - Zeigt die vollständige Trace-Zusammenfassung: 12.847 CUDA-Ereignisse, 4 Kausalketten, gesamte GPU-Zeit
• get_causal_chains - Liest die Kausalketten, die erklären, warum die Latenz sprunghaft anstieg, in einfachem Englisch
• run_sql - Führt benutzerdefinierte Abfragen gegen Roh-Ereignisdaten aus (z.B. "zeige mir alle cudaMemcpyAsync-Aufrufe über 100ms")
• get_stacks - Untersucht Aufrufstapel für jedes markierte Ereignis

Claude identifizierte die Ursache in weniger als 30 Sekunden: Die Logprobs-Berechnung blockierte die Decode-Schleife und verursachte eine 256-fache Verlangsamung auf dem kritischen Pfad. Diese Ursache war in aggregierten Metriken nicht sichtbar, nur in rohen Kausalketten zwischen spezifischen CUDA-API-Aufrufen.

Sicherheitsüberlegungen

Qualys stellte fest, dass über 53 % der MCP-Server auf statische Geheimnisse zur Authentifizierung angewiesen sind, und empfahl, Observability für MCP-Server hinzuzufügen: Protokollierung von Capability-Entdeckungsereignissen, Überwachung von Aufrufmustern und Alarmierung bei Anomalien. Für MCP-Server, die auf GPU-Infrastruktur zugreifen, umfasst die Angriffsfläche Timing-Informationen, Speicherlayouts und Modelldetails.

In Ingeros Implementierung wird jeder MCP-Tool-Aufruf mit derselben eBPF-Infrastruktur verfolgt, die GPU-Ereignisse erfasst, wodurch eine einheitliche Observability-Pipeline entsteht, anstatt einer separaten Protokollierungsschicht.