Aggiungere, modificare e filtrare OpenTelemetry

  • Articolo

Questo articolo fornisce indicazioni su come aggiungere, modificare e filtrare OpenTelemetry per le applicazioni usando Application Insights di Monitoraggio di Azure.

Per altre informazioni sui concetti relativi a OpenTelemetry, vedere panoramica di OpenTelemetry o Domande frequenti su OpenTelemetry.

Raccolta dati automatica

Le distribuzioni raccolgono automaticamente i dati raggruppando librerie di strumentazione OpenTelemetry.

Librerie di strumentazione incluse

Richieste

Dipendenze

Registrazione

  • ILogger

Per altre informazioni su ILogger, vedere Registrazione in C# e .NET ed esempi di codice.

Note

  • ¹: supporta la creazione automatica di report di eccezioni non gestite/non rilevate
  • ²: supporta le metriche OpenTelemetry
  • ²: per impostazione predefinita, la registrazione viene raccolta solo a livello di INFO o superiore. Per modificare questa impostazione, vedere le opzioni di configurazione.
  • ⁴: per impostazione predefinita, la registrazione viene raccolta solo quando la registrazione viene eseguita a livello di AVVISO o superiore.

Nota

Le distribuzioni OpenTelemetry di Monitoraggio di Azure includono mapping personalizzato e logica per generare automaticamente metriche standard di Application Insights.

Suggerimento

Tutte le metriche di OpenTelemetry, che siano raccolte automaticamente dalle librerie di strumentazione o raccolte manualmente dalla codifica personalizzata, sono attualmente considerate "metriche personalizzate" di Application Insights ai fini della fatturazione. Scopri di più.

Aggiungere una libreria di strumentazione della community

È possibile raccogliere più dati automaticamente quando si includono librerie di strumentazione dalla community OpenTelemetry.

Attenzione

Non supportiamo né garantiamo la qualità delle librerie di strumentazione della community. Per suggerire una distribuzione, pubblicare o votare in modo positivo nella community dei commenti e suggerimenti. Tenere presente che alcuni si basano sulle specifiche sperimentali opentelemetry e potrebbero introdurre modifiche di rilievo future.

Per aggiungere una libreria della community, usare i ConfigureOpenTelemetryMeterProvider metodi o ConfigureOpenTelemetryTracerProvider dopo aver aggiunto il pacchetto nuget per la libreria.

L'esempio seguente illustra come è possibile aggiungere strumentazione runtime per raccogliere metriche aggiuntive.

dotnet add package OpenTelemetry.Instrumentation.Runtime 

// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);

// Configure the OpenTelemetry meter provider to add runtime instrumentation.
builder.Services.ConfigureOpenTelemetryMeterProvider((sp, builder) => builder.AddRuntimeInstrumentation());

// Add the Azure Monitor telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();

// Build the ASP.NET Core web application.
var app = builder.Build();

// Start the ASP.NET Core web application.
app.Run();

Raccogliere dati di telemetria personalizzati

Questa sezione illustra come raccogliere dati di telemetria personalizzati dall'applicazione.

A seconda della lingua e del tipo di segnale, esistono diversi modi per raccogliere dati di telemetria personalizzati, tra cui:

  • OpenTelemetry API
  • Librerie di registrazione/metriche specifiche del linguaggio
  • API classica di Application Insights

La tabella seguente rappresenta i tipi di telemetria personalizzati attualmente supportati:

Lingua Eventi personalizzati Metriche personalizzate Dipendenze Eccezioni Visualizzazioni pagina Richieste Tracce
ASP.NET Core
   OpenTelemetry API Sì Sì Sì Sì
   ILoggerAPI Sì
   API classica di intelligenza artificiale
Java
   OpenTelemetry API Sì Sì Sì Sì
   Logback, Log4j, JUL Sì Sì
   Metriche di Micrometer Sì
   API classica di intelligenza artificiale Sì Sì Sì Sì Sì Sì Sì
Node.JS
   OpenTelemetry API Sì Sì Sì Sì
