Hinzufügen, Ändern und Filtern von OpenTelemetry

  • Artikel

Dieser Artikel enthält Anleitungen zum Hinzufügen, Ändern und Filtern von OpenTelemetry für Anwendungen mithilfe von Azure Monitor Application Insights.

Weitere Informationen zu OpenTelemetry-Konzepten finden Sie in der OpenTelemetry-Übersicht oder in den Häufig gestellten Fragen zu OpenTelemetry.

Automatische Datensammlung

Die Distributionen sammeln Daten automatisch durch Bündelung von OpenTelemetry-Instrumentierungsbibliotheken.

Enthaltene Instrumentierungsbibliotheken

Requests

Abhängigkeiten

Protokollierung

  • ILogger

Weitere Informationen zu ILogger finden Sie unter Protokollierung in C# und .NET und unter Codebeispiele.

Fußnoten

  • ¹: Unterstützt das automatische Melden von unbehandelten/nicht erkannten Fehlern
  • ²: Unterstützt OpenTelemetry-Metriken
  • ³: Die Protokollierung erfolgt standardmäßig mindestens auf INFO-Ebene. Um diese Einstellung zu ändern, lesen Sie die Konfigurationsoptionen.
  • ⁴: Die Protokollierung wird standardmäßig nur erfasst, wenn sie auf der Ebene WARNUNG oder höher erfolgt.

Hinweis

Die OpenTelemetry-Distributionen von Azure Monitor umfassen eine benutzerdefinierte Zuordnung und Logik, um automatisch Application Insights-Standardmetriken auszugeben.

Tipp

Alle OpenTelemetry-Metriken, unabhängig davon, ob sie automatisch von Instrumentenbibliotheken oder manuell durch benutzerdefinierte Kodierung erfasst werden, gelten derzeit für Abrechnungszwecke als „benutzerdefinierte Metriken“ von Application Insights. Weitere Informationen.

Hinzufügen einer Community-Instrumentierungsbibliothek

Sie können automatisch mehr Daten sammeln, wenn Sie Instrumentierungsbibliotheken aus der OpenTelemetry-Community einschließen.

Achtung

Community-Instrumentierungsbibliotheken werden von uns nicht unterstützt und wir übernehmen keine Garantie für ihre Qualität. Wenn Sie einen Vorschlag für unsere Distribution machen möchten, posten Sie ihn in unserer Feedback-Community oder geben Sie dort ein Up-Vote ab. Beachten Sie, dass einige auf experimentellen OpenTelemetry-Spezifikationen basieren und möglicherweise zukünftige grundlegende Änderungen einführen.

Verwenden Sie zum Hinzufügen einer Communitybibliothek die Methoden ConfigureOpenTelemetryMeterProvider oder ConfigureOpenTelemetryTracerProvider, nachdem Sie das Nuget-Paket für die Bibliothek hinzugefügt haben.

Im folgenden Beispiel wird veranschaulicht, wie die Laufzeitinstrumentierung hinzugefügt werden kann, um zusätzliche Metriken zu sammeln.

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();

Erfassen benutzerdefinierter Telemetriedaten

In diesem Abschnitt erfahren Sie, wie Sie benutzerdefinierte Telemetrie aus Ihrer Anwendung erfassen.

Abhängig von Ihrer Sprache und Ihrem Signaltyp gibt es verschiedene Möglichkeiten, benutzerdefinierte Telemetriedaten zu erfassen, darunter:

  • OpenTelemetry-API
  • Sprachspezifische Protokollierung/Metrikbibliotheken
  • Classic API von Application Insights

Die folgende Tabelle stellt die derzeit unterstützten benutzerdefinierten Telemetrietypen dar:

Sprache Benutzerdefinierte Ereignisse Benutzerdefinierte Metriken Abhängigkeiten Ausnahmen Seitenaufrufe Requests Traces
ASP.NET Core
   OpenTelemetry-API Ja Ja Ja Ja
   ILogger API Ja
   KI Classic API
Java
   OpenTelemetry-API Ja Ja Ja Ja
   Logback, Log4j, JUL Ja Ja
   Mikrometer-Metriken Ja
   KI Classic API Ja Ja Ja Ja Ja Ja Ja
Node.js
   OpenTelemetry-API Ja Ja Ja Ja
Python
   OpenTelemetry-API Ja Ja Ja Ja
   Python-Protokollierungsmodul Ja
   Ereigniserweiterung Ja Ja

