Partager via

Ajouter, modifier et filtrer OpenTelemetry

  • Article

Cet article explique comment ajouter, modifier et filtrer OpenTelemetry pour les applications à l’aide d’Azure Monitor Application Insights.

Pour en savoir plus sur les concepts OpenTelemetry, consultez la vue d’ensemble d’OpenTelemetry ou les questions fréquentes (FAQ).

Collecte automatique des données

Les distributions collectent automatiquement les données en intégrant les bibliothèques d’instrumentation OpenTelemetry.

Bibliothèques d’instrumentation incluses

Demandes

Dépendances

Logging

  • ILogger

Pour plus d’informations sur ILogger, consultez Journalisation dans C# et .NET et les exemples de code.

Notes de bas de page

  • ¹ : prend en charge la création de rapports automatiques d’exceptions non gérées/non capturées
  • ² : prend en charge les métriques OpenTelemetry
  • ³ : par défaut, la journalisation est uniquement collectée au niveau d’INFO ou supérieur. Pour modifier ce paramètre, consultez les options de configuration.
  • ⁴ : par défaut, la journalisation est uniquement collectée lorsqu’elle est réalisée au niveau d'avertissement ou à un niveau supérieur.

Remarque

Les Distributions Azure Monitor OpenTelemetry incluent un mappage et une logique personnalisés pour émettre automatiquement des métriques standard Application Insights.

Conseil

Toutes les métriques OpenTelemetry collectées automatiquement à partir de bibliothèques d’instrumentation ou manuellement collectées à partir du codage personnalisé sont actuellement considérées comme des « métriques personnalisées » d’Application Insights à des fins de facturation. Plus d’informations

Ajouter une bibliothèque d’instrumentation de communauté

Vous pouvez collecter automatiquement davantage de données lorsque vous incluez des bibliothèques d’instrumentation de la communauté OpenTelemetry.

Attention

Nous ne prenons pas en charge et ne garantissons la qualité des bibliothèques d’instrumentation de la communauté. Pour en suggérer une pour notre distribution, publier ou voter dans nos commentaires de la communauté. N’oubliez pas que certaines sont basées sur des spécifications OpenTelemetry expérimentales et peuvent introduire des changements cassants futurs.

Pour ajouter une bibliothèque de communauté, utilisez les méthodes ConfigureOpenTelemetryMeterProvider ou ConfigureOpenTelemetryTracerProvider, après avoir ajouté le package NuGet pour la bibliothèque.

L'exemple suivant montre comment l'instrumentation du temps d'exécution peut être ajoutée pour collecter des données supplémentaires :

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

Collecter des données de télémétrie personnalisées

Cette section explique comment collecter des données de télémétrie personnalisées à partir de votre application.

Selon votre langage et votre type de signal, il existe différentes façons de collecter des données de télémétrie personnalisées, notamment :

  • API OpenTelemetry
  • Bibliothèques de métriques/journalisation spécifiques au langage
  • API classique Application Insights

Le tableau suivant représente les types de télémétrie personnalisés actuellement pris en charge :

Langage Événements personnalisés Métriques personnalisées Les dépendances Exceptions Affichages de pages Demandes Traces
ASP.NET Core
   API OpenTelemetry Oui Oui Oui Oui
   ILogger API Oui
   API IA classique
Java
   API OpenTelemetry Oui Oui Oui Oui
   Logback, Log4j, JUL Oui Oui
   Mesures Micrometer Oui
   API IA classique Oui Oui Oui Oui Oui Oui Oui
Node.JS
   API OpenTelemetry Oui Oui Oui Oui
Python
   API OpenTelemetry Oui Oui Oui Oui
   Module de journalisation Python Oui
   Extension d’événements Oui Oui

Notes

Application Insights Java 3.x écoute les données de télémétrie envoyées à l’API classique Application Insights. De même, Application Insights Node.js 3.x collecte les événements créés avec l’API classique Application Insights. Cela facilite la mise à niveau et comble un écart important dans notre prise en charge de la télémétrie personnalisée jusqu’à ce que tous les types de télémétrie personnalisés soient pris en charge via l’API OpenTelemetry.

Ajouter des métriques personnalisées

