Von Terabytes zu Erkenntnissen: Realwelt-KI-Beobachtungsarchitektur

Stellen Sie sich die Wartung und Entwicklung einer E-Commerce-Plattform vor, die pro Minute Millionen von Transaktionen verarbeitet und dabei große Mengen an Telemetriedaten generiert, darunter Metriken, Protokolle und Traces über mehrere Microservices hinweg. Bei kritischen Vorfällen stehen die Bereitschaftstechniker vor der gewaltigen Aufgabe, einen Ozean an Daten zu durchforsten, um relevante Signale und Erkenntnisse zu gewinnen. Das ist vergleichbar mit der Suche nach der Nadel im Heuhaufen.

Dies macht Observability eher zu einer Quelle der Frustration als der Erkenntnisgewinnung. Um dieses große Problem zu lösen, begann ich mit der Suche nach einer Lösung, die das Model Context Protocol (MCP) nutzt, um Kontext hinzuzufügen und Schlussfolgerungen aus Protokollen und verteilten Traces zu ziehen. In diesem Artikel schildere ich meine Erfahrungen beim Aufbau einer KI-gestützten Observability-Plattform, erkläre die Systemarchitektur und teile die dabei gewonnenen Erkenntnisse.

In modernen Softwaresystemen ist Beobachtbarkeit kein Luxus, sondern eine grundlegende Notwendigkeit. Die Fähigkeit, das Systemverhalten zu messen und zu verstehen, ist grundlegend für Zuverlässigkeit, Leistung und Benutzervertrauen. Wie heißt es so schön: „Was man nicht messen kann, kann man auch nicht verbessern.“

Dennoch ist es schwieriger denn je, in den heutigen Cloud-nativen, auf Microservices basierenden Architekturen Observability zu erreichen. Eine einzelne Benutzeranfrage kann Dutzende von Microservices durchlaufen, die jeweils Protokolle, Metriken und Traces ausgeben. Das Ergebnis ist eine Fülle von Telemetriedaten:

• Dutzende Terabyte an Protokollen pro Tag
• Dutzende Millionen metrischer Datenpunkte und Voraggregate
• Millionen verteilter Spuren
• Tausende von Korrelations-IDs werden jede Minute generiert

Die Herausforderung besteht nicht nur im Datenvolumen, sondern auch in der Datenfragmentierung. Laut dem Observability Forecast Report 2023 von New Relic berichten 50 % der Unternehmen von isolierten Telemetriedaten, und nur 33 % erreichen eine einheitliche Sicht auf Metriken, Protokolle und Traces.

Protokolle erzählen einen Teil der Geschichte, Metriken einen anderen, Spuren noch einen anderen. Ohne einen durchgängigen Kontext sind Ingenieure gezwungen, die Korrelation manuell vorzunehmen und sich bei Vorfällen auf Intuition, Stammeswissen und mühsame Detektivarbeit zu verlassen.

Aufgrund dieser Komplexität begann ich mich zu fragen: Wie kann uns KI dabei helfen, fragmentierte Daten zu überwinden und umfassende, nützliche Erkenntnisse zu liefern? Können wir Telemetriedaten mithilfe eines strukturierten Protokolls wie MCP sowohl für Menschen als auch für Maschinen grundsätzlich aussagekräftiger und zugänglicher machen? Diese zentrale Frage prägte die Grundlage dieses Projekts.

Anthropic definiert MCP als offenen Standard, der es Entwicklern ermöglicht, eine sichere bidirektionale Verbindung zwischen Datenquellen und KI-Tools herzustellen. Diese strukturierte Datenpipeline umfasst:

• Kontextuelles ETL für KI: Standardisierung der Kontextextraktion aus mehreren Datenquellen.
• Strukturierte Abfrageschnittstelle: Ermöglicht KI-Abfragen den Zugriff auf transparente und leicht verständliche Datenebenen.
• Semantische Datenanreicherung: Bettet aussagekräftigen Kontext direkt in Telemetriesignale ein.

Dadurch besteht das Potenzial, die Plattformbeobachtung weg von der reaktiven Problemlösung und hin zu proaktiven Erkenntnissen zu verlagern.

Bevor wir uns in die Implementierungsdetails vertiefen, gehen wir die Systemarchitektur durch.

In der ersten Ebene entwickeln wir die kontextbezogenen Telemetriedaten, indem wir standardisierte Metadaten wie verteilte Traces, Protokolle und Metriken in die Telemetriesignale einbetten. Anschließend werden in der zweiten Ebene angereicherte Daten in den MCP-Server eingespeist, um diese zu indizieren, zu strukturieren und Clients über APIs Zugriff auf kontextangereicherte Daten zu gewähren. Schließlich nutzt die KI-gesteuerte Analyse-Engine die strukturierten und angereicherten Telemetriedaten zur Anomalieerkennung, Korrelation und Ursachenanalyse, um Anwendungsprobleme zu beheben.