Hinweis

Application Insights Java 3.x lauscht auf Telemetriedaten, die an die Classic API von Application Insights gesendet werden. Auf ähnliche Weise erfasst Application Insights Node.js 3.x Ereignisse, die mit der Classic API von Application Insights erstellt wurden. Dies erleichtert Upgrades und füllt eine Lücke in unserer Unterstützung für benutzerdefinierte Telemetrie, bis alle benutzerdefinierten Telemetrietypen über die OpenTelemetry-API unterstützt werden.

Hinzufügen benutzerdefinierter Metriken

In diesem Zusammenhang bezieht sich benutzerdefinierte Metriken darauf, Ihren Code manuell zu instrumentieren, um zusätzliche Metriken zu sammeln, die über das hinausgehen, was die OpenTelemetry Instrumentierungsbibliotheken automatisch sammeln.

Die OpenTelemetry-API bietet sechs Metrikinstrumente zur Abdeckung verschiedener Metrikszenarien, und Sie müssen beim Visualisieren von Metriken im Metrik-Explorer den richtigen Aggregationstyp auswählen. Diese Anforderung gilt bei Verwendung der OpenTelemetry-Metrik-API zum Senden von Metriken sowie bei Verwendung einer Instrumentierungsbibliothek.

Die folgende Tabelle enthält die empfohlenen Aggregationstypen für die einzelnen OpenTelemetry-Metrikinstrumente:

OpenTelemetry-Instrument Aggregationstyp von Azure Monitor
Leistungsindikator Sum
Asynchroner Zähler Sum
Histogramm Minimum, Maximum, Mittelwert, Summe und Anzahl
Asynchrones Messgerät Average
UpDownCounter Sum
UpDownCounter (asynchron) Sum

Achtung

Andere Aggregationstypen als die in der Tabelle angegebenen Typen sind in der Regel nicht aussagekräftig.

Die OpenTelemetry-Spezifikation beschreibt die Instrumente und enthält Verwendungsbeispiele.

Tipp

Das Histogramm ist am vielseitigsten und entspricht am ehesten der Classic API von Application Insights für GetMetric. Azure Monitor vereinfacht das Histogramminstrument derzeit mit unseren fünf unterstützten Aggregationstypen, und Quantile werden demnächst unterstützt. Andere OpenTelemetry-Instrumente sind zwar weniger vielseitig, haben dafür aber auch weniger Auswirkungen auf die Leistung Ihrer Anwendung.

Histogrammbeispiel

Der Anwendungsstart muss eine Verbrauchseinheit nach Name abonnieren.

// 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();

Meter muss mit demselben Namen initialisiert werden.

// 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"));

Counter-Beispiel

Der Anwendungsstart muss eine Verbrauchseinheit nach Name abonnieren.

// 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();

Meter muss mit demselben Namen initialisiert werden.

// 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"));

Messgerätbeispiel

Der Anwendungsstart muss eine Verbrauchseinheit nach Name abonnieren.

// 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();

Meter muss mit demselben Namen initialisiert werden.

// 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));
    }
}

Hinzufügen benutzerdefinierter Ausnahmen

Bestimmte Instrumentierungsbibliotheken melden automatisch Ausnahmen für Application Insights. Möglicherweise möchten Sie jedoch manuell Ausnahmen melden, die über die Berichte von Instrumentierungsbibliotheken hinausgehen. Beispielsweise werden von Ihrem Code erfasste Ausnahmen üblicherweise nicht gemeldet. Unter Umständen empfiehlt es sich, sie zu melden, um in relevanten Umgebungen auf sie aufmerksam zu machen. Hierzu zählen unter anderem der Fehlerabschnitt sowie End-to-End-Transaktionsansichten.

  • Protokollieren einer Ausnahme mithilfe einer Aktivität: 
    // 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);
    }
}
  • Protokollieren einer Ausnahme mithilfe von 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" });
}

Hinzufügen von benutzerdefinierten Spannen

In zwei Szenarien sollten Sie eine benutzerdefinierte Spanne hinzufügen. Erstens, wenn eine Abhängigkeitsanforderung vorhanden ist, die nicht bereits von einer Instrumentierungsbibliothek erfasst wurde. Zweitens, wenn Sie einen Anwendungsprozess als Spanne in der End-to-End-Transaktionsansicht modellieren möchten.

Hinweis

