Guida, supporto e feedback di OpenTelemetry

Articolo
10/26/2024

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.

Esaminare le domande frequenti
Eseguire i passaggi per la risoluzione dei problemi
Ottenere supporto
Fornire commenti e suggerimenti

Domande frequenti

Che cos'è OpenTelemetry?

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.

Qual è lo stato di OpenTelemetry?

Vedere Stato di OpenTelemetry.

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
- Autenticazione Microsoft Entra
- Archiviazione offline e tentativi automatici
- Statistiche
- Metriche standard di Application Insights
- Rilevare i metadati delle risorse per il popolamento automatico del nome del ruolo cloud e dell'istanza del ruolo cloud in vari ambienti di Azure
- Metriche attive

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?

Consultare la documentazione di abilitazione per .NET, Java, JavaScript (Node.js) e Python.

È consigliabile usare OpenTelemetry o l'SDK Application Insights?

È consigliabile usare la distribuzione OpenTelemetry, a meno che non sia necessaria una funzionalità disponibile solo con il supporto formale nell'SDK Application Insights.

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.

Per scenari di telemetria Python più complessi che richiedono una configurazione avanzata, è consigliabile usare l'utilità di esportazione OpenTelemetry di Monitoraggio di Azure Python.

Qual è lo stato di rilascio corrente delle funzionalità della distribuzione OpenTelemetry di Monitoraggio di Azure?

Nel grafico seguente viene visualizzato il supporto delle funzionalità OpenTelemetry per ogni linguaggio.

Funzionalità	.NET	Node.js	Python	Java
Traccia distribuita	✅	✅	✅	✅
Metriche personalizzate	✅	✅	✅	✅
Metriche standard	✅	✅	✅	✅
Campionamento a frequenza fissa	✅	✅	✅	✅
Archiviazione offline e retry automatici	✅	✅	✅	✅
Segnalazione eccezioni	✅	✅	✅	✅
Raccolta di log	✅	⚠️	✅	✅
Eventi personalizzati	⚠️	⚠️	⚠️	✅
Autenticazione Microsoft Entra	✅	✅	✅	✅
Metriche attive	✅	✅	✅	✅
Filtro delle metriche attive	✅	❌	❌	❌
Rilevare il contesto delle risorse per macchine virtuali/set di scalabilità di macchine virtuali e servizio app	✅	❌	✅	✅
Rilevare il contesto delle risorse per servizio Azure Kubernetes e Funzioni	❌	❌	❌	✅
Eventi di test della disponibilità generati tramite l'API Traccia disponibilità	❌	❌	❌	✅
Filtrare le richieste, le dipendenze, i log e le eccezioni in base all'ID utente anonimo e all'origine sintetica	❌	❌	❌	✅
Filtrare dipendenze, log ed eccezioni in base al nome dell'operazione	❌	❌	❌	✅
Campionamento adattivo	❌	❌	❌	✅
Profiler	❌	❌	❌	⚠️
Debugger di snapshot	❌	❌	❌	❌

Chiave

✅ Questa funzionalità è disponibile per tutti i clienti con supporto formale.
⚠ Questa funzionalità è disponibile come anteprima pubblica. Vedere Condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure.
❌ 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?

Non sono previsti il supporto e il test di questa pratica, anche se le distribuzioni consentono di esportare simultaneamente verso un endpoint OTLP e Monitoraggio di Azure.

È possibile usare funzionalità di anteprima negli ambienti di produzione?

Non è una scelta consigliata. Vedere Condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure.

Qual è la differenza tra strumentazione manuale e automatica?

Vedere la panoramica di OpenTelemetry.

Che cos'è l'agente di raccolta OpenTelemetry?

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.

Risoluzione dei problemi

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

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

Per impostazione predefinita, la registrazione diagnostica è abilitata in Application Insights di Monitoraggio di Azure. Per altre informazioni, vedere Guida alla risoluzione dei problemi: Application Insights di Monitoraggio di Azure per Java.

