Connectors im Azure SRE-Agent

Ihr Agent verfügt über einen integrierten Zugriff auf Azure-Dienste. Er kann Azure Monitor, Application Insights, Log Analytics und Azure Resource Graph sofort abfragen. Connectors erweitern die Reichweite an externe Systeme: Ihre Kusto-Cluster, Quellcoderepositorys, Tools für die Zusammenarbeit und benutzerdefinierte APIs.

Hinweis

Connectors und Incident-Plattformen

Connectors gewähren Ihrem Agent Zugriff auf Daten und Aktionen, z. B. Abfragen von Protokollen, Senden von Benachrichtigungen und Lesen von Code. Vorfallplattformen sind ein separates Konzept: Sie steuern, wo Warnungen stammen und wie Ihr Agent automatisch darauf reagiert.

In diesem Artikel werden Verbindungen behandelt. Informationen zu Vorfallplattformen finden Sie unter Vorfallplattformen.

Was Ihr Agent ohne Connectors tun kann

Auch ohne konfigurierte Connectors verfügt Ihr Agent über integrierte Funktionen über die verwaltete Identität und Azure RBAC-Berechtigungen.

Integrierte Funktion	Was es bietet
Anwendungsanalysen	Abfrage von Anwendungstelemetrie, Ablaufverfolgungen und Ausnahmen
Log Analytics	Abfrageprotokollanalyse-Arbeitsbereiche
Azure Monitor-Metriken	Listen- und Abfragemetriken, Analysieren von Trends und Anomalien
Azure Resource Graph	Ermitteln und Abfragen sämtlicher Azure-Ressourcen über Abonnements hinweg
Azure Resource Manager / Azure CLI	Lesen und Ändern eines beliebigen Azure-Ressourcentyps
AKS-Diagnose	Ausführen von Kubectl-Befehlen, Diagnostizieren von Kubernetes-Problemen

Azure Resource Graph- und ARM-Vorgänge funktionieren mit jedem Azure-Ressourcentyp, einschließlich App-Dienste, Container-Apps, VMs, Netzwerk, Speicher und mehr. Wenn Ihre Protokolle und Metriken in Azure Monitor und Application Insights live gespeichert sind, kann Ihr Agent sofort mit der Untersuchung von Problemen beginnen, ohne dass die Einrichtung des Connectors erforderlich ist. Connectors werden nützlich, wenn Sie den Agent benötigen, um Systeme außerhalb von Azure zu erreichen.

Welche Funktionen bieten Connectors?

Connectors werden in vier Kategorien unterteilt, basierend auf dem, was sie Ihrem Agent geben.

Datenquellen

Abfrageprotokolle, Metriken und Telemetrie, die außerhalb von Azure Monitor gespeichert sind.

Konnektor	Was es bietet
Datenbankabfrage (Azure Data Explorer)	Ausführen vordefinierter KQL-Abfragen für Ihre Kusto-Cluster
Datenbankindizierung (Azure Data Explorer)	Automatisches Erlernen Ihres Kusto-Schemas, damit der Agent Abfragen dynamisch generieren kann

Quellcode und Wissen

Geben Sie Ihrem Agent Kontext zu Ihren Systemen, einschließlich Code, Wikis und Dokumentation.

Konnektor	Was es bietet
GitHub MCP-Server	Zugriff auf Repositorys, Probleme, Pullanforderungen und Wiki-Seiten
GitHub OAuth	GitHub-Zugriff über den OAuth-Authentifizierungsfluss
Azure DevOps OAuth	Azure DevOps-Zugriff über OAuth-Authentifizierung
Dokumentation (Azure DevOps)	Indizieren und Durchsuchen Ihrer Azure DevOps-Wikis

Mithilfe dieser Connectors kann Ihr Agent Code nach Fehlermustern durchsuchen, Wiki-Dokumentation lesen, api-Dokumente während der Problembehandlung referenzieren und Vorfälle mit verwandten Pullanforderungen verbinden.

Tools für die Zusammenarbeit

Lassen Sie Ihren Agenten Ergebnisse über die Kanäle kommunizieren, die Ihr Team bereits verwendet.

Konnektor	Was es bietet
Benachrichtigung senden (Teams)	Veröffentlichen von Ergebnissen und Updates für Teams-Kanäle
Senden von E-Mails (Outlook)	Zusammenfassungen und Berichte zur E-Mail-Untersuchung

Benutzerdefinierte Connectors (MCP-Server)

Mithilfe von MCP (Model Context Protocol) können Sie Ihren Agent mit einem beliebigen System verbinden: lokale Datenbanken, cloudübergreifende Anwendungen, proprietäre APIs oder Plattformen von Drittanbietern wie Datadog, Splunk, Grafana oder Jira.

Durchsuchen Sie die verfügbaren Server im Azure MCP Center. Wenn Sie MCP-Tools zu Subagenten hinzufügen, können Sie alle Tools von einem Server gleichzeitig mithilfe eines Wildcard-Musters hinzufügen.