Python
   OpenTelemetry API Sì Sì Sì Sì
   Modulo di registrazione Python Sì
   Estensione eventi Sì Sì

Nota

Application Insights Java 3.x è in ascolto dei dati di telemetria inviati all'API classica di Application Insights. Analogamente, Application Insights Node.js 3.x raccoglie gli eventi creati con l'API classica di Application Insights. In questo modo, l'aggiornamento risulta più semplice e riempie un divario nel supporto dei dati di telemetria personalizzati fino a quando tutti i tipi di telemetria personalizzati non sono supportati tramite l'API OpenTelemetry.

Aggiungere le metriche personalizzate

In questo contesto, le metriche personalizzate si riferiscono alla strumentazione manuale del codice per raccogliere metriche aggiuntive oltre a quanto raccolto automaticamente dalle librerie di strumentazione OpenTelemetry.

L'API OpenTelemetry offre sei strumenti di metrica per coprire vari scenari di metrica ed è necessario scegliere il tipo di aggregazione corretto durante la visualizzazione delle metriche in Esplora metriche. Questo requisito è vero quando si usa l'API metrica OpenTelemetry per inviare metriche e quando si usa una libreria di strumentazione.

La tabella seguente illustra i tipi di aggregazione consigliati per ognuno di OpenTelemetry Metric Instruments.

OpenTelemetry Instrument Tipo di aggregazione di Monitoraggio di Azure
Contatore Sum
Contatore asincrono Sum
Istogramma Min, Max, Average, Sum e Count
Misuratore asincrono Media
UpDownCounter Sum
UpDownCounter asincrono Sum

Attenzione

I tipi di aggregazione oltre a quanto mostrato nella tabella in genere non sono significativi.

La specifica OpenTelemetry descrive gli strumenti e fornisce esempi di quando è possibile usare ognuno di essi.

Suggerimento

L'istogramma è il più versatile e più strettamente equivalente all'API getMetric classica di Application Insights. Monitoraggio di Azure attualmente rende flat lo strumento istogramma nei cinque tipi di aggregazione supportati e è in corso il supporto per i percentili. Anche se meno versatile, altri strumenti OpenTelemetry hanno un impatto minore sulle prestazioni dell'applicazione.

Esempio di istogramma

L'avvio dell'applicazione deve sottoscrivere un contatore in base al nome.

// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);

// Configure the OpenTelemetry meter provider to add a meter named "OTel.AzureMonitor.Demo".
builder.Services.ConfigureOpenTelemetryMeterProvider((sp, builder) => builder.AddMeter("OTel.AzureMonitor.Demo"));

// Add the Azure Monitor telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();

// Build the ASP.NET Core web application.
var app = builder.Build();

// Start the ASP.NET Core web application.
app.Run();

L'oggetto Meter deve essere inizializzato utilizzando lo stesso nome.

// Create a new meter named "OTel.AzureMonitor.Demo".
var meter = new Meter("OTel.AzureMonitor.Demo");

// Create a new histogram metric named "FruitSalePrice".
Histogram<long> myFruitSalePrice = meter.CreateHistogram<long>("FruitSalePrice");

// Create a new Random object.
var rand = new Random();

// Record a few random sale prices for apples and lemons, with different colors.
myFruitSalePrice.Record(rand.Next(1, 1000), new("name", "apple"), new("color", "red"));
myFruitSalePrice.Record(rand.Next(1, 1000), new("name", "lemon"), new("color", "yellow"));
myFruitSalePrice.Record(rand.Next(1, 1000), new("name", "lemon"), new("color", "yellow"));
myFruitSalePrice.Record(rand.Next(1, 1000), new("name", "apple"), new("color", "green"));
myFruitSalePrice.Record(rand.Next(1, 1000), new("name", "apple"), new("color", "red"));
myFruitSalePrice.Record(rand.Next(1, 1000), new("name", "lemon"), new("color", "yellow"));

Esempio di contatore