Dans ce contexte, les métriques personnalisées font référence à l’instrumentation manuelle de votre code pour collecter des métriques supplémentaires au-delà de ce que les bibliothèques d’instrumentation OpenTelemetry collectent automatiquement.

L’API OpenTelemetry propose six « instruments » de métriques pour couvrir différents scénarios de métriques et vous devez choisir le « Type d’agrégation » correct lors de la visualisation des métriques dans Metrics Explorer. Cette exigence est vraie lors de l’utilisation de l’API de métrique OpenTelemetry pour envoyer des métriques et lors de l’utilisation d’une bibliothèque d’instrumentation.

Le tableau suivant présente les types d’agrégation recommandés pour chacun des instruments de métriques OpenTelemetry.

Instrumentation OpenTelemetry Type d’agrégation Azure Monitor
Compteur Sum
Compteur asynchrone Sum
Histogramme Min, Max, Moyenne, Somme et Nb
Jauge asynchrone Moyenne
UpDownCounter Sum
UpDownCounter asynchrone Sum

Attention

Les types d’agrégation au-delà des éléments affichés dans le tableau ne sont généralement pas significatifs.

La Spécification OpenTelemetry décrit les instruments et fournit des exemples de cas où vous pouvez utiliser chacun d’eux.

Conseil

L’histogramme est l’équivalent le plus versatile et le plus proche de l’API classique Application Insights GetMetric. Azure Monitor aplatit actuellement l’instrumentation de l’histogramme dans nos cinq types d’agrégation pris en charge. La prise en charge des centiles est en cours. Bien que moins polyvalents, les autres instruments OpenTelemetry ont un impact moindre sur les performances de votre application.

Exemple d’histogramme

Le start-up de l’application doit s’abonner à un compteur par nom :

// 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 doit être initialisé à l’aide de ce même nom :

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

Exemple de compteur

Le start-up de l’application doit s’abonner à un compteur par nom :

// 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 doit être initialisé à l’aide de ce même nom :

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

Exemple de jauge

Le start-up de l’application doit s’abonner à un compteur par nom :

// 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 doit être initialisé à l’aide de ce même nom :

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

Ajoutez des exceptions personnalisées

Sélectionnez des bibliothèques d’instrumentation qui signalent automatiquement les exceptions à Application Insights. Toutefois, vous pourriez signaler manuellement des exceptions au-delà du rapport des bibliothèques d’instrumentation. Par exemple, les exceptions interceptées par votre code ne sont généralement pas signalées. Vous pourriez les signaler pour attirer l’attention sur les expériences pertinentes, notamment la section relative aux défaillances et les vues des transactions de bout en bout.

  • Pour enregistrer une exception à l’aide d’une activité :

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

  • Pour enregistrer une exception à l’aide de 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" });
}

Ajouter des étendues personnalisées

Vous pourriez ajouter une étendue personnalisée dans deux scénarios. Tout d’abord, lorsqu’une requête de dépendance n’est pas encore collectée par une bibliothèque d’instrumentation. Deuxièmement, lorsque vous souhaitez modéliser un processus d’application en tant qu’étendue sur la vue transactionnelle de bout en bout.

Notes

Les classes Activity et ActivitySource de l’espace de noms System.Diagnostics représentent les concepts OpenTelemetry de Span et Tracer respectivement. Vous créez ActivitySource directement à l’aide de son constructeur à la place de TracerProvider. Chaque classe ActivitySource doit être explicitement connectée àTracerProvider à l’aide de AddSource() . Cela est dû au fait que des parties de l’API de suivi OpenTelemetry sont incorporées directement dans le runtime .NET. Pour plus d’informations, consultez Présentation de l’API de suivi .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 a la valeur par défaut ActivityKind.Internal, mais vous pouvez fournir n’importe quel autre ActivityKind. ActivityKind.Client, ActivityKind.Producer et ActivityKind.Internal sont mappés sur Application Insights dependencies. ActivityKind.Server et ActivityKind.Consumer sont mappés sur Application Insights requests.

Envoyer une télémétrie personnalisée à l’aide de l’API Application Insights Classic

Nous vous recommandons d’utiliser les API OpenTelemetry dans la mesure du possible, mais il peut y avoir certains scénarios dans lesquels vous devez utiliser l’API classique d’Application Insights.