Überwachung der Integrität des MCP-Connectors

Gilt für: Version 26.1.25.0 und höher

Ihr Agent überwacht kontinuierlich den Status jeder MCP-Serververbindung. Jeder Connector im Portal zeigt eine Echtzeitstatusanzeige an, damit Sie auf einen Blick sehen können, ob Ihre externen Tools erreichbar sind.

Status	Bedeutung	Indicator
Verbunden	Server ist fehlerfrei, und Tools sind einsatzbereit	Grünes Häkchen
Getrennt	Vorübergehender Verbindungsverlust; Ihr Agent versucht die automatische Wiederherstellung	Roter Kreis
Fehler	Der Server kann nicht erreicht werden, oder ein nicht behebbarer Fehler ist aufgetreten. Überprüfen Der Konfiguration	Rotes Fehlersymbol
Initialisierung	Die Verbindung wird hergestellt.	Gelber Indikator
Nicht verfügbar	Es ist keine laufende Agentinstanz verfügbar; Status kann nicht bestimmt werden	Graues Fragezeichen

Wechseln Sie zu Builder-Connectors>, um alle Ihre Konnektoren mit ihrem aktuellen Status anzuzeigen.

Bei Connectors in einem Status "Fehlgeschlagen", " Fehler" oder " Nicht verfügbar " wird in der Statusspalte ein Link " Details anzeigen " angezeigt. Wählen Sie es aus, um Diagnoseinformationen einschließlich der Fehlermeldung, der Anzahl der geladenen Tools und des letzten Heartbeat-Zeitstempels anzuzeigen.

Automatische Wiederherstellung

Ihr Agent meldet nicht nur fehlerhafte Verbindungen. Es erholt sich nach Möglichkeit davon.

• Taktüberwachung: Ihr Agent pingt jeden MCP-Server alle 60 Sekunden, um zu überprüfen, ob er noch erreichbar ist.
• Vorübergehende Fehlerwiederherstellung: Wenn eine Verbindung aufgrund einer Netzwerkstörung abfällt, stellt das nächste erfolgreiche Herzschlag-Signal sie automatisch auf "Verbunden" zurück.
• Integritätsprüfung vor der Ausführung: Bevor Ihr Agent ein MCP-Tool verwendet, überprüft er die Verbindung und versucht erneut, eine Verbindung herzustellen, wenn der Server vorübergehend nicht erreichbar ist.

Tipp

Verbindungen bleiben durch Fehler bestehen

Wenn ein MCP-Server offline ist, bleibt der Connector in Ihrem Portal mit seinem Fehlerstatus sichtbar. Sie verschwindet nicht unbemerkt. Sie können genau sehen, was nicht geklappt hat, und die Konfiguration beheben, ohne den Connector erneut zu erstellen.

Wenn die automatische Wiederherstellung nicht helfen kann

In der folgenden Tabelle werden Szenarien beschrieben, in denen die automatische Wiederherstellung das Problem möglicherweise nicht beheben kann.

Situation	Was ist los	Was zu tun ist
Netzwerkblip	Ihr Agent wird beim nächsten Heartbeat automatisch wieder verbunden.	Nichts; Die Wiederherstellung erfolgt automatisch.
Server vorübergehend nicht verfügbar	Status zeigt "Getrennt" an und wird wiederhergestellt, wenn der Server wieder verfügbar ist.	Warten Sie, bis der Server wieder online ist
Falsche URL oder Anmeldeinformationen	Status: Fehlgeschlagen	Aktualisieren Sie die Verbindungskonfiguration mit den richtigen Werten
Der Server wurde endgültig entfernt.	Status: Fehlgeschlagen	Löschen und erneutes Erstellen des Connectors
Agent wird nicht ausgeführt	Status wird als nicht verfügbar angezeigt	Starten Sie den Agenten, um die Statusüberwachung wiederherzustellen

Wenn Ihr Agent versucht, ein Tool von einem getrennten MCP-Server zu verwenden, wird ein eindeutiger Fehler angezeigt, der erklärt, was falsch ist (z. B. "Verbindung ist getrennt und erneute Verbindung fehlgeschlagen."). Ihr Agent schlägt nicht still fehl oder erzeugt falsche Ergebnisse.

Wer Konnektoren konfigurieren kann

Für die Connectorverwaltung ist schreibberechtigung für den Agent erforderlich. Die folgende Tabelle zeigt, welche Rollen Connectors konfigurieren können.

Rolle	Können Anschlüsse konfiguriert werden?
SRE-Agent-Administrator	Ja
SRE-Agent Standardbenutzer	Nein (nur Ansicht)
SRE Agent Reader	Nein (nur Ansicht)

