Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Tipp
- Reduzieren Sie 15 bis 30 Minuten manuelle Datenzusammenführung über Plattformen hinweg auf wenige Minuten in einem einzigen Gespräch.
- Beseitigen Sie Unsicherheiten, indem Sie Infrastruktur-, Anwendungs- und Geschäftsmetriken in einer Untersuchung korrelieren.
- Verbinden Sie jede Observability-Plattform auf die gleiche Weise mit einem MCP-Server, ohne dass benutzerdefinierte Integrationen erforderlich sind.
- Fügen Sie neue Plattformen ohne Codeänderungen hinzu, da Ihr Agent seine Tools automatisch erkennt.
Das Problem: Observability-Daten sind über mehrere Plattformen verstreut.
Ihre Anwendungen werden auf Azure ausgeführt, aber Ihr Observability-Stapel umfasst mehrere Plattformen, einschließlich Dynatrace für Ablaufverfolgungen, Azure Monitor für Infrastruktur, Splunk für Protokolle, Kusto für Geschäftsmetriken. Während eines Vorfalls überbrücken Sie diese Silos manuell, indem Sie Vorgangs-IDs zwischen Registerkarten kopieren und Zeitstempel über die Abfragesprachen (DQL, KQL, SPL) hinweg korrelieren. Sie verbringen 15 bis 30 Minuten damit, Daten zusammenzuführen, bevor Sie überhaupt mit der Diagnose beginnen.
Wie Ihr Agent dieses Problem löst
Mithilfe von MCP (Model Context Protocol) können Sie Ihre Observability-Tools verbinden. Ihr Agent fragt alle diese Tools (sowohl Azure als auch extern) während jeder Untersuchung ab.
- Fragt Azure-Dienste ab, einschließlich Application Insights, Log Analytics, Azure Monitor, Resource Graph (integriert, ohne Setup erforderlich).
- Abfragen Ihrer externen Tools einschließlich Dynatrace-Protokolle über DQL, Datadog-Metriken, Splunk-Ereignisse (über MCP-Konnektoren).
- Korreliert Signale auf allen Plattformen , die Fehlerspitzen in Dynatrace mit dem Bereitstellungsverlauf in Azure verbinden, gleicht Zeitstempel automatisch ab.
- Meldet ein einheitliches Bild , einschließlich des Untersuchungsthreads mit Nachweisen aus jedem verbundenen System.
Der wichtigste Mechanismus: Ihr Agent registriert Tools von jedem verbundenen MCP-Server zusammen mit seinen integrierten Azure-Tools. Während einer Untersuchung wählt es die richtigen Tools basierend auf dem, was es untersucht, und nicht basierend darauf, von welcher Plattform sie stammen. Weitere Informationen finden Sie unter Toolauswahl.
Was macht diesen Ansatz anders
Ihr Agent fragt alle Ihre Observability-Plattformen in einer Untersuchung ab, korreliert Signale automatisch und passt sich an, wenn Plattformen neue Funktionen hinzufügen.
Im Gegensatz zu separaten Dashboards fragt Ihr Agent alle Observability-Plattformen in einer Untersuchung ab. Sie wechseln nicht zwischen Registerkarten oder übersetzen zwischen Abfragesprachen. Ihr Agent verarbeitet DQL für Dynatrace, KQL für Azure und alles, was Ihre anderen Tools verfügbar machen.
Im Gegensatz zur manuellen Korrelation verbindet Ihr Agent Signale automatisch über Plattformen hinweg. Wenn Dynatrace eine Spitzenzahl von 5xx-Fehlern anzeigt und Azure eine aktuelle Container-App-Bereitstellung anzeigt, korreliert Ihr Agent diese Ergebnisse mit einer einzigen Ursachenanalyse.
Im Gegensatz zu Punktintegrationen ist MCP ein offenes Protokoll. Dienste wie Dynatrace, Datadog, New Relic und Splunk veröffentlichen jeweils einen MCP-Server, zu dem Ihr Agent auf die gleiche Weise eine Verbindung herstellt. Wenn eine Plattform dem MCP-Server neue Funktionen hinzufügt, erkennt Ihr Agent sie automatisch.
Erfahren Sie, wie MCP-Connectors funktionieren, wie sich benutzerdefinierte Agents auf die Plattform spezialisiert haben und wie Ihre Knowledge Base Kontext für benutzerdefinierte Telemetrie bereitstellt.
Vor und nachher
In der folgenden Tabelle werden Workflows zur Untersuchung von Vorfällen mit und ohne externe Observability-Integration verglichen.
| Szenario | Vorher | Nach |
|---|---|---|
| Untersuchungsworkflow | Öffnen Sie Azure Monitor, Dynatrace und Splunk separat. Sie müssen jeden manuell abfragen. | Fragen Sie Ihren Agent einmal, während er alle verbundenen Plattformen abfragt. |
| Signalkorrelation | Kopieren von Fehler-IDs zwischen Tools und Manuelles Abgleichen von Zeitstempeln auf allen Plattformen | Ihr Agent folgt dem Thread über Plattformen hinweg und korreliert automatisch. |
| Kontextwechsel | Drei bis fünf Dashboards, verschiedene Abfragesprachen (KQL, DQL, SPL) | Eine Unterhaltung. Ihr Agent verarbeitet die Abfragen. |
| Zeit für ersten Einblick | 15 bis 30 Minuten, um Daten über verschiedene Tools hinweg zusammenzuführen. | Minuten. Ihre Agentenabfragen laufen parallel |
| Blinde Flecken | Jedes Tool sieht einen eigenen Ausschnitt der Infrastruktur, der Anwendung und der Geschäftsmetriken. | Ihr Agent sieht das gesamte Bild über alle verbundenen Systeme hinweg. |
Untersuchungsbeispiel: Plattformübergreifende Korrelation
Das folgende Beispiel zeigt, wie Ihr Agent plattformübergreifend untersucht, wenn Azure-Metriken allein nicht die vollständige Geschichte erzählen.
Symptom: "Bestellungen schlagen fehl, aber die Azure-Metriken sehen gut aus."
Ihr Agent untersucht plattformübergreifend:
Überprüft die Azure-Infrastruktur (integrierte Tools)
- App-Dienst: fehlerfrei, niedrige CPU
- Azure SQL: stabil, niedrige DTU
- Application Insights: keine Ausnahmen in der App-Ebene
Abfragen Dynatrace (über MCP)
- Abfragen von 5xx-Fehlern über Dienste hinweg mithilfe von Dynatrace's DQL-Tools
- Zahlungsdienst p99 Latenz: 12 Sekunden (Normal: 200 ms)
- Fehlervolumen isoliert auf die letzte bereitgestellte Revision
Abfragen Ihres Kusto Clusters (über Kusto)
OrderEvents | where Status == "Failed" | summarize count() by FailureReason- Ergebnis: 847 Fehler mit "PaymentGatewayTimeout"
Korreliert Ergebnisse: "Azure-Infrastruktur ist gesund. Die in Dynatrace sichtbare 5xx-Fehlerspitze korreliert mit der Bereitstellung der Revision 0000039. Die 847 PaymentGatewayTimeout-Fehler in Ihren Kusto-Bestelldaten bestätigen die Auswirkungen. Ursache: schlechte Bereitstellung."
Ohne externe Observierbarkeit: Die Untersuchung wird bei Schritt 1 beendet – "Azure ist fehlerfrei, Fall geschlossen". Durch die Verwendung von MCP-Connectors findet Ihr Agent die tatsächliche Ursache auf drei Plattformen.
Was Sie verbinden können
In der folgenden Tabelle sind die unterstützten Datenquellen und was Ihr Agent damit machen kann, aufgeführt.
| Datenquelle | Konnektor | Was Ihr Agent tun kann |
|---|---|---|
| Azure Data Explorer (Kusto) | Kusto-Anschluss | Abfragen von Geschäftsmetriken und benutzerdefinierter Telemetrie |
| Dynatrace | MCP-Server | Abfrageprotokolle und Metriken über DQL, Identifizieren von Fehlermustern |
| Datadog | MCP-Server | Abfragemetriken, APM-Ablaufverfolgungen, Protokolle und Monitore |
| Splunk | MCP-Server | Suchprotokolle, Gespeicherte Suchen ausführen, Abfrageereignisse |
| New Relic | MCP-Server | Abfragemetriken, Ablaufverfolgungen und Anwendungsleistungsdaten |
| Elasticsearch | MCP-Server | Suchen und Abfragen von Elasticsearch-Indizes |
| Jedes Tool mit MCP | MCP-Server | Alle Tools, die der MCP-Server der Plattform zur Verfügung stellt |
Erste Schritte
Die folgende Tabelle enthält Setuphandbücher basierend auf dem Typ des Tools, das Sie verbinden möchten.
| Was Sie verbinden möchten | Konnektor | Setuphandbuch |
|---|---|---|
| Dynatrace, Datadog, Splunk, benutzerdefinierte Tools | MCP-Server | MCP-Connector-Lernprogramm |
| Azure Data Explorer (Kusto) | Kusto-Anschluss | Kusto Connector-Lernprogramm |
| Wiederverwendbare KQL-Abfragen | Kusto-Tools | Erstellen von Kusto-Tools |
Wann jeder Ansatz verwendet werden soll
In der folgenden Tabelle können Sie die richtige Vorgehensweise basierend auf Ihrem Observability-Technologie-Stack auswählen.
| Ihr Beobachtbarkeits-Stack | Empfohlener Ansatz |
|---|---|
| Alle Telemetriedaten in Azure (App Insights, Log Analytics) | Azure Observability funktioniert von Anfang an |
| Azure + externe APM (Dynatrace, Datadog, New Relic) | Azure Observability (eingebaute) + MCP-Konnektoren für jede Plattform |
| Azure + benutzerdefinierte Geschäftsmetriken in Kusto | Azure Observability + Kusto-Verbindung |
| Multiplattform (Azure + Dynatrace + Splunk + Kusto) | Alle. Ihr Agent fragt alles im Rahmen einer Untersuchung ab |