Monitoring neu gedacht: Wie ein modellagnostischer MCP-Server OpenSearch und Co. mit KI verbindet

12.5.2025

Stellen Sie sich vor, Sie könnten ein Monitoring-System einfach per Sprache steuern – ganz ohne komplexe Abfragen, CLI-Kommandos oder Tool-Hopping. Genau das ermöglicht ein neu entwickelter, modularer AI Monitoring Assistant auf Basis eines MCP-Servers.

In modernen IT-Infrastrukturen ist die effektive Überwachung komplexer Systeme essenziell, um Ausfallzeiten zu minimieren, Sicherheitsrisiken frühzeitig zu erkennen und Betriebsprozesse zu optimieren. Die Integration von Künstlicher Intelligenz (KI) in das Monitoring verspricht dabei nicht nur eine tiefere Einsicht in Betriebszustände, sondern auch die Möglichkeit, wiederkehrende Anfragen automatisiert zu bearbeiten oder komplexe Zusammenhänge zu erkennen. Der hier vorgestellte Ansatz setzt auf einen modellagnostischen AI Monitoring Assistant, der mithilfe eines eigens entwickelten Model Context Protocol (MCP)-Servers eine flexible und erweiterbare Architektur für KI-gestütztes Monitoring bietet – mit einem initialen Fokus auf OpenSearch und Perspektiven für die Anbindung weiterer Systeme wie SSH, Grafana, Icinga oder ElasticSearch.

Was ist der MCP-Server – und warum ist das spannend?

Der Model Context Protocol (MCP)-Server ist eine smarte Vermittlungsinstanz zwischen Sprachmodellen und Monitoring-Systemen wie OpenSearch, SSH, Grafana oder Icinga.

Sie geben ein, was Sie wissen wollen – etwa: „Zeig mir alle Indizes, die gestern geändert wurden“ – und der Server übersetzt das in passende API- oder Shell-Kommandos. Ergebnis: Sie bekommen direkt die relevanten Daten – ganz ohne manuelles Tippen von Abfragen. Der Clou: Das Ganze ist modellagnostisch. Ob OpenAI, Mistral, Llama oder ein lokales LLM (z.B. AIR) – der MCP-Server funktioniert mit allen. So bleibt Ihre Monitoring-Architektur flexibel, sicher und zukunftsfähig.

So funktioniert’s: Tools, Abfragen, Antworten

Der MCP-Server nutzt ein Set an Tools, die wie Bausteine definieren, was das System ausführen darf. Für OpenSearch sind das beispielsweise REST-Requests wie usw.

 _search, _cat/indices, _cluster/health

Das Sprachmodell wählt basierend auf Ihrer Eingabe das passende Tool aus, der Server führt es aus – und liefert die Antwort zurück ans Modell. Das Ergebnis: echte KI-gestützte Monitoring-Dialoge, mit validierten Operationen und kontrollierter Ausführung.

1. Ausgangslage: Monitoring trifft auf KI

Klassisches IT-Monitoring basiert auf dedizierten Tools, vordefinierten Regeln und oft auch auf einer Vielzahl heterogener Datenquellen – von Systemmetriken über Logs bis hin zu externen APIs. Mit der zunehmenden Verbreitung von Machine Learning und generativer KI ergeben sich neue Möglichkeiten, diese Daten nicht nur zu sammeln, sondern auch intelligent zu verarbeiten. Sprachmodelle können etwa genutzt werden, um Anfragen in natürliche Sprache zu interpretieren und automatisiert die passenden Abfragen an technische Systeme zu übermitteln. Genau hier setzt der MCP-Server an.

2. Der MCP-Server: Architektur und Funktionsweise

Das zentrale Element der Lösung ist ein sogenannter Model Context Protocol (MCP)-Server. Dieser agiert als Vermittlungsinstanz zwischen einem Sprachmodell – sei es lokal oder in der Cloud – und einem Set definierter Tools. Diese Tools können dabei beliebige technische Schnittstellen oder Befehlsmuster repräsentieren, etwa die REST API von OpenSearch oder vordefinierte Kommandos auf einem SSH-Server.

Modellagnostik als Kernprinzip