Die Klassen Activity und ActivitySource aus dem System.Diagnostics-Namespace stellen die OpenTelemetry-Konzepte von Span bzw. Tracer dar. Sie erstellen ActivitySource direkt mithilfe des Konstruktors anstelle von mithilfe von TracerProvider. Jede Klasse ActivitySource muss mithilfe von AddSource() explizit mit TracerProvider verbunden werden. Dies liegt daran, dass Teile der OpenTelemetry-Ablaufverfolgungs-API direkt in die .NET-Runtime integriert sind. Weitere Informationen finden Sie unter Einführung in die .NET-Ablaufverfolgungs-API für 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 ist standardmäßig auf ActivityKind.Internal festgelegt. Sie können jedoch eine beliebige andere ActivityKind angeben. ActivityKind.Client, ActivityKind.Producer und ActivityKind.Internal sind Application Insights-dependencies zugeordnet. ActivityKind.Server und ActivityKind.Consumer sind Application Insights-requests zugeordnet.

Senden von benutzerdefinierten Telemetriedaten mithilfe der Classic API von Application Insights

Es wird empfohlen, nach Möglichkeit die OpenTelemetry-APIs zu verwenden. Es kann jedoch einige Szenarien geben, in denen Sie die Classic API von Application Insights verwenden müssen.

Ereignisse

  1. Fügen Sie Ihrer Anwendung Microsoft.ApplicationInsights hinzu.

  2. Erstellen Sie eine TelemetryClient-Instanz.

Hinweis

Es ist wichtig, nur einmal eine Instanz des TelemetryClient pro Anwendung zu erstellen.

var telemetryConfiguration = new TelemetryConfiguration { ConnectionString = "" };
var telemetryClient = new TelemetryClient(telemetryConfiguration);
  1. Verwenden Sie den Client, um benutzerdefinierte Telemetriedaten zu senden.
telemetryClient.TrackEvent("testEvent");

Ändern der Telemetrie

In diesem Abschnitt wird das Ändern von Telemetriedaten erläutert.

Hinzufügen von span-Attributen

Zu diesen Attributen kann das Hinzufügen einer benutzerdefinierten Eigenschaft zu Ihrer Telemetrie gehören. Sie können auch Attribute verwenden, um optionale Felder im Application Insights-Schema festzulegen, z. B. Client-IP.

Hinzufügen einer benutzerdefinierten Eigenschaft zu einer Spanne

Alle Attribute, die Sie Spans hinzufügen, werden als benutzerdefinierte Eigenschaften exportiert. Sie füllen das Feld customDimensions in der Tabelle mit Anforderungen, Abhängigkeiten, Überwachungen oder Ausnahmen mit Daten auf.

Verwenden Sie zum Hinzufügen von Span-Attributen eine der beiden folgenden Möglichkeiten:

Tipp

Der Vorteil der Verwendung von Optionen, die von Instrumentierungsbibliotheken bereitgestellt werden, wenn sie verfügbar sind, ist, dass der gesamte Kontext verfügbar ist. Dadurch können Benutzer weitere Attribute hinzufügen oder filtern. Mit der Option „anreichern“ in der HttpClient-Instrumentierungsbibliothek erhalten Benutzer beispielsweise Zugriff auf HttpRequestMessage und die HttpResponseMessage selbst. Sie können alles daraus auswählen und als Attribut speichern.

  1. Viele Instrumentierungsbibliotheken bieten eine Anreicherungsoption. Eine Anleitung finden Sie in den Readme-Dateien der einzelnen Instrumentierungsbibliotheken:

  2. Verwenden eines benutzerdefinierten Prozessors:

Tipp

Fügen Sie den hier gezeigten Prozessor vor dem Hinzufügen von Azure Monitor hinzu.

// 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();

Fügen Sie Ihrem Projekt ActivityEnrichingProcessor.cs mit dem unten aufgeführten Code hinzu:

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");
    }
}

Festlegen der Benutzer-IP

Sie können das Feld client_IP für Anforderungen auffüllen, indem Sie ein Attribut für den Bereich festlegen. Application Insights verwendet die IP-Adresse zum Generieren von Benutzerstandortattributen und verwirft sie dann standardmäßig.

Verwenden Sie das Beispiel zum Hinzufügen einer benutzerdefinierten Eigenschaft, ersetzen Sie dabei aber die folgenden Codezeilen 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>");