Événements

  1. Ajoutez Microsoft.ApplicationInsights à votre application :

  2. Créez une instance TelemetryClient :

    Remarque

    Il est important de créer une seule instance de TelemetryClient par application.

    var telemetryConfiguration = new TelemetryConfiguration { ConnectionString = "" };
var telemetryClient = new TelemetryClient(telemetryConfiguration);

  3. Utiliser le client pour envoyer des données de télémétrie personnalisées :

    telemetryClient.TrackEvent("testEvent");

Modifier la télémétrie

Cette section explique comment modifier la télémétrie.

Ajouter des attributs d’étendue

Ces attributs peuvent inclure l’ajout d’une propriété personnalisée à votre télémétrie. Vous pouvez également utiliser des attributs pour définir des champs facultatifs dans le schéma Application Insights, comme une adresse IP de client.

Ajoutez une propriété personnalisée à une étendue

Tous les attributs que vous ajoutez aux étendues sont exportés en tant que propriétés personnalisées. Ils remplissent le champ customDimensions dans la table des requêtes, des dépendances, des traces ou des exceptions.

Pour ajouter des attributs span, utilisez l’une des deux méthodes suivantes :

Conseil

L’avantage de l’utilisation des options fournies par les bibliothèques d’instrumentation, lorsqu’elles sont disponibles, est que tout le contexte est disponible. Par conséquent, les utilisateurs peuvent choisir d’ajouter ou de filtrer davantage d’attributs. Par exemple, l’option enrichir de la bibliothèque d’instrumentation HttpClient permet aux utilisateurs d’accéder au HttpRequestMessage et au HttpResponseMessage eux-mêmes. Ils peuvent sélectionner n’importe quoi et le stocker en tant qu’attribut.

  1. De nombreuses bibliothèques d’instrumentation fournissent une option enrichir. Pour obtenir de l’aide, consultez les fichiers Lisez-moi des bibliothèques d’instrumentation individuelles :

  2. Utilisation d’un processeur personnalisé :

    Conseil

    Ajoutez le processeur indiqué ici avant d’ajouter Azure Monitor.

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

    Ajoutez ActivityEnrichingProcessor.cs à votre projet avec le code ci-dessous :

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

Définir l’IP utilisateur

Vous pouvez renseigner le champ client_IP pour les requêtes en définissant un attribut sur l’étendue. Application Insights utilise l’adresse IP pour générer des attributs d’emplacement utilisateur, puis la supprime par défaut.

Utilisez l’exemple d’ajout d’une propriété personnalisée, mais changez les lignes de code suivantes dans 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>");

Définir manuellement l’ID utilisateur ou l’ID utilisateur authentifié

Vous pouvez remplir le champ user_Id ou user_AuthenticatedId pour les requêtes à l’aide des instructions ci-dessous. L’ID d’utilisateur est un identificateur d’utilisateur anonyme. L’ID d’utilisateur authentifié est un identificateur d’utilisateur connu.

Important

Consultez les lois en vigueur inhérentes à la protection des données personnelles avant de définir l’ID d’utilisateur authentifié.

Utilisez l’exemple d’ajout d’une propriété personnalisée :

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

Ajouter des attributs de journal

OpenTelemetry utilise le ILogger de .NET. Vous pouvez joindre des dimensions personnalisées aux journaux à l’aide d’un modèle de message.

Filtrer les données de télémétrie

Vous pouvez utiliser les méthodes suivantes pour filtrer les données de télémétrie avant qu’elles ne quittent votre application.

  1. De nombreuses bibliothèques d’instrumentation fournissent une option de filtre. Pour obtenir de l’aide, consultez les fichiers Lisez-moi des bibliothèques d’instrumentation individuelles :

  2. Utilisation d’un processeur personnalisé :

    Conseil

    Ajoutez le processeur indiqué ici avant d’ajouter Azure Monitor.

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

    Ajoutez ActivityFilteringProcessor.cs à votre projet avec le code ci-dessous :

    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. Si une source particulière n’est pas explicitement ajoutée à l’aide de AddSource("ActivitySourceName"), alors aucune des activités créées à l’aide de cette source n’est exportée.

Obtenir l’ID de trace ou l’ID d’étendue

Vous pouvez obtenir les Trace ID et Span ID de l’étendue actuellement active en suivant ces étapes.