Dieses mehrschichtige Design stellt sicher, dass KI- und Entwicklungsteams kontextbezogene, umsetzbare Erkenntnisse aus Telemetriedaten erhalten.

Lassen Sie uns die tatsächliche Implementierung unserer MCP-gestützten Observability-Plattform untersuchen und uns dabei auf die Datenflüsse und Transformationen in jedem Schritt konzentrieren.

Ebene 1: Kontextangereicherte Datengenerierung

Zunächst müssen wir sicherstellen, dass unsere Telemetriedaten genügend Kontext für eine aussagekräftige Analyse enthalten. Die wichtigste Erkenntnis ist, dass die Datenkorrelation zum Zeitpunkt der Erstellung und nicht zum Zeitpunkt der Analyse erfolgen muss.

def process_checkout(user_id, cart_items, payment_method): „““Simulieren Sie einen Checkout-Prozess mit kontextangereicherter Telemetrie.“““ # Korrelations-ID generieren Bestell-ID = f „Bestellung-{uuid.uuid4().hex[:8]}“ Anfrage-ID = f „Anforderung-{uuid.uuid4().hex[:8]}“ # Kontextwörterbuch initialisieren, das angewendet wird Kontext = { „Benutzer-ID“: Benutzer-ID, „Bestell-ID“: Bestell-ID, „Anforderungs-ID“: Anforderungs-ID, „Warenkorbartikelanzahl“: Länge(Warenkorbartikel), „Zahlungsmethode“: Zahlungsmethode, „Dienstname“: „Kasse“, „Dienstversion“: „v1.0.0“ } # OTel-Trace mit demselben Kontext starten mit tracer.start_as_current_span( „process_checkout“, Attribute={k: str(v) für k, v in context.items()} ) als checkout_span: # Protokollierung im gleichen Kontext logger.info(f”Checkout-Prozess wird gestartet”, extra={“Kontext”: json.dumps(Kontext)}) # Kontextausbreitung mit tracer.start_as_current_span("process_payment"): # Zahlungslogik verarbeiten… logger.info(“Zahlung verarbeitet”, extra={“Kontext”: json.dumps(Kontext)})

Code 1. Kontextanreicherung für Protokolle und Spuren

Dieser Ansatz stellt sicher, dass jedes Telemetriesignal (Protokolle, Metriken, Spuren) dieselben zentralen Kontextdaten enthält, wodurch das Korrelationsproblem an der Quelle gelöst wird.

Als Nächstes habe ich einen MCP-Server erstellt, der Rohtelemetriedaten in eine abfragbare API umwandelt. Die wichtigsten Datenoperationen umfassen dabei Folgendes:

1. Indizierung : Erstellen effizienter Nachschlagevorgänge über Kontextfelder hinweg
2. Filtern : Auswählen relevanter Teilmengen von Telemetriedaten
3. Aggregation : Berechnung statistischer Maße über Zeitfenster hinweg

@app.post(“/mcp/logs”, response_model=List[Log])def query_logs(query: LogQuery): “””Abfrageprotokolle mit bestimmten Filtern””” Ergebnisse = LOG_DB.copy() # Kontextfilter anwenden if query.request_id: Ergebnisse = [Protokoll für Anmeldeergebnisse if log[“context”].get(“request_id”) == query.request_id] if query.user_id: Ergebnisse = [Protokoll für Anmeldeergebnisse if log[“context”].get(“user_id”) == query.user_id] # Zeitbasierte Filter anwenden if query.time_range: Startzeit = datetime.fromisoformat(query.time_range[“start”]) Endzeit = datetime.fromisoformat(query.time_range[“end”]) Ergebnisse = [Protokoll für Anmeldeergebnisse if Startzeit <= datetime.fromisoformat(log[“timestamp”]) <= Endzeit] # Sortieren nach Zeitstempel Ergebnisse = sortiert (Ergebnisse, Schlüssel = Lambda x: x [„Zeitstempel“], umgekehrt = Wahr) returniere Ergebnisse[:query.limit] wenn query.limit sonst Ergebnisse

Code 2. Datentransformation mit dem MCP-Server

Diese Schicht wandelt unsere Telemetrie von einem unstrukturierten Datensee in eine strukturierte, abfrageoptimierte Schnittstelle um, die ein KI-System effizient navigieren kann.

Die letzte Schicht ist eine KI-Komponente, die Daten über die MCP-Schnittstelle nutzt und folgende Aufgaben ausführt:

1. Mehrdimensionale Analyse : Korrelieren von Signalen über Protokolle, Metriken und Spuren hinweg.
2. Anomalieerkennung : Identifizierung statistischer Abweichungen von normalen Mustern.
3. Ermittlung der Grundursache : Verwenden Sie kontextbezogene Hinweise, um wahrscheinliche Problemquellen zu isolieren.