L'avvio dell'applicazione deve sottoscrivere un contatore in base al nome.

// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);

// Configure the OpenTelemetry meter provider to add a meter named "OTel.AzureMonitor.Demo".
builder.Services.ConfigureOpenTelemetryMeterProvider((sp, builder) => builder.AddMeter("OTel.AzureMonitor.Demo"));

// Add the Azure Monitor telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();

// Build the ASP.NET Core web application.
var app = builder.Build();

// Start the ASP.NET Core web application.
app.Run();

L'oggetto Meter deve essere inizializzato utilizzando lo stesso nome.

// Create a new meter named "OTel.AzureMonitor.Demo".
var meter = new Meter("OTel.AzureMonitor.Demo");

// Create a new counter metric named "MyFruitCounter".
Counter<long> myFruitCounter = meter.CreateCounter<long>("MyFruitCounter");

// Record the number of fruits sold, grouped by name and color.
myFruitCounter.Add(1, new("name", "apple"), new("color", "red"));
myFruitCounter.Add(2, new("name", "lemon"), new("color", "yellow"));
myFruitCounter.Add(1, new("name", "lemon"), new("color", "yellow"));
myFruitCounter.Add(2, new("name", "apple"), new("color", "green"));
myFruitCounter.Add(5, new("name", "apple"), new("color", "red"));
myFruitCounter.Add(4, new("name", "lemon"), new("color", "yellow"));

Esempio di misuratore

L'avvio dell'applicazione deve sottoscrivere un contatore in base al nome.

// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);

// Configure the OpenTelemetry meter provider to add a meter named "OTel.AzureMonitor.Demo".
builder.Services.ConfigureOpenTelemetryMeterProvider((sp, builder) => builder.AddMeter("OTel.AzureMonitor.Demo"));

// Add the Azure Monitor telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();

// Build the ASP.NET Core web application.
var app = builder.Build();

// Start the ASP.NET Core web application.
app.Run();

L'oggetto Meter deve essere inizializzato utilizzando lo stesso nome.

// Get the current process.
var process = Process.GetCurrentProcess();

// Create a new meter named "OTel.AzureMonitor.Demo".
var meter = new Meter("OTel.AzureMonitor.Demo");

// Create a new observable gauge metric named "Thread.State".
// This metric will track the state of each thread in the current process.
ObservableGauge<int> myObservableGauge = meter.CreateObservableGauge("Thread.State", () => GetThreadState(process));

private static IEnumerable<Measurement<int>> GetThreadState(Process process)
{
    // Iterate over all threads in the current process.
    foreach (ProcessThread thread in process.Threads)
    {
        // Create a measurement for each thread, including the thread state, process ID, and thread ID.
        yield return new((int)thread.ThreadState, new("ProcessId", process.Id), new("ThreadId", thread.Id));
    }
}

Aggiungere eccezioni personalizzate

Selezionare le librerie di strumentazione che segnalano automaticamente le eccezioni ad Application Insights. Tuttavia, potrebbe essere necessario segnalare manualmente le eccezioni oltre al report delle librerie di strumentazione. Ad esempio, le eccezioni rilevate dal codice non vengono in genere segnalate. È possibile segnalarli per attirare l'attenzione nelle esperienze pertinenti, tra cui la sezione errori e le viste delle transazioni end-to-end.

  • Per registrare un'eccezione usando un'attività: 
    // Start a new activity named "ExceptionExample".
using (var activity = activitySource.StartActivity("ExceptionExample"))
{
    // Try to execute some code.
    try
    {
        throw new Exception("Test exception");
    }
    // If an exception is thrown, catch it and set the activity status to "Error".
    catch (Exception ex)
    {
        activity?.SetStatus(ActivityStatusCode.Error);
        activity?.RecordException(ex);
    }
}
  • Per registrare un'eccezione usando ILogger: 
    // Create a logger using the logger factory. The logger category name is used to filter and route log messages.
var logger = loggerFactory.CreateLogger(logCategoryName);