Notes

Les classes Activity et ActivitySource de l’espace de noms System.Diagnostics représentent les concepts OpenTelemetry de Span et Tracer respectivement. Cela est dû au fait que des parties de l’API de suivi OpenTelemetry sont incorporées directement dans le runtime .NET. Pour plus d’informations, consultez Présentation de l’API de suivi .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();

Étapes suivantes

Forum aux questions

Cette section fournit des réponses aux questions fréquentes.

Qu’est-ce qu’OpenTelemetry ?

C’est une nouvelle norme open source pour l’observabilité. Pour en savoir plus, rendez-vous sur OpenTelemetry.

Pourquoi Microsoft Azure Monitor investit-il dans OpenTelemetry ?

Microsoft fait partie des plus importants contributeurs d’OpenTelemetry.

Les principales propositions de valeur d’OpenTelemetry reposent sur le fait qu’elles sont indépendantes du fournisseur et qu’elles offrent des API/kits SDK cohérents dans tous les langages.

Au fil du temps, nous pensons qu’OpenTelemetry permettra aux clients d’Azure Monitor d’observer des applications écrites dans des langages autres que nos langages pris en charge. Il étend également les types de données que vous pouvez collecter via un ensemble complet de bibliothèques d’instrumentation. En outre, les kits de développement logiciel OpenTelemetry (SDK) ont tendance à être plus performants à grande échelle que leurs prédécesseurs, les kits SDK Application Insights.

Enfin, OpenTelemetry est en phase avec la stratégie de Microsoft qui vise à adopter l’open source.

Quel est l’état d’OpenTelemetry ?

Consultez l’état d’OpenTelemetry.

Qu’est-ce que la « distribution Azure Monitor OpenTelemetry » ?

Vous pouvez le considérer comme un wrapper mince qui regroupe tous les composants OpenTelemetry pour une expérience de première classe sur Azure. Ce wrapper est également appelé une distribution dans OpenTelemetry.

Pourquoi utiliser la « distribution Azure Monitor OpenTelemetry » ?

Il existe plusieurs avantages à utiliser la distribution Azure Monitor OpenTelemetry par rapport à OpenTelemetry natif de la communauté :

Dans l’esprit d’OpenTelemetry, nous avons conçu la distribution pour qu’elle soit ouverte et extensible. Par exemple, vous pouvez ajouter :

  • Un exportateur OTLP (OpenTelemetry Protocol) et l’envoi vers une seconde destination simultanément
  • Autres bibliothèques d’instrumentation non incluses dans la distribution

Étant donné que la distribution fournit une distribution OpenTelemetry, la distribution prend en charge tout ce qui est pris en charge par OpenTelemetry. Par exemple, vous pouvez ajouter d’autres processeurs de télémétrie, exportateurs ou bibliothèques d’instrumentation si OpenTelemetry les prend en charge.

Remarque

La distribution définit l’échantillonneur sur un échantillonneur personnalisé à taux fixe pour Application Insights. Vous pouvez le modifier pour un autre échantillonneur, mais cela peut désactiver certaines des fonctionnalités incluses de la distribution. Pour plus d’informations sur l’échantillonneur pris en charge, consultez la section Activer l’échantillonnage de Configurer Azure Monitor OpenTelemetry.

Pour les langues sans exportateur OpenTelemetry autonome pris en charge, la distribution OpenTelemetry d’Azure Monitor est la seule façon actuellement prise en charge d’utiliser OpenTelemetry avec Azure Monitor. Pour les langues avec un exportateur OpenTelemetry autonome pris en charge, vous avez la possibilité d’utiliser la distribution OpenTelemetry Azure Monitor ou l’exportateur OpenTelemetry autonome approprié en fonction de votre scénario de télémétrie. Pour plus d’informations, consultez Quand dois-je utiliser l’exportateur Azure Monitor OpenTelemetry ?.

Comment tester la distribution Azure Monitor OpenTelemetry ?

Consultez notre documentation sur l’activation pour .NET, Java, JavaScript (Node.js) et Python.

Dois-je utiliser le kit de développement logiciel (SDK) OpenTelemetry ou Application Insights ?