Festlegen der Benutzer-ID oder der authentifizierten Benutzer-ID

Sie können das Feld user_Id oder user_AuthenticatedId für Anforderungen mit Daten auffüllen, indem Sie die folgende Anleitung verwenden. Die Benutzer-ID ist ein anonymer Benutzerbezeichner. Die authentifizierte Benutzer-ID ist ein bekannter Benutzerbezeichner.

Wichtig

Informieren Sie sich über die geltenden Datenschutzgesetze, bevor Sie die authentifizierte Benutzer-ID festlegen.

Verwenden Sie das Beispiel zum Hinzufügen benutzerdefinierter Eigenschaften.

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

Hinzufügen von Protokollattributen

OpenTelemetry verwendet den ILogger von .NET. Das Anfügen benutzerdefinierter Dimensionen an Protokolle kann mithilfe einer Nachrichtenvorlage erfolgen.

Filtern von Telemetriedaten

Sie können die folgenden Methoden verwenden, um Telemetriedaten herausfiltern, bevor sie Ihre Anwendung verlassen.

  1. Viele Instrumentierungsbibliotheken bieten eine Filteroption. Eine Anleitung finden Sie in den Readme-Dateien der einzelnen Instrumentierungsbibliotheken:

  2. Verwenden eines benutzerdefinierten Prozessors:

    Tipp

    Fügen Sie den hier gezeigten Prozessor vor dem Hinzufügen von Azure Monitor hinzu.

    // 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();

    Fügen Sie Ihrem Projekt ActivityFilteringProcessor.cs mit dem unten aufgeführten Code hinzu:

    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. Wenn eine bestimmte Quelle nicht explizit mit AddSource("ActivitySourceName") hinzugefügt wird, wird keine der Aktivitäten exportiert, die mit dieser Quelle erstellt wurden.

Abrufen der Ablaufverfolgungs-ID oder Span-ID

Möglicherweise möchten Sie die Ablaufverfolgungs-ID oder Spannen-ID abrufen. Wenn Protokolle an ein anderes Ziel als Application Insights gesendet werden, sollten Sie die Ablaufverfolgungs-ID oder die Span-ID hinzufügen. Dies ermöglicht eine bessere Korrelation beim Debuggen und Diagnostizieren von Problemen.

Hinweis

Die Klassen Activity und ActivitySource aus dem System.Diagnostics-Namespace stellen die OpenTelemetry-Konzepte von Span bzw. Tracer dar. Dies liegt daran, dass Teile der OpenTelemetry-Ablaufverfolgungs-API direkt in die .NET-Runtime integriert sind. Weitere Informationen finden Sie unter Einführung in die .NET-Ablaufverfolgungs-API für 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();

Nächste Schritte

Häufig gestellte Fragen

Dieser Abschnitt enthält Antworten auf häufig gestellte Fragen.

Was ist OpenTelemetry?

Es handelt sich um einen neuen Open-Source-Standard für Einblicke. Weitere Informationen finden Sie unter OpenTelemetry.

Warum investiert Microsoft Azure Monitor in OpenTelemetry?

Microsoft gehört zu den Unternehmen, die den größten Beitrag zu OpenTelemetry leisten.

Die wichtigsten Wertversprechen von OpenTelemetry sind, dass es anbieterneutral ist und über einheitliche APIs und SDKs für alle Sprachen verfügt.

Wir glauben, dass OpenTelemetry im Laufe der Zeit Azure Monitor-Kunden ermöglichen wird, auch Anwendungen zu überwachen, die in anderen als den von uns unterstützten Sprachen geschrieben wurden. Außerdem werden die Datentypen erweitert, die Sie über einen umfangreichen Satz von Instrumentierungsbibliotheken erfassen können. Darüber hinaus sind OpenTelemetry-SDKs tendenziell im großen Stil leistungsstärker als ihre Vorgänger, die Application Insights-SDKs.

Darüber hinaus ist OpenTelemetry an der Microsoft-Strategie zur Förderung von Open Source ausgerichtet.

Wie ist der Status von OpenTelemetry?

Siehe OpenTelemetry Status.

Was ist die OpenTelemetry-Distribution von Azure Monitor?

Sie können es sich als dünnen Wrapper vorstellen, der alle OpenTelemetry-Komponenten für eine erstklassige Erfahrung in Azure bündelt. Dieser Wrapper wird auch als Verteilung in OpenTelemetry bezeichnet.