// Try to execute some code.
try
{
    throw new Exception("Test Exception");
}
catch (Exception ex)
{
    // Log an error message with the exception. The log level is set to "Error" and the event ID is set to 0.
    // The log message includes a template and a parameter. The template will be replaced with the value of the parameter when the log message is written.
    logger.Log(
        logLevel: LogLevel.Error,
        eventId: 0,
        exception: ex,
        message: "Hello {name}.",
        args: new object[] { "World" });
}

Aggiungere intervalli personalizzati

È possibile aggiungere un intervallo personalizzato in due scenari. In primo luogo, quando è presente una richiesta di dipendenza non già raccolta da una libreria di strumentazione. In secondo luogo, quando si vuole modellare un processo dell'applicazione come intervallo nella visualizzazione delle transazioni end-to-end.

Nota

Le Activity classi e ActivitySource dello System.Diagnostics spazio dei nomi rappresentano rispettivamente i concetti di OpenTelemetry di Span e Tracer. È possibile creare ActivitySource direttamente usando il relativo costruttore anziché usando TracerProvider. Ogni ActivitySource classe deve essere connessa in modo esplicito a TracerProvider tramite AddSource(). Ciò è dovuto al fatto che parti dell'API di traccia OpenTelemetry vengono incorporate direttamente nel runtime .NET. Per altre informazioni, vedere Introduzione all'API di traccia .NET opentelemetry.

// Define an activity source named "ActivitySourceName". This activity source will be used to create activities for all requests to the application.
internal static readonly ActivitySource activitySource = new("ActivitySourceName");

// Create an ASP.NET Core application builder.
var builder = WebApplication.CreateBuilder(args);

// Configure the OpenTelemetry tracer provider to add a source named "ActivitySourceName". This will ensure that all activities created by the activity source are traced.
builder.Services.ConfigureOpenTelemetryTracerProvider((sp, builder) => builder.AddSource("ActivitySourceName"));

// Add the Azure Monitor telemetry service to the application. This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();

// Build the ASP.NET Core application.
var app = builder.Build();

// Map a GET request to the root path ("/") to the specified action.
app.MapGet("/", () =>
{
    // Start a new activity named "CustomActivity". This activity will be traced and the trace data will be sent to Azure Monitor.
    using (var activity = activitySource.StartActivity("CustomActivity"))
    {
        // your code here
    }

    // Return a response message.
    return $"Hello World!";
});

// Start the ASP.NET Core application.
app.Run();

StartActivity per impostazione predefinita è ActivityKind.Internal, ma è possibile specificare qualsiasi altro ActivityKindoggetto . ActivityKind.Client, ActivityKind.Producere ActivityKind.Internal vengono mappati ad Application Insights dependencies. ActivityKind.Server e ActivityKind.Consumer vengono mappati ad Application Insights requests.

Inviare dati di telemetria personalizzati usando l'API classica di Application Insights

È consigliabile usare le API OpenTelemetry quando possibile, ma potrebbero esserci alcuni scenari quando è necessario usare l'API classica di Application Insights.

evento

  1. Aggiungere Microsoft.ApplicationInsights all'applicazione.

  2. Creare un'istanza di TelemetryClient.

Nota

È importante creare una sola istanza di TelemetryClient per applicazione.

var telemetryConfiguration = new TelemetryConfiguration { ConnectionString = "" };
var telemetryClient = new TelemetryClient(telemetryConfiguration);
  1. Usare il client per inviare dati di telemetria personalizzati.
telemetryClient.TrackEvent("testEvent");

Modificare la telemetria

Questa sezione illustra come modificare i dati di telemetria.

Aggiungere attributi span

Questi attributi possono includere l'aggiunta di una proprietà personalizzata ai dati di telemetria. È anche possibile usare gli attributi per impostare campi facoltativi nello schema di Application Insights, ad esempio IP client.

Aggiungere una proprietà personalizzata a un oggetto Span

Tutti gli attributi aggiunti agli intervalli vengono esportati come proprietà personalizzate. Popolano il campo customDimensions nella tabella richieste, dipendenze, tracce o eccezioni.