def analyze_incident(self, request_id=None, user_id=None, timeframe_minutes=30): „““Analysieren Sie Telemetriedaten, um die Grundursache und Empfehlungen zu ermitteln.“““ # Analysezeitfenster definieren Endzeit = Datum/Uhrzeit.jetzt() Startzeit = Endzeit – Zeitdelta(Minuten=Zeitrahmen_Minuten) Zeitbereich = {„Start“: Startzeit.isoformat(), „Ende“: Endzeit.isoformat()} # Relevante Telemetriedaten basierend auf dem Kontext abrufen Protokolle = self.fetch_logs(Anforderungs-ID=Anforderungs-ID, Benutzer-ID=Benutzer-ID, Zeitbereich=Zeitbereich) # Extrahieren Sie in Protokollen erwähnte Dienste für eine gezielte Metrikanalyse services = set(log.get(„service“, „unknown“) für Anmeldeprotokolle) # Holen Sie sich Metriken für diese Dienste metrics_by_service = {} für Service in Services: für metric_name in [„Latenz“, „Fehlerrate“, „Durchsatz“]: metric_data = self.fetch_metrics(Service, metric_name, Zeitbereich) # Statistische Eigenschaften berechnen Werte = [Punkt[„Wert“] für Punkt in Metrikdaten[„Datenpunkte“]] Metriken nach Dienst[f“{Dienst}.{Metrikname}“] = { „Mittelwert“: Statistik.Mittelwert(Werte) wenn Werte sonst 0, „Median“: Statistik.Median(Werte) wenn Werte sonst 0, „Standardabweichung“: Statistik.Standardabweichung(Werte) wenn Länge(Werte) > 1 sonst 0, „Min“: Min(Werte) wenn Werte sonst 0, „Max“: Max(Werte) wenn Werte sonst 0 } # Identifizieren Sie Anomalien mithilfe des Z-Scores Anomalien = [] für metric_name, stats in metrics_by_service.items(): if stats[“stdev”] > 0: # Division durch Null vermeiden z_score = (stats[“max”] – stats[“mean”]) / stats[“stdev”] if z_score > 2: # Mehr als 2 Standardabweichungen anomalies.append({ “metric”: metric_name, “z_score”: z_score, “severity”: “high” if z_score > 3 else “medium” }) return { “summary”: ai_summary, “anomalies”: anomalies, “impacted_services”: list(services), “recommendation”: ai_recommendation }

Code 3. Vorfallanalyse, Anomalieerkennung und Inferenzmethode

Die Integration von MCP in Observability-Plattformen könnte die Verwaltung und das Verständnis komplexer Telemetriedaten verbessern. Zu den potenziellen Vorteilen gehören:

• Schnellere Anomalieerkennung, was zu einer kürzeren Mindesterkennungszeit (MTTD) und Mindestlösungszeit (MTTR) führt.
• Einfachere Identifizierung der Grundursachen von Problemen.
• Weniger Lärm und weniger nicht umsetzbare Warnungen, wodurch die Warnungsmüdigkeit reduziert und die Produktivität der Entwickler verbessert wird.
• Weniger Unterbrechungen und Kontextwechsel bei der Lösung von Vorfällen, was zu einer verbesserten Betriebseffizienz für ein Engineering-Team führt.

Hier sind einige wichtige Erkenntnisse aus diesem Projekt, die Teams bei ihrer Observability-Strategie helfen werden.

• Kontextbezogene Metadaten sollten frühzeitig in den Telemetrie-Generierungsprozess eingebettet werden, um die nachgelagerte Korrelation zu erleichtern.
• Strukturierte Datenschnittstellen Erstellen Sie API-gesteuerte, strukturierte Abfrageebenen, um den Zugriff auf Telemetriedaten zu verbessern.
• Kontextbewusste KI konzentriert die Analyse auf kontextreiche Daten, um Genauigkeit und Relevanz zu verbessern.
• Kontextanreicherung und KI-Methoden sollten regelmäßig anhand von praktischem Betriebsfeedback weiterentwickelt werden.

Die Kombination strukturierter Datenpipelines und KI verspricht enorme Vorteile für die Beobachtbarkeit. Durch den Einsatz strukturierter Protokolle wie MCP und KI-gesteuerter Analysen können wir umfangreiche Telemetriedaten in umsetzbare Erkenntnisse umwandeln und so proaktive statt reaktive Systeme schaffen. Lumigo identifiziert drei wesentliche Säulen der Beobachtbarkeit: Protokolle , Metriken und Traces . Ohne Integration sind Ingenieure gezwungen, unterschiedliche Datenquellen manuell zu korrelieren, was die Reaktion auf Vorfälle verlangsamt.

Die Art und Weise, wie wir Telemetriedaten generieren, erfordert strukturelle Änderungen sowie analytische Techniken, um Bedeutung zu extrahieren.

Pronnoy Goswami ist ein KI- und Datenwissenschaftler mit mehr als zehn Jahren Erfahrung auf diesem Gebiet.