Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Suggerimento
- Ridurre da 15–30 minuti di unione manuale dei dati su piattaforme a pochi minuti in una singola conversazione.
- Eliminare le incertezze correlando le metriche di infrastruttura, applicazione e business in un'unica indagine.
- Connettere qualsiasi piattaforma osservabile con un server MCP allo stesso modo, senza alcuna integrazione personalizzata necessaria.
- Aggiungere nuove piattaforme senza modifiche al codice, perché l'agente individua automaticamente gli strumenti.
Il problema: dati di osservabilità sparsi tra piattaforme
Le applicazioni vengono eseguite in Azure, ma lo stack di osservabilità si estende su più piattaforme, tra cui Dynatrace per le tracce, Monitoraggio di Azure per l'infrastruttura, Splunk per i log, Kusto per le metriche aziendali. Durante un incidente, è possibile connettere manualmente questi silo: copiando gli ID operazione tra schede, correlando i timestamp tra linguaggi di query (DQL, KQL, SPL) e impiegando 15-30 minuti a unire i dati prima di iniziare l'attività di diagnostica.
Come l'agente risolve questo problema
Usando MCP (Model Context Protocol) è possibile connettere gli strumenti di osservabilità. L'agente esegue query su tutti questi strumenti (sia Azure che esterni) durante ogni indagine.
- Esegue query sui servizi di Azure , tra cui Application Insights, Log Analytics, Monitoraggio di Azure, Resource Graph (predefinita, nessuna configurazione necessaria).
- Esegue query sugli strumenti esterni, inclusi i log Dynatrace tramite DQL, metriche Datadog, eventi Splunk (tramite connettori MCP).
- Correla i segnali tra le piattaforme che collegano i picchi di errore in Dynatrace con la cronologia di distribuzione in Azure, corrisponde automaticamente ai timestamp.
- Segnala un quadro unificato, incluso il thread di indagine con prove da ogni sistema connesso.
Meccanismo chiave: l'agente registra gli strumenti da ogni server MCP connesso insieme agli strumenti predefiniti di Azure. Durante un'indagine, seleziona gli strumenti appropriati in base a ciò che sta analizzando, non in base alla piattaforma da cui provengono. Per altre informazioni, vedere Selezione degli strumenti.
Cosa rende questo approccio diverso
L'agente esegue query su tutte le piattaforme osservabili in un'unica indagine, correla automaticamente i segnali e si adatta quando le piattaforme aggiungono nuove funzionalità.
A differenza dei dashboard separati, l'agente esegue query su tutte le piattaforme di osservabilità in un'unica indagine. Non si passa tra le schede né si traduce tra i linguaggi di query. Il tuo agente gestisce DQL per Dynatrace, KQL per Azure e qualsiasi altro strumento che i tuoi strumenti rendano disponibile.
A differenza della correlazione manuale, l'agente connette automaticamente i segnali tra le piattaforme. Quando Dynatrace mostra un picco di errori 5xx e Azure mostra un'implementazione recente di app container, l'agente correla tali risultati in un'unica analisi della causa principale.
A differenza delle integrazioni da punto a punto, MCP è un protocollo aperto. Servizi come Dynatrace, Datadog, New Relic e Splunk pubblicano ciascuno un server MCP a cui l'agente si connette nello stesso modo. Quando una piattaforma aggiunge nuove funzionalità al server MCP, l'agente li individua automaticamente.
Informazioni sul funzionamento dei connettori MCP , sul modo in cui gli agenti personalizzati sono specializzati per piattaforma e su come la knowledge base fornisce contesto per i dati di telemetria personalizzati.
Prima e dopo
La tabella seguente confronta i flussi di lavoro di indagine degli eventi imprevisti con e senza l'integrazione dell'osservabilità esterna.
| Scenario | Prima | Dopo |
|---|---|---|
| Flusso di lavoro di indagine | Aprire Monitoraggio di Azure, Dynatrace e Splunk separatamente. È necessario eseguire una query manualmente su ognuno di essi. | Chiedere all'agente una sola volta mentre esegue query su tutte le piattaforme connesse |
| Correlazione dei segnali | Copiare gli ID errore tra strumenti e confrontare manualmente i timestamp tra piattaforme | L'agente segue il thread tra piattaforme e correla automaticamente |
| Cambio di contesto | Da tre a cinque dashboard, linguaggi di query diversi (KQL, DQL, SPL) | Una conversazione. L'agente gestisce le richieste. |
| Tempo alla prima intuizione | 15-30 minuti di unione dei dati tra gli strumenti | Minuti. L'agente esegue query in parallelo |
| Punti ciechi | Ogni strumento ha la propria sezione di metriche di infrastruttura, applicative e aziendali. | L'agente vede l'intera immagine in tutti i sistemi connessi |
Esempio di indagine: correlazione multipiattaforma
L'esempio seguente mostra come l'agente analizza le diverse piattaforme quando le metriche di Azure da sole non raccontano la storia completa.
Sintomo: "Gli ordini hanno esito negativo, ma le metriche di Azure hanno un aspetto positivo".
L'agente esamina le diverse piattaforme:
Controlla l'infrastruttura di Azure (strumenti predefiniti)
- Servizio app: integro, basso utilizzo della CPU
- Azure SQL: sano, DTU basso
- Application Insights: nessuna eccezione nel livello dell'app
Query Dynatrace (tramite MCP)
- Interrogazioni sugli errori 5xx tra i servizi utilizzando gli strumenti DQL di Dynatrace
- Latenza del servizio di pagamento p99: 12 secondi (normale: 200 ms)
- Volume degli errori isolato all'ultima revisione della distribuzione
Esegue query nel cluster Kusto (tramite Kusto)
OrderEvents | where Status == "Failed" | summarize count() by FailureReason- Risultato: 847 errori con "PaymentGatewayTimeout"
Correla i risultati: "L'infrastruttura di Azure è in buona salute. Il picco di errore 5xx visibile in Dynatrace è correlato alla distribuzione della revisione 0000039. Gli 847 errori di PaymentGatewayTimeout nei dati degli ordini Kusto confermano l'impatto. Causa radice: distribuzione non valida."
Senza osservabilità esterna: L'indagine si arresta al passaggio 1: "Azure è integro, caso chiuso". Usando i connettori MCP, l'agente trova la causa radice effettiva in tre piattaforme.
Elementi che è possibile connettere
Nella tabella seguente sono elencate le origini dati supportate e le operazioni che l'agente può eseguire con ogni.
| L'origine dei dati | Connettore | Operazioni che l'agente può eseguire |
|---|---|---|
| Esplora dati di Azure (Kusto) | Connettore Kusto | Eseguire query sulle metriche aziendali e sui dati di telemetria personalizzati |
| Dynatrace | Server MCP | Esegui query su log e metriche tramite DQL e individua schemi di errori. |
| Datadog | Server MCP | Metriche di query, tracce, log e monitoraggi APM |
| Splunk | Server MCP | Registri di ricerca, esegui ricerche salvate, interroga eventi |
| New Relic | Server MCP | Eseguire query su metriche, tracce e dati sulle prestazioni dell'applicazione |
| Elasticsearch | Server MCP | Ricerca e interrogazione degli indici Elasticsearch |
| Qualsiasi strumento con MCP | Server MCP | Qualsiasi strumento esposto dal server MCP della piattaforma |
Inizia subito
La tabella seguente fornisce guide alla configurazione in base al tipo di strumento che si vuole connettere.
| Cosa vuoi connettere | Connettore | Guida all'installazione |
|---|---|---|
| Dynatrace, Datadog, Splunk, strumenti personalizzati | Server MCP | Esercitazione sul connettore MCP |
| Esplora dati di Azure (Kusto) | Connettore Kusto | Esercitazione sul connettore Kusto |
| Query KQL riutilizzabili | Strumenti Kusto | Creare strumenti Kusto |
Quando usare ogni approccio
La tabella seguente consente di scegliere l'approccio corretto in base allo stack di osservabilità.
| Stack di osservabilità | Approccio consigliato |
|---|---|
| Tutti i dati di telemetria in Azure (App Insights, Log Analytics) | Azure Observability funziona fin dall'inizio |
| Azure + strumenti APM esterni (Dynatrace, Datadog, New Relic) | Connettori Azure Observability (predefiniti) + MCP per ogni piattaforma |
| Metriche aziendali personalizzate e di Azure in Kusto | Connettore per Azure Observability e Kusto |
| Multipiattaforma (Azure + Dynatrace + Splunk + Kusto) | Tutti. L'agente interroga tutti gli elementi in un'unica analisi. |