Nozioni di base sulla raccolta dati di Application Insights per Monitoraggio di Azure
Articolo
Prima di poter monitorare l'applicazione, è necessario strumentarla.
Nelle sezioni seguenti vengono illustrate alcune nozioni di base sulla raccolta dati di Application Insights di Monitoraggio di Azure.
Opzioni di strumentazione
A livello di base, la "strumentazione" consente semplicemente a un'applicazione di acquisire i dati di telemetria.
Esistono due metodi per strumentare l'applicazione:
Strumentazione automatica
Strumentazione manuale
La strumentazione automatica abilita la raccolta di dati di telemetria tramite la configurazione senza toccare il codice dell'applicazione. Anche se è più conveniente, tende a essere meno configurabile. Inoltre, non è disponibile in tutte le lingue. Vedere Ambienti e linguaggi supportati per la strumentazione automatica. Quando è disponibile l'installazione automatica, è il modo più semplice per abilitare Application Insights di Monitoraggio di Azure.
Suggerimento
Attualmente, l'autenticazione di Microsoft Entra non è disponibile con l'installazione automatica. Se è necessaria l'autenticazione di Microsoft Entra, è necessario usare la strumentazione manuale.
La strumentazione manuale sta codificando in base all'API Application Insights o OpenTelemetry. Nel contesto di un utente, si riferisce in genere all'installazione di un SDK specifico del linguaggio in un'applicazione. Ciò significa che è necessario gestire gli aggiornamenti alla versione più recente del pacchetto manualmente. È possibile usare questa opzione se è necessario effettuare chiamate di dipendenza personalizzate o chiamate API che non vengono acquisite per impostazione predefinita con l'installazione automatica. Sono disponibili due opzioni per la strumentazione manuale:
Anche se si vede OpenTelemetry come direzione futura, non è previsto di interrompere la raccolta dei dati dagli SDK meno recenti. È comunque possibile procedere prima che le distribuzioni di Azure OpenTelemetry raggiungano la parità delle funzionalità con gli SDK di Application Insights. In molti casi, i clienti continuano a scegliere di usare gli SDK di Application Insights per molto tempo.
Importante
"Manuale" non significa che sarà necessario scrivere codice complesso per definire intervalli per le tracce distribuite, anche se rimane un'opzione. Le librerie di strumentazione inserite nelle distribuzioni consentono di acquisire facilmente i segnali di telemetria in framework e librerie comuni. Microsoft sta lavorando attivamente per strumentare gli SDK dei servizi di Azure più diffusi usando OpenTelemetry, in modo che questi segnali siano disponibili per i clienti che usano la distribuzione OpenTelemetry di Monitoraggio di Azure.
Tipi di dati di telemetria
I dati di telemetria raccolti per osservare l'applicazione possono essere suddivisi in tre tipi o "pilastri":
Traccia distribuita
Metrica
Registri
Una storia di osservabilità completa include tutti e tre i pilastri e Application Insights suddivide ulteriormente questi pilastri in tabelle basate sul modello di dati. Gli SDK di Application Insights o le distribuzioni OpenTelemetry di Monitoraggio di Azure includono tutto ciò che è necessario per Application Performance Monitoring in Azure. Il pacchetto stesso è gratuito per l'installazione e si paga solo per i dati inseriti in Monitoraggio di Azure.
Esistono due modi per inviare i dati a Monitoraggio di Azure (o a qualsiasi fornitore):
Tramite un utilità di esportazione diretta
Tramite un agente
Un utilità di esportazione diretta invia i dati di telemetria in-process (dal codice dell'applicazione) direttamente all'endpoint di inserimento di Monitoraggio di Azure. Il vantaggio principale di questo approccio è l'onboarding della semplicità.
Gli SDK di Application Insights attualmente disponibili e le distribuzioni OpenTelemetry di Monitoraggio di Azure si basano su un'utilità di esportazione diretta.
Se si prevede di usare OpenTelemetry-Collector per il campionamento o l'elaborazione dati aggiuntiva, è possibile ottenere queste stesse funzionalità predefinite in Monitoraggio di Azure. I clienti che hanno eseguito la migrazione ad Application Insights basati sull'area di lavoro possono trarre vantaggio dalle trasformazioni in fase di inserimento. Per abilitare, seguire i dettagli dell'esercitazione, ignorando il passaggio che illustra come configurare un'impostazione di diagnostica perché con Application Insights incentrato sull'area di lavoro è già configurata. Se si filtra meno del 50% del volume complessivo, non sono previsti costi aggiuntivi. Dopo il 50%, c'è un costo, ma molto meno del costo standard per GB.
OpenTelemetry
Microsoft è lieta di adottare OpenTelemetry come futuro della strumentazione dei dati di telemetria. I clienti hanno chiesto la strumentazione indipendente dal fornitore e siamo lieti di collaborare con la community OpenTelemetry per creare API e SDK coerenti in tutte le lingue.
Microsoft ha collaborato con gli stakeholder del progetto di due progetti di telemetria open source più diffusi, OpenCensus e OpenTracing. Insieme, abbiamo contribuito a creare un singolo progetto, OpenTelemetry. OpenTelemetry include contributi di tutti i principali fornitori di cloud e Application Performance Management (APM) e vive all'interno di Cloud Native Computing Foundation (CNCF). Microsoft è un membro Platinum del CNCF.
Per la terminologia, vedere il glossario nelle specifiche OpenTelemetry.
Alcuni termini legacy in Application Insights confondono a causa della convergenza del settore in OpenTelemetry. Nella tabella seguente vengono evidenziate queste differenze. I termini OpenTelemetry sostituiscono i termini di Application Insights.
Application Insights
OpenTelemetry
Agenti di raccolta automatici
Librerie di strumentazione
Channel
Esportatore
Senza codice/basato su agente
Strumentazione automatica
Tracce
Registri
Richieste
Intervalli di server
Dipendenze
Altri tipi di intervalli (client, interno e così via)
Passaggio 1: abilitare la registrazione diagnostica
L'utilità di esportazione del Monitoraggio di Azure utilizza EventSource per la registrazione interna. I log dell'utilità di esportazione sono disponibili per qualsiasi EventListener mediante il consenso esplicito 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
L'utilità di esportazione del Monitoraggio di Azure utilizza EventSource per la registrazione interna. I log dell'utilità di esportazione sono disponibili per qualsiasi EventListener mediante il consenso esplicito 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
I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti
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.
Passaggio 1: abilitare la 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:
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.
Passaggio 3: 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. A tale scopo, impostare la variabile di ambiente OTEL_LOGS_EXPORTER 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.
Passaggio 4: assicurarsi che i dati della richiesta Flask vengano raccolti
Se si implementa un'applicazione Flask, la raccolta dei dati della tabella Richieste da Application Insights potrebbe non riuscire durante l'uso della libreria client di distribuzione OpenTelemetry di Monitoraggio di Azure per Python. Questo problema si può verificare se le dichiarazioni import non sono strutturate correttamente. Si potrebbe importare il framework dell'applicazione Web flask.Flask prima di chiamare la funzione configure_azure_monitor per strumentare la libreria Flask. Ad esempio, il codice seguente non è in grado di strumentare correttamente l'app Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask
configure_azure_monitor()
app = Flask(__name__)
È invece consigliabile importare il modulo flask per intero ed effettuare una chiamata a configure_azure_monitor per configurare OpenTelemetry per l'utilizzo di Monitoraggio di Azure prima di accedere a flask.Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
import flask
configure_azure_monitor()
app = flask.Flask(__name__)
In alternativa, è possibile chiamare configure_azure_monitor prima di importare flask.Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
from flask import Flask
app = Flask(__name__)
Supporto tecnico
Selezionare la scheda del linguaggio scelto per scoprire le opzioni di supporto.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.