Questo articolo offre opzioni di supporto, supporto e feedback per OpenTelemetry in Application Insights di Monitoraggio di Azure per .NET, Java, Node.js e app Python.
Si tratta di un nuovo standard open source per l'osservabilità. Per altre informazioni, vedere OpenTelemetry.
Perché Monitoraggio di Azure Microsoft investe in OpenTelemetry?
Microsoft sta investendo in OpenTelemetry per i motivi seguenti:
Garantisce la sua operatività a prescindere dal vendor e fornisce API/SDK coerenti in tutti i linguaggi.
Riteniamo che nel tempo OpenTelemetry consentirà ai clienti di Monitoraggio di Azure di osservare le applicazioni scritte in altri linguaggi oltre ai linguaggi supportati.
Espande i tipi di dati che è possibile raccogliere tramite un set completo di librerie di strumentazione.
OpenTelemetry Software Development Kit (SDK) tende a essere più efficiente su larga scala rispetto ai predecessori, gli SDK di Application Insights.
OpenTelemetry si allinea alla strategia di Microsoft, che si prefigge di adottare l'open source.
Che cos'è la distribuzione OpenTelemetry di Monitoraggio di Azure?
Può essere considerata un wrapper sottile che aggrega tutti i componenti OpenTelemetry per un'esperienza di prima classe in Azure. In OpenTelemetry questo wrapper è detto anche distribuzione.
Perché dovrei usare la distribuzione di OpenTelemetry di Monitoraggio di Azure?
L'uso della distribuzione OpenTelemetry di Azure Monitor presenta diversi vantaggi rispetto a OpenTelemetry nativo della community:
Riduce il lavoro di abilitazione
È supportato da Microsoft
Include funzionalità specifiche di Azure, ad esempio:
Campionamento compatibile con gli SDK classici di Application Insights
Nello spirito di OpenTelemetry, abbiamo progettato la distribuzione in modo che sia aperta ed estendibile. Ad esempio, è possibile aggiungere:
Esportazione del protocollo OTLP (OpenTelemetry Protocol) e invio simultaneo a una seconda destinazione
Altre librerie di strumentazione non incluse nella distribuzione
Poiché la distribuzione fornisce una distribuzione OpenTelemetry, la distribuzione supporta qualsiasi elemento supportato da OpenTelemetry. Ad esempio, è possibile aggiungere altri processori di telemetria, utilità di esportazione o librerie di strumentazione, se OpenTelemetry li supporta.
Nota
La distribuzione imposta il campionatore su un campionatore personalizzato a frequenza fissa per Application Insights. È possibile passare a un campionatore diverso, ma ciò potrebbe disabilitare alcune delle funzionalità incluse della distribuzione.
Per altre informazioni sul campionatore supportato, vedere la sezione Abilitare il campionamento di Configurare OpenTelemetry di Monitoraggio di Azure.
Per i linguaggi privi di un utilità di esportazione OpenTelemetry autonoma supportata, la distribuzione OpenTelemetry di Monitoraggio di Azure è l'unico modo attualmente supportato per usare OpenTelemetry con Monitoraggio di Azure. Per i linguaggi con un utilità di esportazione OpenTelemetry autonoma supportata, è possibile usare la distribuzione OpenTelemetry di Monitoraggio di Azure o l'utilità di esportazione OpenTelemetry autonoma appropriata a seconda dello scenario di telemetria. Per altre informazioni, vedere Quando usare l'utilità di esportazione OpenTelemetry di Monitoraggio di Azure?.
Come è possibile testare la distribuzione OpenTelemetry di Monitoraggio di Azure?
L'adozione di OpenTelemetry ora consente di non dover effettuare la migrazione in un secondo momento.
Quando è consigliabile usare l'utilità di esportazione OpenTelemetry di Monitoraggio di Azure?
Per ASP.NET Core, Java, Node.js e Python, è consigliabile usare la distribuzione OpenTelemetry di Monitoraggio di Azure. Si tratta di una riga di codice con cui iniziare.
Per tutti gli altri scenari .NET, inclusi ASP.NET classico, app console, Windows Forms (WinForms) e così via, è consigliabile usare l'utilità di esportazione OpenTelemetry di Monitoraggio di Azure .NET: Azure.Monitor.OpenTelemetry.Exporter.
❌ Questa funzionalità non è disponibile o non è applicabile.
È possibile usare OpenTelemetry per i Web browser?
Sì, ma non è consigliabile e Azure non lo supporta. OpenTelemetry JavaScript è fortemente ottimizzato per Node.js. È invece consigliabile usare l'SDK JavaScript Application Insights.
Per quando è prevista la disponibilità dell'SDK OpenTelemetry per l'uso nei Web browser?
L'SDK Web OpenTelemetry non ha una timeline di disponibilità determinata. Probabilmente serviranno diversi anni perché un SDK browser sia una valida alternativa all'SDK JavaScript di Application Insights.
Oggi è possibile testare OpenTelemetry in un Web browser?
La sandbox Web OpenTelemetry è un fork progettato per consentire il funzionamento di OpenTelemetry in un browser. Non è ancora possibile inviare dati di telemetria ad Application Insights. L'SDK non definisce eventi client generali.
L'esecuzione di Application Insights insieme a agenti concorrenti come AppDynamics, DataDog e NewRelic è supportata?
Alcuni clienti usano l'agente di raccolta OpenTelemetry come alternativa agente, anche se al momento Microsoft non supporta ufficialmente un approccio basato su agente per il monitoraggio delle applicazioni. Nel frattempo, la community open source ha contribuito a un'utilità di esportazione di Monitoraggio di Azure dell'agente di raccolta OpenTelemetry che alcuni clienti usano per inviare dati ad Application Insights di Monitoraggio di Azure. Questo non è supportato da Microsoft.
Qual è la differenza tra OpenCensus e OpenTelemetry?
OpenCensus è il precursore di OpenTelemetry. Microsoft ha contribuito a riunire OpenTracing e OpenCensus per creare OpenTelemetry, un unico standard di osservabilità a livello globale. L'SDK Python attualmente consigliato per la produzione per Monitoraggio di Azure si basa su OpenCensus. Microsoft si impegna a rendere Monitoraggio di Azure basato su OpenTelemetry.
In Grafana, perché vedo Status: 500. Can't visualize trace events using the trace visualizer?
È possibile provare a visualizzare i log di testo non elaborati anziché le tracce OpenTelemetry.
In Application Insights la tabella 'Traces' archivia i log di testo non elaborati a scopo diagnostico. Consentono di identificare e correlare le tracce associate alle richieste degli utenti, ad altri eventi e ai report delle eccezioni. Tuttavia, la tabella 'Traces' non contribuisce direttamente alla visualizzazione delle transazioni end-to-end (grafico a cascata) negli strumenti di visualizzazione come Grafana.
Con l'adozione crescente delle procedure native del cloud, esiste un'evoluzione nella raccolta e nella terminologia dei dati di telemetria. OpenTelemetry è diventato uno standard per la raccolta e la strumentazione dei dati di telemetria. In questo contesto, il termine 'Traces' ha assunto un nuovo significato. Anziché ai log non elaborati, 'Traces' in OpenTelemetry fa riferimento a una forma più completa e strutturata di dati di telemetria che include intervalli, che rappresentano singole unità di lavoro. Questi intervalli sono fondamentali per la creazione di viste di transazioni dettagliate, consentendo un monitoraggio e una diagnostica migliori delle applicazioni native del cloud.
Passaggio 1: abilitare la registrazione diagnostica
L'utilità di esportazione del Monitoraggio di Azure utilizza EventSource per la registrazione interna. I log di esportazione sono disponibili per qualsiasi EventListener acconsentendo esplicitamente all'origine denominata OpenTelemetry-AzureMonitor-Exporter. Per conoscere i passaggi per la risoluzione dei problemi, vedere Risoluzione dei problemi OpenTelemetry su GitHub.
Passaggio 2: testare la connettività tra l'host dell'applicazione e il servizio di inserimento dati
Gli SDK (Software Development Kit) e gli agenti di Application Insights inviano dati di telemetria per essere inseriti come chiamate REST agli endpoint di inserimento. Per testare la connettività dal server Web o dal computer host dell'applicazione con gli endpoint del servizio di inserimento dati, usare i comandi cURL o le richieste REST non elaborate da PowerShell. Per altre informazioni, vedere Risolvere i problemi di dati di telemetria mancanti delle applicazioni in Application Insights per Monitoraggio di Azure.
Problemi noti
Gli elementi seguenti sono problemi noti per le utilità di esportazione OpenTelemetry di Monitoraggio di Azure:
Nome dell'operazione mancante nei dati di telemetria delle dipendenze. La mancanza del nome dell'operazione causa errori e influisce negativamente sull'esperienza della scheda prestazioni.
Modello dispositivo mancante nei dati di telemetria delle richieste e delle dipendenze. La mancanza del modello dispositivo influisce negativamente sull'analisi della coorte del dispositivo.
Passaggio 1: abilitare la registrazione diagnostica
L'utilità di esportazione del Monitoraggio di Azure utilizza EventSource per la registrazione interna. I log di esportazione sono disponibili per qualsiasi EventListener acconsentendo esplicitamente all'origine denominata OpenTelemetry-AzureMonitor-Exporter. Per conoscere i passaggi per la risoluzione dei problemi, vedere Risoluzione dei problemi OpenTelemetry su GitHub.
Passaggio 2: testare la connettività tra l'host dell'applicazione e il servizio di inserimento dati
Gli SDK e gli agenti di Application Insights inviano dati di telemetria per l'inserimento, ad esempio chiamate REST, agli endpoint di inserimento dati. Per testare la connettività dal server Web o dal computer host dell'applicazione con gli endpoint del servizio di inserimento dati, usare i comandi cURL o le richieste REST non elaborate da PowerShell. Per altre informazioni, vedere Risolvere i problemi di dati di telemetria mancanti delle applicazioni in Application Insights per Monitoraggio di Azure.
Problemi noti
Gli elementi seguenti sono problemi noti per le utilità di esportazione OpenTelemetry di Monitoraggio di Azure:
Nome dell'operazione mancante nei dati di telemetria delle dipendenze. La mancanza del nome dell'operazione causa errori e influisce negativamente sull'esperienza della scheda prestazioni.
Modello dispositivo mancante nei dati di telemetria delle richieste e delle dipendenze. La mancanza del modello dispositivo influisce negativamente sull'analisi della coorte del dispositivo.
Passaggio 1: abilitare la registrazione diagnostica
Passaggio 2: testare la connettività tra l'host dell'applicazione e il servizio di inserimento dati
Gli SDK e gli agenti di Application Insights inviano dati di telemetria per l'inserimento, ad esempio chiamate REST, agli endpoint di inserimento dati. Per testare la connettività dal server Web o dal computer host dell'applicazione con gli endpoint del servizio di inserimento dati, usare i comandi cURL o le richieste REST non elaborate da PowerShell. Per altre informazioni, vedere Risolvere i problemi di dati di telemetria mancanti delle applicazioni in Application Insights per Monitoraggio di Azure.
Problemi noti
Se si scarica la libreria client di Application Insights per l'installazione da un browser, talvolta il file JAR scaricato è danneggiato e ha dimensioni di circa la metà rispetto al file di origine. Se si verifica questo problema, scaricare il file JAR eseguendo il comando curl o wget, come illustrato nelle chiamate di comando dell'esempio seguente:
Le chiamate di comando dell'esempio si applicano ad Application Insights per Java versione 3.4.11. Per trovare il numero di versione e l'indirizzo URL della versione corrente di Application Insights per Java, vedere https://github.com/microsoft/ApplicationInsights-Java/releases.
I passaggi seguenti sono applicabili alle applicazioni native Spring Boot.
Passaggio 1: verificare la versione di OpenTelemetry
Durante l'avvio dell'applicazione potrebbe essere visualizzato il messaggio seguente:
WARN c.a.m.a.s.OpenTelemetryVersionCheckRunner - The OpenTelemetry version is not compatible with the spring-cloud-azure-starter-monitor dependency.
The OpenTelemetry version should be <version>
In questo caso, è necessario importare le distinte base di OpenTelemetry secondo le indicazioni della documentazione di OpenTelemetry nell'unità di avvio Spring Boot.
Passaggio 2: abilitare la diagnostica automatica
Se qualcosa non funziona come previsto, è possibile abilitare la diagnostica automatica a livello di DEBUG per ottenere informazioni dettagliate. A tale scopo, impostare il livello di diagnostica automatica su ERROR, WARN, INFO, DEBUG o TRACE usando la variabile di ambiente APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL.
Per abilitare la diagnostica automatica al livello DEBUG con un contenitore Docker in esecuzione, eseguire il comando seguente:
docker run -e APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL=DEBUG <image-name>
Nota
Sostituire <image-name> con il nome dell'immagine Docker di conseguenza.
Dichiarazione di non responsabilità sulle informazioni di terze parti
Microsoft non garantisce, implicitamente o altrimenti, le prestazioni o l'affidabilità di questi prodotti indipendenti di terze parti.
Passaggio 1: abilitare la registrazione diagnostica
L'utilità di esportazione di Monitoraggio di Azure si avvale del logger dell'API OpenTelemetry per i log interni. Per abilitare il logger, eseguire il frammento di codice riportato di seguuto:
Passaggio 2: testare la connettività tra l'host dell'applicazione e il servizio di inserimento dati
Gli SDK e gli agenti di Application Insights inviano dati di telemetria per l'inserimento, ad esempio chiamate REST, agli endpoint di inserimento dati. Per testare la connettività dal server Web o dal computer host dell'applicazione con gli endpoint del servizio di inserimento dati, usare i comandi cURL o le richieste REST non elaborate da PowerShell. Per altre informazioni, vedere Risolvere i problemi di dati di telemetria mancanti delle applicazioni in Application Insights per Monitoraggio di Azure.
Problemi noti
Gli elementi seguenti sono problemi noti per le utilità di esportazione OpenTelemetry di Monitoraggio di Azure:
Nome dell'operazione mancante nei dati di telemetria delle dipendenze. La mancanza del nome dell'operazione causa errori e influisce negativamente sull'esperienza della scheda prestazioni.
Modello dispositivo mancante nei dati di telemetria delle richieste e delle dipendenze. La mancanza del modello dispositivo influisce negativamente sull'analisi della coorte del dispositivo.
Nome del server di database mancante nel nome della dipendenza. Poiché il nome del server di database non è incluso, le utilità di esportazione OpenTelemetry aggregano erroneamente le tabelle con lo stesso nome in server diversi.
Abilita registrazione diagnostica
L'utilità di esportazione di Monitoraggio di Microsoft Azure usa la libreria di registrazione standard Python per la registrazione interna. All'API OpenTelemetry e ai log dell'utilità di esportazione di Monitoraggio di Azure viene assegnato un livello di gravità di WARNING o ERROR per attività irregolare. Il livello di gravità INFO indica attività regolari o con esito positivo.
Per impostazione predefinita, la libreria di registrazione Python imposta il livello di gravità su WARNING. Pertanto, è necessario modificare il livello di gravità per visualizzare i log con tale impostazione della gravità. Il codice di esempio seguente illustra come generare i log di tutti i livelli di gravità nella console e in un file:
Testare la connettività tra l'host dell'applicazione e il servizio di inserimento
Gli SDK e gli agenti di Application Insights inviano dati di telemetria per l'inserimento, ad esempio chiamate REST, agli endpoint di inserimento dati. Per testare la connettività dal server Web o dal computer host dell'applicazione con gli endpoint del servizio di inserimento dati, usare i comandi cURL o le richieste REST non elaborate da PowerShell. Per altre informazioni, vedere Risolvere i problemi di dati di telemetria mancanti delle applicazioni in Application Insights per Monitoraggio di Azure.
Evitare dati di telemetria duplicati
Spesso i dati di telemetria duplicati sono causati dalla creazione di più istanze di processori o utilità di esportazione. Assicurarsi di eseguire una sola utilità di esportazione e un solo processore alla volta per ciascun pilastro dei dati di telemetria (log, metriche e traccia distribuita).
Nelle sezioni seguenti sono illustrati gli scenari nei quali si possono generare dati di telemetria duplicati.
Log di traccia duplicati in Funzioni di Azure
Se viene visualizzata una coppia di voci per ciascun log di traccia in Application Insights, probabilmente sono stati abilitati i seguenti tipi di strumentazione di registrazione:
Strumentazione di registrazione nativa in Funzioni di Azure
Strumentazione di registrazione azure-monitor-opentelemetry nella distribuzione
Per evitare la generazione di dati duplicati, è possibile disabilitare la registrazione della distribuzione, lasciando abilitata la strumentazione di registrazione nativa in Funzioni di Azure. Per raggiungere questo obiettivo, impostare la OTEL_LOGS_EXPORTER variabile di ambiente su None.
Dati di telemetria duplicati in Funzioni di Azure "Always On"
Se l'impostazione Always On in Funzioni di Azure è impostata su On, Funzioni di Azure esegue alcuni processi in background al termine di ogni esecuzione. Si supponga, ad esempio, di avere una funzione timer di cinque minuti che chiama configure_azure_monitor ogni volta. Dopo 20 minuti, quattro utilità di esportazione delle metriche potrebbero essere eseguite contemporaneamente. Questa situazione potrebbe essere l'origine dei dati di telemetria delle metriche duplicati.
In una situazione simile, impostare Always On su Off oppure provare ad arrestare manualmente i provider tra ogni chiamata configure_azure_monitor. Per arrestare ciascun provider, eseguire le chiamate di arresto per ogni provider di contatore, traccia e logger correnti, come illustrato nel codice seguente:
Cartelle di lavoro di Azure e Jupyter Notebook potrebbero continuare a eseguire in background i processi dell'utilità di esportazione. Per evitare la generazione di dati di telemetria duplicati, cancellare la cache prima di effettuare altre chiamate a configure_azure_monitor.
Telemetria delle richieste mancanti da app FastAPI o Flask
Se mancano i dati della tabella Requests ma non altre categorie, è probabile che il framework HTTP non venga instrumentato. Questo problema può verificarsi nelle app FastAPI e Flask usando la libreria client di distribuzione OpenTelemetry di Monitoraggio di Azure per Python se non si strutturano correttamente le import dichiarazioni. È possibile importare fastapi.FastAPI o flask.Flask rispettivamente prima di chiamare la configure_azure_monitor funzione per instrumentare le librerie FastAPI e Flask. Ad esempio, il codice seguente non instrumenta correttamente le app FastAPI e Flask:
# FastAPI
from azure.monitor.opentelemetry import configure_azure_monitor
from fastapi import FastAPI
configure_azure_monitor()
app = FastAPI()
# Flask
from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask
configure_azure_monitor()
app = Flask(__name__)
È invece consigliabile importare i fastapi moduli o flask nel suo complesso e quindi chiamare configure_azure_monitor per configurare OpenTelemetry per l'uso di Monitoraggio di Azure prima di accedere a fastapi.FastAPI o flask.Flask:
Informazioni sull'osservabilità e su come implementarla in un'applicazione nativa del cloud. Usare i pacchetti OpenTelemetry per restituire log, metriche e dati di traccia e analizzare i dati in Application Insights e nelle applicazioni di terze parti.
Gestire l'inserimento e la preparazione dei dati, il training e la distribuzione di modelli e il monitoraggio delle soluzioni di apprendimento automatico con Python, Azure Machine Learning e MLflow.