Während des Setups erfordern einige Connectors OAuth-Zustimmung von einem Benutzer, der über die entsprechenden Berechtigungen im externen System verfügt (z. B. ein GitHub-Organisationsmitglied für GitHub-Connectors oder ein Microsoft Entra-Administrator für Outlook/Teams). Diese Zustimmung betrifft Berechtigungen im externen Dienst, nicht SRE-Agent-Rollen.

Für Connectors, die die verwaltete Identität des Agents verwenden (z. B. Azure Data Explorer), muss ein Administrator des externen Systems die Identität zulassen.

Nach der Konfiguration profitieren alle Agentbenutzer automatisch von Connectors. Sie stellen einfach Fragen an den Agenten und verwenden die verfügbaren Connectors hinter den Kulissen.

Verbinder und Subagenten

Sie können spezielle MCP-Tools speziellen Subagenten zuweisen. Ein Unteragent zur Problembehandlung bei datenbanken kann Kusto-Tools erhalten, während ein Bereitstellungsunteragent GitHub-Zugriff erhält. Dieser Ansatz hält jeden Subagenten konzentriert und verhindert, dass er mit zu vielen Tools überwältigt wird.

Hinzufügen von MCP-Tools einzeln

Wechseln Sie im Portal zum Generator-Subagent-Generator>, erstellen oder bearbeiten Sie einen Unteragent, und wählen Sie unter "Erweiterte Einstellungen" die Option "Tools auswählen" aus. Die Toolauswahl zeigt Tools an, die nach MCP-Verbindung gruppiert sind. Wählen Sie diejenigen aus, die Ihr Subagent benötigt.

Listen Sie in YAML jedes Tool anhand des vollständigen Namens auf:

mcp_tools:
  - kusto-mcp_kusto_query
  - kusto-mcp_kusto_table_list
  - kusto-mcp_kusto_table_schema

Hinzufügen aller Tools von einem MCP-Server (Wildcard)

Gilt für: Version 26.2.9.0 und höher

Wenn ein MCP-Server viele Tools verfügbar macht und ihr Subagent alle benötigt, verwenden Sie das Wildcardmuster, anstatt jedes Tool einzeln aufzulisten:

mcp_tools:
  - kusto-mcp/*

Das {connection-id}/* Muster fügt jedes Tool aus dieser MCP-Verbindung hinzu. Ihr Agent erweitert den Wildcard beim Start. Beispielsweise wird kusto-mcp/* zu allen Tools aufgelöst, die unter der kusto-mcp Verbindung registriert sind.

Sie können Wildcards mit einzelnen Toolnamen kombinieren:

mcp_tools:
  - kusto-mcp/*            # All tools from the Kusto connection
  - grafana-mcp_dashboard  # One specific tool from Grafana

Hinweis

Syntax für Wildcards

Das Muster muss {connection-id}/* mit dem Schrägstrich verwenden. Muster wie kusto-mcp* (ohne Schrägstrich) werden als genaue Toolnamen und nicht als Wildcards behandelt.

In der folgenden Tabelle werden die Auswahl einzelner Tools und der Wildcard-Ansatz verglichen.

Vorgehensweise	Wann verwenden
Einzelne Tools	Sie möchten genau steuern, auf welche Tools ein Subagent zugreifen kann.
Wildcard (connection-id/*)	Sie vertrauen dem MCP-Server und möchten alle Tools nutzen, einschließlich solcher, die später hinzugefügt werden.
Gemischt	Sie möchten alle Tools von einem Server sowie bestimmte Tools von einem anderen

Warum wird der Wildcard verwendet? Wenn ein MCP-Server neue Tools hinzufügt, nimmt der Wildcard diese automatisch auf, ohne den Subagent neu zu konfigurieren. Individuelle Werkzeugauswahl bietet Ihnen präzise Kontrolle. Der Wildcard bietet Ihnen eine automatische Deckung.

Wenn MCP-Tools noch nicht bereit sind

Wenn ein MCP-Server nicht bereit ist, wenn Ihr Agent gestartet wird, kann der Agent nicht auf Tools von diesem Server zugreifen. Ihr Agent behandelt diese Bedingung ordnungsgemäß. Der Agent verzögert Subagenten mit nicht aufgelösten Wildcards oder fehlenden Tools und lädt sie automatisch, nachdem der Agent die MCP-Verbindung hergestellt hat. Sie müssen keine manuellen Maßnahmen ergreifen.

Weitere Informationen finden Sie unter Subagenten.

Nächster Schritt

Einrichten eines MCP-Connectors

Verwandte Inhalte

• Vorfallplattformen: Erfahren Sie, wie Ihr Agent Vorfälle automatisch empfängt und reagiert.
• Verbinden des Quellcodes: Einrichten von GitHub- oder Azure DevOps-Connectors.
• Subagenten: Erstellen Sie spezialisierte Agenten mit fokussiertem Konnektorzugriff.
• Berechtigungen: Konfigurieren des Azure-Ressourcenzugriffs für Ihren Agent.