Warum sollte ich die OpenTelemetry-Distribution von Azure Monitor verwenden?

Die Verwendung der OpenTelemetry-Distribution von Azure Monitor hat gegenüber der nativen OpenTelemetry aus der Community mehrere Vorteile:

Im Sinne von OpenTelemetry haben wir die Distribution so konzipiert, dass sie offen und erweiterbar ist. Sie können beispielsweise Folgendes tun:

  • Ein OpenTelemetry Protocol (OTLP)-Exporter und gleichzeitiges Senden an ein zweites Ziel
  • Andere Instrumentierungsbibliotheken, die nicht in der Distribution enthalten sind

Da die Distro eine OpenTelemetry-Verteilung bereitstellt, unterstützt die Distro alles, was von OpenTelemetry unterstützt wird. Sie können beispielsweise weitere Telemetrieprozessoren, Exporteure oder Instrumentierungsbibliotheken hinzufügen, wenn OpenTelemetry sie unterstützt.

Hinweis

Die Distro legt den Sampler auf einen benutzerdefinierten Sampler mit fester Rate für Application Insights fest. Sie können dies in einen anderen Sampler ändern, dies kann jedoch einige der enthaltenen Funktionen von Distro deaktivieren. Weitere Informationen zum unterstützten Sampler finden Sie im Abschnitt Aktivieren des Samplings von Konfigurieren von Azure Monitor OpenTelemetry.

Für Sprachen ohne einen unterstützten eigenständigen OpenTelemetry-Exporter ist der Azure Monitor OpenTelemetry Distro die einzige derzeit unterstützte Methode zur Verwendung von OpenTelemetry mit Azure Monitor. Für Sprachen mit einem unterstützten eigenständigen OpenTelemetry-Exporter haben Sie je nach Telemetrieszenario die Möglichkeit, entweder den Azure Monitor OpenTelemetry Distro oder den entsprechenden eigenständigen OpenTelemetry-Exporter zu verwenden. Weitere Informationen finden Sie unter Wann sollte ich den OpenTelemetry-Exporter von Azure Monitor verwenden?.

Wie kann ich die OpenTelemetry-Distribution von Azure Monitor testen?

Sehen Sie sich unsere Aktivierungsdokumentation für .NET, Java, JavaScript (Node.js) und Python an.

Sollte ich OpenTelemetry oder das Application Insights-SDK verwenden?

Wir empfehlen die Verwendung der OpenTelemetry-Distribution, es sei denn, Sie benötigen ein Feature, das nur mit formaler Unterstützung im Application Insights-SDK verfügbar ist.

Wenn OpenTelemetry jetzt eingeführt wird, wird verhindert, dass zu einem späteren Zeitpunkt migriert werden muss.

Wann sollte ich den OpenTelemetry-Exporter von Azure Monitor verwenden?

Für ASP.NET Core, Java, Node.js und Python empfehlen wir die Verwendung der Azure Monitor OpenTelemetry Distro. Es ist nur eine Codezeile, um loszulegen.

Für alle anderen .NET-Szenarien, einschließlich klassischem ASP.NET, Konsolenanwendungen usw., empfehlen wir die Verwendung des .NET Azure Monitor OpenTelemetry-Exporters: Azure.Monitor.OpenTelemetry.Exporter.

Für komplexere Python-Telemetrieszenarien, die eine erweiterte Konfiguration erfordern, empfehlen wir die Verwendung des Python Azure Monitor OpenTelemetry-Exporters.

Wie lautet der aktuelle Releasestatus der Features in der OpenTelemetry-Distribution von Azure Monitor?

Im folgenden Diagramm ist die Unterstützung der OpenTelemetry-Funktion für jede Sprache aufgeschlüsselt.