Nous vous recommandons d’utiliser la distribution OpenTelemetry, sauf si vous avez besoin d’une fonctionnalité disponible uniquement avec une prise en charge officielle dans le kit SDK Application Insights.

L’adoption d’OpenTelemetry empêche désormais la migration à une date ultérieure.

Quand utiliser l’exportateur OpenTelemetry Azure Monitor ?

Pour ASP.NET Core, Java, Node.js et Python, nous vous recommandons d’utiliser la distribution OpenTelemetry Azure Monitor. Il s’agit d’une ligne de code pour démarrer.

Pour tous les autres scénarios .NET, notamment les ASP.NET classiques, les applications console, Windows Forms (WinForms), etc., nous vous recommandons d’utiliser l’exportateur .NET Azure Monitor OpenTelemetry : Azure.Monitor.OpenTelemetry.Exporter.

Pour les scénarios de télémétrie Python plus complexes nécessitant une configuration avancée, nous vous recommandons utiliser l’Exportateur Azure Monitor OpenTelemetry.

Quel est l’état de publication actuel des fonctionnalités de la distribution Azure Monitor OpenTelemetry ?

Le graphique suivant présente la prise en charge des fonctionnalités OpenTelemetry pour chaque langage.

Fonctionnalité .NET Node.js Python Java
Traçage distribué ✅ ✅ ✅ ✅
Métriques personnalisées ✅ ✅ ✅ ✅
Métriques standard ✅ ✅ ✅ ✅
Échantillonnage à fréquence fixe ✅ ✅ ✅ ✅
Stockage hors connexion et nouvelles tentatives automatiques ✅ ✅ ✅ ✅
Rapports d’exceptions ✅ ✅ ✅ ✅
Collection de journaux ✅ ⚠️ ✅ ✅
Événements personnalisés ⚠️ ⚠️ ⚠️ ✅
Authentification Microsoft Entra ✅ ✅ ✅ ✅
Métriques temps réel ✅ ✅ ✅ ✅
Filtrage des métriques actives ✅ ❌ ❌ ❌
Détecter le contexte de ressource pour les VM/VMSS et App Service ✅ ❌ ✅ ✅
Détecter le contexte des ressources pour Azure Kubernetes Service (AKS) et Functions ❌ ❌ ❌ ✅
Évènements de test de disponibilité générés en utilisant l’API Suivi de la disponibilité ❌ ❌ ❌ ✅
Filtrer les demandes, dépendances, journaux et exceptions par identificateur d’utilisateur anonyme et source synthétique ❌ ❌ ❌ ✅
Filtrer les dépendances, les journaux et les exceptions par nom d’opération ❌ ❌ ❌ ✅
échantillonnage adaptatif ❌ ❌ ❌ ✅
Profiler ✅ ❌ ❌ ⚠️
Débogueur de capture instantanée ✅ ❌ ❌ ❌

Clé

OpenTelemetry peut-il être utilisé pour les navigateurs web ?

Oui, mais cela n’est pas recommandé ou pris en charge par Azure. OpenTelemetry JavaScript est fortement optimisé pour Node.js. Au lieu de cela, nous vous recommandons d’utiliser le Kit de développement logiciel (SDK) JavaScript Application Insights.

Quand pouvons-nous nous attendre à ce que le Kit de développement logiciel (SDK) OpenTelemetry soit disponible pour être utilisé dans les navigateurs web ?

Le SDK web OpenTelemetry n’a pas de planning de disponibilité défini. Il faudra probablement attendre encore plusieurs années avant qu’un SDK pour navigateur ne constitue une alternative viable au SDK JavaScript d’Application Insights.

Puis-je tester OpenTelemetry dans un navigateur web aujourd’hui ?

Le bac à sable web OpenTelemetry est une duplication (fork) conçue pour permettre à OpenTelemetry de fonctionner dans un navigateur. Il n’est pas encore possible d’envoyer des données de télémétrie à Application Insights. Le SDK ne définit pas d’événements clients d’ordre général.

L’exécution d’Application Insights avec les agents concurrents tels que AppDynamics, DataDog et NewRelic est-elle prise en charge ?

Bien que nos distributions vous permettent d’exporter simultanément vers un point de terminaison OTLP et Azure Monitor, nous ne prévoyons pas de tester ou de prendre en charge cette pratique.