Ein zentrales Designziel des MCP-Servers war die Modellagnostik. Das bedeutet, dass der Server unabhängig vom eingesetzten Sprachmodell arbeitet. Ob ein Open-Source-Modell lokal ausgeführt oder ein cloudbasiertes LLM verwendet wird – der MCP-Server kann in beiden Szenarien genutzt werden. Diese Unabhängigkeit ermöglicht es, die Lösung in unterschiedlichen Datenschutz- und Sicherheitskontexten einzusetzen, etwa auch in abgeschotteten Unternehmensnetzwerken oder hochsensiblen Bereichen mit hohen Compliance-Anforderungen.

Funktionsweise im Detail

Der MCP-Server wird mit einem Set an Tools konfiguriert, die als ausführbare Operationen dienen. Im Fall von OpenSearch handelt es sich beispielsweise um eine Sammlung zulässiger REST-Requests wie und weitere.

GET _cat/indices, POST _search, GET _cluster/health

Ein an das Sprachmodell gerichteter Prompt – etwa: "Zeig mir alle Indizes, die in den letzten 24 Stunden verändert wurden" – wird durch das Sprachmodell in einen konkreten Tool-Call übersetzt, den der MCP-Server ausführt. Das Ergebnis wird anschließend aufbereitet und zurück an das Modell übergeben, um ggf. eine sprachlich interpretierte Antwort zu generieren. Der Server bildet damit die Brücke zwischen natürlicher Sprache und technischen Monitoring-Operationen. Für die Integration von MCP-Server mit einem Sprachmodell braucht es einen MCP-Client (z.B. der freie Client 5ire). Praktisch die Benutzerschnittstelle zur Entgegennahme Ihrer natürlichsprachlichen Fragen und Befehle. Über den MCP-Server, die Augen und Ohren der AIOps-Lösung, werden dann Fakten gesammelt und Aktionen durchgeführt.

3. OpenSearch als Einstiegspunkt

Die erste Implementierung des MCP-Servers fokussiert sich auf die Integration mit OpenSearch, einer freien und performanten Such- und Analyseplattform für strukturierte und unstrukturierte Daten. Der Zugriff erfolgt über die REST-basierte OpenSearch API, die durch das Toolset des MCP-Servers abgebildet wird. Dieselbe API die auch in unserem auf OpenSearch basierten Protokollmonitoring LOMOC verwendbar ist. Durch diese Integration lassen sich mit einfachen Spracheingaben komplexe Suchabfragen oder Metrik-Auswertungen in OpenSearch ausführen. Beispiele sind:

• Abfrage des Cluster-Zustands
• Durchsuchen von Logs nach bestimmten Fehlern
• Analyse der größten Indizes im System
• Ermittlung der durchschnittlichen Antwortzeiten für einen Zeitraum

Dieser Ansatz ermöglicht auch weniger technisch versierten Nutzern, tiefere Einblicke in das Monitoring-Backend zu erhalten – ohne fundierte Kenntnisse in Query-DSL oder API-Nutzung.

4. Erweiterung auf weitere Systeme: SSH, Grafana, Icinga

Ein entscheidender Vorteil des MCP-Servers ist seine Modularität. Die Abstraktion über Tools erlaubt es, beliebige weitere Systeme einzubinden. Im nächsten Entwicklungsschritt wurden daher auch einfache SSH-Kommandos als Toolset eingebunden. Dabei wird besonders auf Sicherheit geachtet: Nur sogenannte "safe commands" wie htop, free -m, ps aux oder df -h sind zugelassen.

Diese Integration eröffnet neue Möglichkeiten:

• Zugriff auf Servermetriken über SSH, um Engpässe oder Lastverteilungen zu analysieren
• Analyse laufender Prozesse bei auffälligem Verhalten
• Kombinierte Auswertung von Logdateien und Systemzustand

Ebenso denkbar ist die Anbindung an Visualisierungssysteme wie Grafana oder Monitoringlösungen wie Icinga2 bzw. COMMOC. Auch hier erfolgt die Kommunikation über definierte API-Calls oder sichere Kommandos, die vom Sprachmodell via MCP ausgeführt werden können. Bald stellen wir Ihnen hier die entsprechende Lösung vor.

5. Sicherheitsaspekte und Governance