Funktion .NET Node.js Python Java
Verteilte Ablaufverfolgung ✅ ✅ ✅ ✅
Benutzerdefinierte Metriken ✅ ✅ ✅ ✅
Standardmetriken (Genauigkeit derzeit beeinflusst durch Sampling) ✅ ✅ ✅ ✅
Stichprobenerstellung mit festem Prozentsatz ✅ ✅ ✅ ✅
Offlinespeicher und automatische Wiederholungsversuche ✅ ✅ ✅ ✅
Ausnahmeberichterstattung ✅ ✅ ✅ ✅
Protokollerfassung ✅ ⚠️ ✅ ✅
Benutzerdefinierte Ereignisse ⚠️ ⚠️ ⚠️ ✅
Microsoft Entra-Authentifizierung ✅ ✅ ✅ ✅
Livemetriken ❌ ❌ ❌ ✅
Erkennen des Ressourcenkontexts für VM/VMSS und App Service ✅ ❌ ✅ ✅
Erkennen des Ressourcenkontexts für AKS und Functions ❌ ❌ ❌ ✅
Filterung nach Verfügbarkeitstestspanne ❌ ❌ ❌ ✅
Automatisches Auffüllen von Benutzer-ID, authentifizierter Benutzer-ID und Benutzer-IP-Adresse ❌ ❌ ❌ ✅
Manuelles Überschreiben/Festlegen von Vorgangsname, Benutzer-ID oder authentifizierter Benutzer-ID ❌ ❌ ❌ ✅
Adaptive Stichprobenerstellung ❌ ❌ ❌ ✅
Profiler ❌ ❌ ❌ ⚠️
Momentaufnahmedebugger ❌ ❌ ❌ ❌

Schlüssel

Kann OpenTelemetry für Webbrowser verwendet werden?

Ja, aber wir empfehlen es nicht, und Azure unterstützt es nicht. OpenTelemetry JavaScript ist in hohem Maße für Node.js optimiert. Stattdessen wird empfohlen, das Application Insights JavaScript SDK zu verwenden.

Wann können wir damit rechnen, dass das OpenTelemetry SDK für die Verwendung in Webbrowsern verfügbar sein wird?

Für das OpenTelemetry-Web-SDK gibt es keine festgelegte Verfügbarkeitszeitachse. Wir sind wahrscheinlich noch einige Jahre von einem Browser-SDK entfernt, das eine brauchbare Alternative zum Application Insights JavaScript-SDK wäre.

Kann ich OpenTelemetry heute in einem Webbrowser testen?

Die OpenTelemetry Web Sandbox ist ein Fork, mit dem OpenTelemetry in einem Browser funktioniert. Es ist aber noch nicht möglich, Telemetriedaten an Application Insights zu senden. Das SDK definiert keine allgemeinen Clientereignisse.

Wird die Ausführung von Application Insights zusammen mit Agents von Mitbewerbern wie AppDynamics, DataDog und NewRelic unterstützt?

Nein. Wir haben nicht vor, diese Praxis zu testen oder zu unterstützen, obwohl unsere Distributionen es Ihnen ermöglichen, gleichzeitig neben Azure Monitor einen OTLP-Endpunkt zu exportieren.

Kann ich in Produktionsumgebungen die Previewfunktionen verwenden?

Wir raten davon ab. Siehe Ergänzende Nutzungsbedingungen für Microsoft Azure-Vorschauversionen.

Was ist der Unterschied zwischen manueller und automatischer Instrumentierung?

Weitere Informationen finden Sie in der OpenTelemetry-Übersicht.

Kann ich den OpenTelemetry-Collector verwenden?

Einige Kunden verwenden den OpenTelemetry-Collector als Agent-Alternative, obwohl Microsoft einen Agent-basierenden Ansatz für die Anwendungsüberwachung noch nicht offiziell unterstützt. In der Zwischenzeit wurde von der Open-Source-Community ein Azure Monitor-Exporter für den OpenTelemetry-Collector bereitgestellt, der von einigen Kunden zum Senden von Daten an Azure Monitor Application Insights verwendet wird. Dies wird von Microsoft nicht unterstützt.

Worin besteht der Unterschied zwischen OpenCensus und OpenTelemetry?

OpenCensus ist der Vorgänger von OpenTelemetry. Mit der Hilfe von Microsoft entstand OpenTelemetry aus einer Zusammenführung von OpenTracing und OpenCensus als einzelner Einblickstandard für die ganze Welt. Das aktuelle für die Produktion empfohlene Python SDK für Azure Monitor basiert auf OpenCensus. Microsoft hat sich verpflichtet, Azure Monitor auf der Grundlage von OpenTelemetry zu entwickeln.

Problembehandlung

Funktioniert etwas nicht? Sehen Sie sich die Problembehandlungsseite für ASP.NET Core an.

Unterstützung

Wählen Sie eine Registerkarte für die Sprache Ihrer Wahl aus, um Supportoptionen zu ermitteln.

OpenTelemetry-Feedback

So können Sie Feedback geben