Per aggiungere attributi span, usare uno dei due modi seguenti:

Suggerimento

Il vantaggio dell'uso delle opzioni fornite dalle librerie di strumentazione, quando sono disponibili, è che l'intero contesto è disponibile. Di conseguenza, gli utenti possono selezionare per aggiungere o filtrare altri attributi. Ad esempio, l'opzione enrich nella libreria di strumentazione HttpClient consente agli utenti di accedere a HttpRequestMessage e a HttpResponseMessage stesso. Possono selezionare qualsiasi elemento da esso e archiviarlo come attributo.

  1. Molte librerie di strumentazione offrono un'opzione di arricchimento. Per indicazioni, vedere i file leggimi delle singole librerie di strumentazione:

  2. Usare un processore personalizzato:

Suggerimento

Aggiungere il processore illustrato qui prima di aggiungere Monitoraggio di Azure.

// Create an ASP.NET Core application builder.
var builder = WebApplication.CreateBuilder(args);

// Configure the OpenTelemetry tracer provider to add a new processor named ActivityEnrichingProcessor.
builder.Services.ConfigureOpenTelemetryTracerProvider((sp, builder) => builder.AddProcessor(new ActivityEnrichingProcessor()));

// Add the Azure Monitor telemetry service to the application. This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();

// Build the ASP.NET Core application.
var app = builder.Build();

// Start the ASP.NET Core application.
app.Run();

Aggiungere ActivityEnrichingProcessor.cs al progetto con il codice seguente:

public class ActivityEnrichingProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        // The updated activity will be available to all processors which are called after this processor.
        activity.DisplayName = "Updated-" + activity.DisplayName;
        activity.SetTag("CustomDimension1", "Value1");
        activity.SetTag("CustomDimension2", "Value2");
    }
}

Impostare l'INDIRIZZO IP utente

È possibile popolare il campo client_IP per le richieste impostando un attributo sull'intervallo. Application Insights usa l'indirizzo IP per generare gli attributi di posizione utente e quindi lo rimuove per impostazione predefinita.

Usare l'esempio di aggiungi proprietà personalizzata, ma sostituire le righe di codice seguenti in ActivityEnrichingProcessor.cs:

// Add the client IP address to the activity as a tag.
// only applicable in case of activity.Kind == Server
activity.SetTag("client.address", "<IP Address>");

Impostare l'ID utente o l'ID utente autenticato

È possibile popolare il campo user_Id o user_AuthenticatedId per le richieste usando le indicazioni seguenti. L'ID utente è un identificatore utente anonimo. L'ID utente autenticato è un identificatore utente noto.

Importante

Prima di impostare l'ID utente autenticato, consultare le leggi sulla privacy applicabili.

Usare l'esempio aggiungi proprietà personalizzata.

// Add the user ID to the activity as a tag, but only if the activity is not null.
activity?.SetTag("enduser.id", "<User Id>");

Aggiungere attributi di log

OpenTelemetry usa . ILogger. È possibile allegare dimensioni personalizzate ai log usando un modello di messaggio.

Filtrare i dati di telemetria

È possibile usare i modi seguenti per filtrare i dati di telemetria prima di uscire dall'applicazione.

  1. Molte librerie di strumentazione offrono un'opzione di filtro. Per indicazioni, vedere i file leggimi delle singole librerie di strumentazione:

  2. Usare un processore personalizzato:

    Suggerimento

    Aggiungere il processore illustrato qui prima di aggiungere Monitoraggio di Azure.

    // Create an ASP.NET Core application builder.
var builder = WebApplication.CreateBuilder(args);

// Configure the OpenTelemetry tracer provider to add a new processor named ActivityFilteringProcessor.
builder.Services.ConfigureOpenTelemetryTracerProvider((sp, builder) => builder.AddProcessor(new ActivityFilteringProcessor()));
// Configure the OpenTelemetry tracer provider to add a new source named "ActivitySourceName".
builder.Services.ConfigureOpenTelemetryTracerProvider((sp, builder) => builder.AddSource("ActivitySourceName"));
// Add the Azure Monitor telemetry service to the application. This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();