Die Nutzung generativer KI in produktiven Monitoringprozessen erfordert strenge Sicherheits- und Governance-Mechanismen. Um das Ausführen gefährlicher oder potenziell schädlicher Kommandos zu vermeiden, implementiert der MCP-Server eine Whitelisting-Logik, die nur explizit zugelassene Tools ausführen lässt. Jegliche Versuche, nicht autorisierte Aktionen zu initiieren, werden erkannt und unterbunden.

Darüber hinaus lässt sich das System in abgeschotteten Netzwerken betreiben, etwa durch die Kombination mit lokal laufenden Sprachmodellen und restriktiv konfigurierten Toolsets. Dies ermöglicht auch den Betrieb in Umgebungen mit hohen Anforderungen an Datenschutz, Compliance und Betriebsstabilität.

6. Anwendungsbeispiele aus der Praxis

Die praktische Nutzbarkeit des AI Monitoring Assistants zeigt sich in einer Vielzahl von Anwendungsszenarien. Nachfolgend einige exemplarische Use Cases:

• Incident Analyse in Echtzeit: Bei ungewöhnlichen Verhaltensmustern oder Systemausfällen kann ein Operator über das Sprachmodell unmittelbar Abfragen formulieren, z. B. „Welche Fehler gab es in den letzten 30 Minuten im Cluster X?“ Das Modell übersetzt die Anfrage in OpenSearch- oder SSH-Kommandos, liefert die Resultate und ggf. eine sprachliche Interpretation.
• Proaktive Kapazitätsplanung: Auf Basis historischer Lastwerte und Speicherverbrauch kann über einfache Eingaben wie „Zeige mir, wann die Speichernutzung in den letzten 7 Tagen über 90 % lag“ eine fundierte Planung initiiert werden.
• Monitoring-Dashboards per Sprache bedienen: Durch Integration in Visualisierungstools wie Grafana lässt sich auch die Dashbord-Interaktion vereinfachen. Etwa: „Zeig mir das CPU-Dashboard vom Server web01 für gestern“.
• Compliance Checks und Betriebskennzahlen: Über SSH- oder API-basierte Tools können regelmäßig Audit-Daten abgefragt, Systemzustände dokumentiert und Schwachstellen kommuniziert werden – auch in natürlichsprachlicher Form.

Wie unser AI Monitoring Assistant einen LOMOC-Cluster reparierte

Die Ausgangsfrage war, warum einer unserer LOMOC-Cluster einen gelben Health-Status anzeigt. Bevor wir in die Details der Problemlösung eingestiegen sind habe wir den AI Assistenten die Architektur des Cluster ergründen lassen:

„please list the nodes in my cluster“

Im nächsten Schritt wollten wir vom AI Assistenten wissen welche Daten in diesem Cluster gespeichert und indiziert sind:

„what indices does it have“

Unser AI Assistant hat bei der Beantwortung dieser Frage schon selbstständig herausgefunden, dass der Cluster sich im Status „Gelb“ befindet.

Wir fragen nochmals detaillierter nach dem Status des Clusters.

„can you check the health of lomoc-cluster"

Das finden wir interessant – und beginnen unserem „5-why“ Ansatz für Root-Cause-Analysen mit folgender Warum-Frage:

„why are there unassigned shards”

Wir verzichten auf weitere Warum-Fragen und kommen geradeaus zum Punkt – wir wollen das Problem gelöst haben:

„what requests should I send to fix this?”

Unser AI-Assistent schließt automatisch aus unserer Frage, dass wir den Cluster reparieren wollen und bietet von sich aus an ab jetzt den Cluster-Status auf die Lösung des Problems hin zu überprüfen.

Wir gehen auf seine Frage nur indirekt ein – setzen aber seinen Vorschlag um:

„i have done this now, is the health better?”

Der AI Monitoring Assistent erkennt eine Verbesserung – die Maßnahme scheint zu wirken.

Der Assistent weiß, dass die Lösung etwas länger dauern kann und bietet an, die Abarbeitung zu überwachen.

Wir fragen nach einiger Zeit nach:

„can you check again?"

Der Assistant stellt den Fortschritt fest und schliesst aus der Veränderung der zugrundeliegenden Metriken wie ein menschlicher Administrator auf die Korrektheit des laufenden Reperaturprozesses.

Nach einiger Zeit stellen wir voller Erwartung die finale Frage:

„can you check the health now?"

Der AI Monitoring Assistant hat die die korrekte Funktion des Clusters erkannt und gibt uns netterweise noch eine Zusammenfassung über die Ausgangssituation und den aktuellen Zustand:

nur 56.7% aktive Shards – jetzt 100%. So einfach.

7. Zukunftsperspektiven und Weiterentwicklung

Das hier vorgestellte System legt die Grundlage für eine neue Klasse von intelligenten Monitoring-Assistenten, die durch ihre Modularität, Modellagnostik und Sicherheit überzeugen. Perspektivisch ergeben sich eine Vielzahl von Erweiterungsmöglichkeiten:

• Integration in SIEM- und SOAR-Plattformen für automatisierte Alarmreaktionen
• Self-Service-Interfaces für Non-Tech-User, z. B. Helpdesk-Teams oder Fachbereiche
• Erklärbare KI (XAI) zur transparenten Darstellung, warum eine bestimmte Monitoring-Entscheidung oder Auswertung getroffen wurde
• Training domänenspezifischer Modelle für besonders kritische Infrastrukturen (KRITIS)

Auch die Kombination mit Event-Korrelation und AIOps-Plattformen wie AIR eröffnet neue Horizonte für autonome Betriebsprozesse und vorausschauende Fehlervermeidung.

8. Cyberrisiken von MCP-Clients und MCP-Servern – und warum europäische Lösungen entscheidend sind

Der Betrieb von MCP-Clients und MCP-Servern eröffnet neue Angriffsflächen innerhalb moderner IT-Infrastrukturen. Da diese Komponenten als Vermittler zwischen Sprachmodellen und produktiven Systemen fungieren, besteht bei Fehlkonfiguration, mangelnder Zugriffskontrolle oder unzureichender Protokollierung ein erhebliches Cyberrisiko. Ein kompromittierter MCP-Client könnte manipulierte Eingaben an ein Sprachmodell übermitteln oder nicht autorisierte Aktionen über den Server auslösen. Ebenso kann ein unsicherer MCP-Server als Einfallstor dienen, um interne APIs oder Kommandozeilenwerkzeuge mit schadhaften Abfragen zu missbrauchen.

Besonders kritisch ist, wenn diese Komponenten über Cloudlösungen oder APIs betrieben werden, deren Infrastruktur außerhalb Europas liegt. Damit steigt das Risiko durch Drittstaatenzugriffe, unzureichende Verschlüsselung oder staatliche Überwachung. In sicherheitskritischen Bereichen wie KRITIS, Behörden oder Finanzwesen sind solche Szenarien nicht tragbar.

Die Nutzung europäischer MCP-Clients und MCP-Server – entwickelt, betrieben und gehostet innerhalb der EU – bietet daher eine deutlich bessere Sicherheitsgrundlage. Sie unterliegen der europäischen Gesetzgebung, ermöglichen eine nachvollziehbare Sicherheitsarchitektur und vermeiden Abhängigkeiten von extraterritorialen Dienstleistern. Für europäische Infrastrukturen ist dies nicht nur ein strategischer Vorteil, sondern eine zwingende Voraussetzung für eine widerstandsfähige, vertrauenswürdige KI-Integration.

Fazit

Mit dem in Entwicklung befindlichen MCP-Server entsteht eine robuste, sichere und erweiterbare Infrastruktur für die Integration von Sprachmodellen in das technische Monitoring. Die Fähigkeit, Systemanfragen in natürlicher Sprache zu stellen und in konkretes Monitoring-Handeln zu überführen, markiert einen entscheidenden Fortschritt in der Mensch-Maschine-Interaktion. Durch die Offenheit für verschiedenste Tools – von OpenSearch über SSH bis zu Grafana, LOMOC, COMMOC, SIEMOC – sowie die Modellagnostik bietet das System eine ideale Grundlage für skalierbare, KI-gestützte Monitoring-Architekturen der nächsten Generation.

Sie wollen es ausprobieren?

Dann reden Sie mit unseren Experten. Ob Proof of Concept, Integration in bestehende Systeme oder Erweiterung auf Ihre Infrastruktur – wir zeigen Ihnen, wie Sie mit einem MCP-Server den nächsten Monitoring-Level erreichen und mit COMMOC, LOMOC und SIEMOC die perfekte Basis für Ihre AIOps Strategie bilden können.