Passaggio 2: testare la connettività tra l'host dell'applicazione e il servizio di inserimento dati

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:
```
curl --location --output applicationinsights-agent-3.6.2.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download//applicationinsights-agent-3.6.2.jar
```
```
wget --output-document=applicationinsights-agent-3.6.2.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download//applicationinsights-agent-3.6.2.jar
```
Nota

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:

const { diag, DiagConsoleLogger, DiagLogLevel } = require("@opentelemetry/api");
const { NodeTracerProvider } = require("@opentelemetry/sdk-trace-node");

const provider = new NodeTracerProvider();
diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.ALL);
provider.register();

Passaggio 2: testare la connettività tra l'host dell'applicazione e il servizio di inserimento dati

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:

...
import logging

logging.basicConfig(format = "%(asctime)s:%(levelname)s:%(message)s", level = logging.DEBUG)

logger = logging.getLogger(__name__)
file = logging.FileHandler("example.log")
stream = logging.StreamHandler()
logger.addHandler(file)
logger.addHandler(stream)
...

Testare la connettività tra l'host dell'applicazione e il servizio di inserimento

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:

get_meter_provider().shutdown()
get_tracer_provider().shutdown()
get_logger_provider().shutdown()

Cartelle di lavoro di Azure e Jupyter Notebook

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:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor
import fastapi

configure_azure_monitor()

app = fastapi.FastAPI(__name__)

# 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 fastapi.FastAPI o flask.Flask:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor

configure_azure_monitor()

from fastapi import FastAPI

app = FastAPI(__name__)

# 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.

Per i problemi relativi al supporto di Azure, aprire un ticket di supporto tecnico di Azure.
Per i problemi relativi a OpenTelemetry, contattare direttamente la community .NET di OpenTelemetry.
Per un elenco dei problemi aperti relativi all'utilità di esportazione di Monitoraggio di Azure, vedere la pagina Problemi di GitHub.

Commenti e suggerimenti su OpenTelemetry

Per inviare un feedback:

Compilare il questionario feedback clienti della community OpenTelemetry.
Raccontare di sé a Microsoft unendosi alla Community Early Adopter di OpenTelemetry.
Interagire con altri utenti di Monitoraggio di Azure nella Microsoft Tech Community.
Inviare una richiesta relativa alle funzionalità nel forum feedback di Azure.

Condividi tramite

Guida, supporto e feedback di OpenTelemetry

Domande frequenti

Che cos'è OpenTelemetry?

Perché Monitoraggio di Azure Microsoft investe in OpenTelemetry?

Qual è lo stato di OpenTelemetry?

Che cos'è la distribuzione OpenTelemetry di Monitoraggio di Azure?

Perché dovrei usare la distribuzione di OpenTelemetry di Monitoraggio di Azure?

Come è possibile testare la distribuzione OpenTelemetry di Monitoraggio di Azure?

È consigliabile usare OpenTelemetry o l'SDK Application Insights?

Quando è consigliabile usare l'utilità di esportazione OpenTelemetry di Monitoraggio di Azure?

Qual è lo stato di rilascio corrente delle funzionalità della distribuzione OpenTelemetry di Monitoraggio di Azure?

È possibile usare OpenTelemetry per i Web browser?

Per quando è prevista la disponibilità dell'SDK OpenTelemetry per l'uso nei Web browser?

Oggi è possibile testare OpenTelemetry in un Web browser?

L'esecuzione di Application Insights insieme a agenti concorrenti come AppDynamics, DataDog e NewRelic è supportata?

È possibile usare funzionalità di anteprima negli ambienti di produzione?

Qual è la differenza tra strumentazione manuale e automatica?

Che cos'è l'agente di raccolta OpenTelemetry?

Qual è la differenza tra OpenCensus e OpenTelemetry?

In Grafana, perché vedo Status: 500. Can't visualize trace events using the trace visualizer?

Risoluzione dei problemi

Passaggio 1: abilitare la registrazione diagnostica

Passaggio 2: testare la connettività tra l'host dell'applicazione e il servizio di inserimento dati

Problemi noti

Supporto tecnico

Commenti e suggerimenti su OpenTelemetry

Commenti e suggerimenti

Risorse aggiuntive

In Grafana, perché vedo `Status: 500. Can't visualize trace events using the trace visualizer`?