// Build the ASP.NET Core application.
var app = builder.Build();

// Start the ASP.NET Core application.
app.Run();

    Aggiungere ActivityFilteringProcessor.cs al progetto con il codice seguente:

    public class ActivityFilteringProcessor : BaseProcessor<Activity>
{
    // The OnStart method is called when an activity is started. This is the ideal place to filter activities.
    public override void OnStart(Activity activity)
    {
        // prevents all exporters from exporting internal activities
        if (activity.Kind == ActivityKind.Internal)
        {
            activity.IsAllDataRequested = false;
        }
    }
}

  3. Se un'origine specifica non viene aggiunta in modo esplicito tramite AddSource("ActivitySourceName"), nessuna delle attività create tramite tale origine viene esportata.

Ottenere l'ID di traccia o l'ID intervallo

Potrebbe essere necessario ottenere l'ID di traccia o l'ID intervallo. Se sono stati inviati log a una destinazione diversa da Application Insights, è consigliabile aggiungere l'ID di traccia o l'ID intervallo. In questo modo è possibile migliorare la correlazione durante il debug e la diagnosi dei problemi.

Nota

Le Activity classi e ActivitySource dello System.Diagnostics spazio dei nomi rappresentano rispettivamente i concetti di OpenTelemetry di Span e Tracer. Ciò è dovuto al fatto che parti dell'API di traccia OpenTelemetry vengono incorporate direttamente nel runtime .NET. Per altre informazioni, vedere Introduzione all'API di traccia .NET opentelemetry.

// Get the current activity.
Activity activity = Activity.Current;
// Get the trace ID of the activity.
string traceId = activity?.TraceId.ToHexString();
// Get the span ID of the activity.
string spanId = activity?.SpanId.ToHexString();

Passaggi successivi

  • Per configurare ulteriormente la distribuzione di OpenTelemetry, vedere Configurazione di OpenTelemetry di Monitoraggio di Azure
  • Per esaminare il codice sorgente, vedere il repository GitHub aspNetCore di Monitoraggio di Azure.
  • Per installare il pacchetto NuGet, verificare la disponibilità di aggiornamenti o visualizzare le note sulla versione, vedere la pagina Del pacchetto NuGet AspNetCore di Monitoraggio di Azure.
  • Per acquisire familiarità con Monitoraggio di Azure e OpenTelemetry, vedere l'applicazione di esempio di Monitoraggio di Azure.
  • Per altre informazioni su OpenTelemetry e sulla relativa community, vedere il repository GitHub OpenTelemetry .NET.
  • Per abilitare le esperienze di utilizzo, abilitare il monitoraggio degli utenti del Web o del browser.

Domande frequenti

Questa sezione fornisce le risposte alle domande comuni.

Che cos'è OpenTelemetry?

Si tratta di un nuovo standard open source per l'osservabilità. Per altre informazioni, vedere OpenTelemetry.

Perché Monitoraggio di Microsoft Azure investe in OpenTelemetry?

Microsoft è tra i maggiori collaboratori a OpenTelemetry.

Le proposte chiave di valore di OpenTelemetry sono che sono indipendenti dal fornitore e forniscono API/SDK coerenti in tutte le lingue.

Nel corso del tempo, Si ritiene che OpenTelemetry consentirà ai clienti di Monitoraggio di Azure di osservare le applicazioni scritte in lingue diverse dalle lingue supportate. Espande anche i tipi di dati che è possibile raccogliere tramite un set completo di librerie di strumentazione. Inoltre, gli SDK OpenTelemetry tendono ad essere più efficienti su larga scala rispetto ai predecessori, gli SDK di Application Insights.

Infine, OpenTelemetry si allinea alla strategia di Microsoft per adottare l'open source.

Qual è lo stato di OpenTelemetry?

