Connettori nell'agente SRE di Azure

L'agente include l'accesso predefinito ai servizi di Azure. Può eseguire query su Monitoraggio di Azure, Application Insights, Log Analytics e Azure Resource Graph. I connettori estendono tale portata ai sistemi esterni: i cluster Kusto, i repository di codice sorgente, gli strumenti di collaborazione e le API personalizzate.

Operazioni che l'agente può eseguire senza connettori

Anche senza connettori configurati, l'agente dispone di funzionalità predefinite tramite l'identità gestita e le autorizzazioni di controllo degli accessi in base al ruolo (RBAC) di Azure.

le operazioni Azure Resource Graph e ARM funzionano con qualsiasi tipo di risorsa Azure inclusi Servizi app, App contenitore, macchine virtuali, rete, archiviazione e altro ancora. Se i log e le metriche risiedono in Monitoraggio di Azure e Application Insights, l'agente può iniziare a analizzare immediatamente i problemi, senza che sia necessaria alcuna configurazione del connettore. I connettori diventano utili quando è necessario che l'agente raggiunga i sistemi outside Azure.

Cosa forniscono i connettori

I connettori rientrano in quattro categorie in base a ciò che forniscono all'agente:

Origini dati

Esegui query su log, metriche e telemetria dagli archivi di dati.

Codice sorgente e conoscenza

Fornire al proprio agente il contesto dei sistemi, ovvero codice, wiki e documentazione.

Con questi connettori, l'agente può cercare modelli di errore, leggere la documentazione wiki, la documentazione dell'API di riferimento durante la risoluzione dei problemi e connettere gli eventi imprevisti alle richieste pull correlate.

Strumenti di collaborazione

Consentire all'agente di comunicare i risultati tramite i canali già usati dal team.

Connettori personalizzati (server MCP)

MCP (Model Context Protocol) consente di connettere l'agente a qualsiasi sistema, tra cui piattaforme di osservabilità, repository di codice sorgente, sistemi di ticketing e API personalizzate. L'agente individua automaticamente gli strumenti dai server connessi, monitora l'integrità delle connessioni con heartbeat di 60 secondi e recupera automaticamente da errori temporanei.

Due tipi di trasporto coprono ogni modello di distribuzione: Streamable-HTTP per i servizi cloud remoti e stdio per i processi locali in esecuzione insieme all'agente. I connettori partner preconfigurati per GitHub, Datadog, Splunk, New Relic e altro ancora forniscono la configurazione con un clic.

Per una guida completa all'architettura MCP, ai tipi di trasporto, ai connettori partner, al monitoraggio dell'integrità e alla gestione degli strumenti, vedere Connettori MCP e strumenti.

Per configurare il primo connettore MCP, vedere Configurare il connettore MCP.

Esplorazione e gestione dei connettori

Apri la pagina Connettori (Builder Connettori>) per visualizzare i connettori organizzati in gruppi di categorie espandibili. Per impostazione predefinita, tutti i gruppi vengono espansi.

Ogni intestazione di categoria mostra il numero di connettori in tale gruppo. Quando si comprime una categoria, viene visualizzata una notifica rossa se un connettore in tale gruppo presenta un problema di connessione. È possibile individuare i problemi a colpo d'occhio senza espandere ogni sezione. Usare i controlli della barra degli strumenti per gestire la visualizzazione:

• Espandi tutto/Comprimi tutto per attivare o disattivare tutti i gruppi di categorie contemporaneamente.
• Filtro categoria per visualizzare solo i connettori in una categoria specifica.
• Cercare i connettori in base al nome (passa a un elenco semplice per la ricerca di parole chiave).

Vengono visualizzate solo le categorie che contengono almeno un connettore. Quando si cerca un connettore in base al nome, la pagina passa a una visualizzazione elenco flat per un filtro più rapido.

Chi può configurare i connettori

La gestione del connettore richiede l'autorizzazione di scrittura per l'agente. In pratica:

Durante l'installazione, alcuni connettori richiedono il consenso OAuth da un utente che dispone delle autorizzazioni appropriate nel sistema esterno(ad esempio, un membro dell'organizzazione GitHub per i connettori GitHub o un amministratore di AD Azure per Outlook/Teams). Questo consenso riguarda le autorizzazioni nel servizio esterno , non i ruoli dell'agente SRE.

Per i connettori che usano l'identità gestita dell'agente (ad esempio Esplora dati di Azure), un amministratore del sistema esterno deve consentire l'elenco dell'identità.

Quando si configurano i connettori, tutti gli utenti dell'agente ne traggono vantaggio automaticamente. Fanno semplicemente domande all'agente ed esso utilizza i connettori disponibili in background.

Connettori e agenti personalizzati

È possibile assegnare strumenti MCP specifici a agenti personalizzati specializzati. Un agente personalizzato per la risoluzione dei problemi del database potrebbe ottenere gli strumenti Kusto, mentre un agente personalizzato di distribuzione ottiene l'accesso a GitHub. Questo approccio mantiene incentrato ogni agente personalizzato e impedisce di sovraccaricarlo con troppi strumenti.

Assegna gli strumenti singolarmente nel selettore strumenti del portale o usa i modelli wildcard (connection-id/*) in YAML per aggiungere tutti gli strumenti da un server in una sola volta. Per informazioni dettagliate sull'assegnazione degli strumenti e sulla sintassi con caratteri jolly, vedere Connettori e strumenti MCP.

Nel portale passare a Generatore generatore>di agenti personalizzati, creare o modificare un agente personalizzato e selezionare Scegli strumenti in Impostazioni avanzate. Lo strumento di selezione visualizza gli strumenti raggruppati per connessione MCP. Selezionare gli strumenti necessari per l'agente personalizzato.

In YAML elencare ogni strumento in base al nome completo:

mcp_tools:
  - azure-data-explorer_kusto_query
  - azure-data-explorer_kusto_table_list
  - azure-data-explorer_kusto_table_schema

Aggiungere tutti gli strumenti da un server MCP (wildcard)

Si applica a: versione 26.2.9.0 e successive

Quando un server MCP espone molti strumenti e l'agente personalizzato richiede tutti questi strumenti, usare il modello wildcard anziché elencare singolarmente ogni strumento.

mcp_tools:
  - azure-data-explorer/*

Il {connection-id}/* modello aggiunge ogni strumento dalla connessione MCP. L'agente espande il carattere jolly all'avvio. Ad esempio, azure-data-explorer/* corrisponde a tutti gli strumenti registrati in una connessione chiamata azure-data-explorer (predefinito per il connettore Azure MCP con Kusto a partire dalla versione 26.4.16.0). Sostituire il nome assegnato al connettore.

È possibile combinare caratteri jolly con singoli nomi di strumenti:

mcp_tools:
  - azure-data-explorer/*  # All tools from the Kusto connection
  - grafana-mcp_dashboard  # One specific tool from Grafana

La tabella seguente confronta la selezione dei singoli strumenti e l'approccio generico.

Perché usare il carattere jolly? Quando un server MCP aggiunge nuovi strumenti, la wildcard li rileva automaticamente senza riconfigurare l'agente personalizzato. La selezione di singoli strumenti ti offre un controllo preciso. Il wildcard offre una protezione automatica.

Quando gli strumenti MCP non sono ancora pronti

Se un server MCP non è pronto all'avvio dell'agente, l'agente non può accedere a strumenti da tale server. L'agente gestisce questa condizione normalmente. Rinvia gli agenti personalizzati con caratteri jolly non risolti o strumenti mancanti e li carica automaticamente dopo che l'agente ha stabilito la connessione MCP. Non è necessario eseguire alcuna azione manuale.

Per altre informazioni, vedere Agenti personalizzati.

Passo successivo

Contenuti correlati