Puis-je utiliser les fonctionnalités d’évaluation dans les environnements de production ?

Nous ne le recommandons pas. Consultez Conditions d’utilisation supplémentaires des Préversions Microsoft Azure.

Quelle est la différence entre une instrumentation manuelle et automatique ?

Consultez la rubrique Présentation d’OpenTelemetry.

Est-il possible d’utiliser le collecteur OpenTelemetry ?

Certains clients utilisent le collecteur OpenTelemetry comme agent de substitution, même si Microsoft ne prend pas encore officiellement en charge une approche basée sur un agent pour la surveillance d’applications. En attendant, la communauté open source a contribué à créer un exportateur Azure Monitor de collecteur OpenTelemetry que certains clients utilisent pour envoyer des données à Azure Monitor Application Insights. Ce n’est pas pris en charge par Microsoft.

Quelle est la différence entre OpenCensus et OpenTelemetry ?

OpenCensus est le précurseur d’OpenTelemetry. Microsoft a contribué à réunir OpenTracing et OpenCensus pour créer OpenTelemetry, une norme d’observabilité unique et disponible à l’échelle mondiale. Le Kit de développement logiciel (SDK) Python actuellement recommandé en production pour Azure Monitor est basé sur OpenCensus. Microsoft s’engage à baser Azure Monitor sur OpenTelemetry.

Dans Grafana, pourquoi est-ce que je vois Status: 500. Can't visualize trace events using the trace visualizer ?

Vous essayez peut-être de visualiser des journaux en texte brut plutôt que des traces OpenTelemetry.

Dans Application Insights, la table « Traces » stocke les journaux en texte brut à des fins de diagnostic. Ils permettent d’identifier et de mettre en corrélation les traces associées aux demandes utilisateur, à d’autres événements et aux rapports d’exceptions. Cependant, la table « Traces » ne contribue pas directement à la vue des transactions de bout en bout (graphique en cascade) dans des outils de visualisation comme Grafana.

Avec l’adoption croissante des pratiques natives cloud, la collecte et la terminologie des données de télémétrie évoluent. OpenTelemetry est désormais la norme pour collecter et instrumenter des données de télémétrie. Dans ce contexte, le terme « Traces » prend un nouveau sens. Au lieu de désigner des journaux bruts, « Traces » dans OpenTelemetry fait référence à une forme de télémétrie plus riche et structurée qui inclut des étendues représentant des unités de travail individuelles. Ces étendues sont essentielles pour construire des vues de transaction détaillées, améliorant ainsi le monitoring et les diagnostics des applications natives cloud.

Dépannage

Étape 1 : activer la journalisation des diagnostics

L’exportateur Azure Monitor utilise EventSource pour sa journalisation interne. Les journaux de l’exportateur sont disponibles pour n’importe quel EventListener en l’abonnant à la source nommée OpenTelemetry-AzureMonitor-Exporter. Pour obtenir les étapes de dépannage, consultez Résolution des problèmes d’OpenTelemetry sur GitHub.

Étape 2 : tester la connectivité entre l’hôte de votre application et le service d’ingestion

Les Kits de développement logiciel (SDK) et les agents Application Insights envoient les données de télémétrie à ingérer en tant qu’appels REST à nos points de terminaison d’ingestion. Pour tester la connectivité entre votre serveur web ou l’ordinateur hôte de votre application et les points de terminaison du service d’ingestion, utilisez des commandes cURL ou des requêtes REST brutes depuis PowerShell. Pour plus d’informations, consultez Résoudre les problèmes de données de télémétrie d’application manquantes dans Azure Monitor Application Insights.

Problèmes connus

Les éléments suivants sont des problèmes connus pour les exportateurs OpenTelemetry Azure Monitor :

  • Le nom de l’opération est manquant dans la télémétrie des dépendances. Le nom d’opération manquant provoque des échecs et affecte négativement l’expérience de l’onglet des performances.

  • Le modèle d’appareil est manquant dans les données de télémétrie de requête et de dépendance. Le modèle d’appareil manquant affecte négativement l’analyse des cohortes d’appareils.

Support

Sélectionnez un onglet correspondant à la langue de votre choix pour découvrir les options de support.

Commentaires OpenTelemetry

Pour fournir des commentaires :