Vedere Stato OpenTelemetry.

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

È possibile considerarlo come un wrapper sottile che aggrega tutti i componenti OpenTelemetry per un'esperienza di prima classe in Azure. Questo wrapper è detto anche distribuzione in OpenTelemetry.

Perché è consigliabile usare la distribuzione di OpenTelemetry di Monitoraggio di Azure?

L'uso della distribuzione OpenTelemetry di Monitoraggio di Azure tramite OpenTelemetry nativo dalla community offre diversi vantaggi:

Nello spirito di OpenTelemetry, abbiamo progettato la distribuzione per essere aperta ed estendibile. Ad esempio, è possibile aggiungere:

  • Esportazione del protocollo OTLP (OpenTelemetry Protocol) e invio simultaneamente 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 in questo modo è possibile disabilitare alcune delle funzionalità incluse della distribuzione. Per altre informazioni sull'sampler supportato, vedere la sezione Abilitare il campionamento di Configurare OpenTelemetry di Monitoraggio di Azure.

Per le lingue senza 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 le lingue 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 di OpenTelemetry di Monitoraggio di Azure?

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

È consigliabile usare OpenTelemetry o Application Insights SDK?

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

L'adozione di OpenTelemetry impedisce ora di eseguire 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 da iniziare.

Per tutti gli altri scenari .NET, inclusi i ASP.NET classici, le app console 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 Python Monitoraggio di Azure OpenTelemetry Exporter.

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

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

Funzionalità .NET Node.js Python Java
Traccia distribuita ✅ ✅ ✅ ✅
Metriche personalizzate ✅ ✅ ✅ ✅
Metriche standard (accuratezza attualmente interessata dal campionamento) ✅ ✅ ✅ ✅
Campionamento a frequenza fissa ✅ ✅ ✅ ✅
Archiviazione offline e tentativi automatici ✅ ✅ ✅ ✅
Segnalazione eccezioni ✅ ✅ ✅ ✅
Raccolta logs ✅ ⚠️ ✅ ✅
Eventi personalizzati ⚠️ ⚠️ ⚠️ ✅
Autenticazione Microsoft Entra ✅ ✅ ✅ ✅
Metriche attive ❌ ❌ ❌ ✅
Rilevare il contesto delle risorse per vm/set di scalabilità di macchine virtuali e servizio app ✅ ❌ ✅ ✅
Rilevare il contesto delle risorse per il servizio Azure Kubernetes e le funzioni ❌ ❌ ❌ ✅
Filtro intervallo di test di disponibilità ❌ ❌ ❌ ✅
Popolamento automatico dell'ID utente, ID utente autenticato e IP utente ❌ ❌ ❌ ✅
Eseguire manualmente l'override/impostare il nome dell'operazione, l'ID utente o l'ID utente autenticato ❌ ❌ ❌ ✅
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 Application Insights JavaScript SDK.

Quando è possibile prevedere che OpenTelemetry SDK sia disponibile per l'uso nei Web browser?

OpenTelemetry Web SDK non ha una sequenza temporale di disponibilità determinata. Probabilmente ci sono diversi anni di distanza da un SDK del browser che è un'alternativa praticabile all'SDK JavaScript di Application Insights.

È 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 è supportato?

No. Questa procedura non è un elemento che si prevede di testare o supportare, anche se le distribuzioni consentono di esportare in un endpoint OTLP insieme a Monitoraggio di Azure contemporaneamente.

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

Non è consigliabile. 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.

È possibile usare OpenTelemetry Collector?

Alcuni clienti usano OpenTelemetry Collector come alternativa agente, anche se 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.

Risoluzione dei problemi

Non funziona? Vedere la pagina relativa alla risoluzione dei problemi per ASP.NET Core.

Supporto tecnico

Selezionare una scheda per la lingua scelta per individuare le opzioni di supporto.

  • Per supporto tecnico di Azure problemi, aprire un ticket di supporto tecnico di Azure.
  • Per i problemi di 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 fornire commenti e suggerimenti: