Cet article décrit les paramètres de configuration de la distribution Azure Monitor OpenTelemetry.
Chaîne de connexion
Dans Application Insights, une chaîne de connexion définit l’emplacement cible pour l’envoi de données de télémétrie, ce qui permet de s’assurer qu’elles atteignent la ressource appropriée pour la surveillance et l’analyse.
Utilisez l’une des trois méthodes suivantes pour configurer la chaîne de connexion :
Ajoutez UseAzureMonitor() au démarrage de votre application, dans votre classe program.cs.
// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);
// Add the OpenTelemetry telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor(options => {
options.ConnectionString = "<Your Connection String>";
});
// Build the ASP.NET Core web application.
var app = builder.Build();
// Start the ASP.NET Core web application.
app.Run();
Si vous définissez la chaîne de connexion à plusieurs emplacements, nous respectons la précédence suivante :
Code
Variable d’environnement
Fichier de configuration
Utilisez l’une des deux méthodes suivantes pour configurer la chaîne de connexion :
Ajoutez l’exportateur Azure Monitor à chaque signal OpenTelemetry au démarrage de l’application.
// Create a new OpenTelemetry tracer provider.
// It is important to keep the TracerProvider instance active throughout the process lifetime.
var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddAzureMonitorTraceExporter(options =>
{
options.ConnectionString = "<Your Connection String>";
});
// Create a new OpenTelemetry meter provider.
// It is important to keep the MetricsProvider instance active throughout the process lifetime.
var metricsProvider = Sdk.CreateMeterProviderBuilder()
.AddAzureMonitorMetricExporter(options =>
{
options.ConnectionString = "<Your Connection String>";
});
// Create a new logger factory.
// It is important to keep the LoggerFactory instance active throughout the process lifetime.
var loggerFactory = LoggerFactory.Create(builder =>
{
builder.AddOpenTelemetry(options =>
{
options.AddAzureMonitorLogExporter(options =>
{
options.ConnectionString = "<Your Connection String>";
});
});
});
// Import the useAzureMonitor function and the AzureMonitorOpenTelemetryOptions class from the @azure/monitor-opentelemetry package.
const { useAzureMonitor, AzureMonitorOpenTelemetryOptions } = require("@azure/monitor-opentelemetry");
// Create a new AzureMonitorOpenTelemetryOptions object.
const options: AzureMonitorOpenTelemetryOptions = {
azureMonitorExporterOptions: {
connectionString: "<your connection string>"
}
};
// Enable Azure Monitor integration using the useAzureMonitor function and the AzureMonitorOpenTelemetryOptions object.
useAzureMonitor(options);
Utilisez l’une des deux méthodes suivantes pour configurer la chaîne de connexion :
# Import the `configure_azure_monitor()` function from the `azure.monitor.opentelemetry` package.
from azure.monitor.opentelemetry import configure_azure_monitor
# Configure OpenTelemetry to use Azure Monitor with the specified connection string.
# Replace `<your-connection-string>` with the connection string of your Azure Monitor Application Insights resource.
configure_azure_monitor(
connection_string="<your-connection-string>",
)
Définir le nom du rôle cloud et l’instance de rôle cloud
Pour les langues prises en charge, Azure Monitor OpenTelemetry Distro détecte automatiquement le contexte de ressource et fournit des valeurs par défaut pour les propriétés Nom de rôle cloud et Instance de rôle cloud de votre composant. Toutefois, vous pouvez remplacer les valeurs par défaut par un élément logique pour votre équipe. La valeur du nom du rôle cloud s’affiche sur la cartographie d’applications en tant que nom sous un nœud.
Définissez le nom du rôle cloud et l’instance de rôle cloud via les attributs Ressource. Le nom du rôle cloud utilise les attributs service.namespace et service.name, mais il retourne à la valeur service.name si service.namespace n’est pas défini. L’instance de rôle cloud utilise la valeur d’attribut service.instance.id. Pour plus d’informations sur les attributs standard pour les ressources, consultez Conventions sémantiques OpenTelemetry.
// Setting role name and role instance
// Create a dictionary of resource attributes.
var resourceAttributes = new Dictionary<string, object> {
{ "service.name", "my-service" },
{ "service.namespace", "my-namespace" },
{ "service.instance.id", "my-instance" }};
// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);
// Add the OpenTelemetry telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry()
.UseAzureMonitor()
// Configure the ResourceBuilder to add the custom resource attributes to all signals.
// Custom resource attributes should be added AFTER AzureMonitor to override the default ResourceDetectors.
.ConfigureResource(resourceBuilder => resourceBuilder.AddAttributes(_testResourceAttributes));
// Build the ASP.NET Core web application.
var app = builder.Build();
// Start the ASP.NET Core web application.
app.Run();
Définissez le nom du rôle cloud et l’instance de rôle cloud via les attributs Ressource. Le nom du rôle cloud utilise les attributs service.namespace et service.name, mais il retourne à la valeur service.name si service.namespace n’est pas défini. L’instance de rôle cloud utilise la valeur d’attribut service.instance.id. Pour plus d’informations sur les attributs standard pour les ressources, consultez Conventions sémantiques OpenTelemetry.
// Setting role name and role instance
// Create a dictionary of resource attributes.
var resourceAttributes = new Dictionary<string, object> {
{ "service.name", "my-service" },
{ "service.namespace", "my-namespace" },
{ "service.instance.id", "my-instance" }};
// Create a resource builder.
var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);
// Create a new OpenTelemetry tracer provider and set the resource builder.
// It is important to keep the TracerProvider instance active throughout the process lifetime.
var tracerProvider = Sdk.CreateTracerProviderBuilder()
// Set ResourceBuilder on the TracerProvider.
.SetResourceBuilder(resourceBuilder)
.AddAzureMonitorTraceExporter();
// Create a new OpenTelemetry meter provider and set the resource builder.
// It is important to keep the MetricsProvider instance active throughout the process lifetime.
var metricsProvider = Sdk.CreateMeterProviderBuilder()
// Set ResourceBuilder on the MeterProvider.
.SetResourceBuilder(resourceBuilder)
.AddAzureMonitorMetricExporter();
// Create a new logger factory and add the OpenTelemetry logger provider with the resource builder.
// It is important to keep the LoggerFactory instance active throughout the process lifetime.
var loggerFactory = LoggerFactory.Create(builder =>
{
builder.AddOpenTelemetry(options =>
{
// Set ResourceBuilder on the Logging config.
options.SetResourceBuilder(resourceBuilder);
options.AddAzureMonitorLogExporter();
});
});
Utiliser le spring.application.name pour des applications image natives Spring Boot
Utiliser le quarkus.application.name pour les applications d’image native de Quarkus
Définissez le nom du rôle cloud et l’instance de rôle cloud via les attributs Ressource. Le nom du rôle cloud utilise les attributs service.namespace et service.name, mais il retourne à la valeur service.name si service.namespace n’est pas défini. L’instance de rôle cloud utilise la valeur d’attribut service.instance.id. Pour plus d’informations sur les attributs standard pour les ressources, consultez Conventions sémantiques OpenTelemetry.
// Import the useAzureMonitor function, the AzureMonitorOpenTelemetryOptions class, the Resource class, and the SemanticResourceAttributes class from the @azure/monitor-opentelemetry, @opentelemetry/resources, and @opentelemetry/semantic-conventions packages, respectively.
const { useAzureMonitor, AzureMonitorOpenTelemetryOptions } = require("@azure/monitor-opentelemetry");
const { Resource } = require("@opentelemetry/resources");
const { SemanticResourceAttributes } = require("@opentelemetry/semantic-conventions");
// Create a new Resource object with the following custom resource attributes:
//
// * service_name: my-service
// * service_namespace: my-namespace
// * service_instance_id: my-instance
const customResource = new Resource({
[SemanticResourceAttributes.SERVICE_NAME]: "my-service",
[SemanticResourceAttributes.SERVICE_NAMESPACE]: "my-namespace",
[SemanticResourceAttributes.SERVICE_INSTANCE_ID]: "my-instance",
});
// Create a new AzureMonitorOpenTelemetryOptions object and set the resource property to the customResource object.
const options: AzureMonitorOpenTelemetryOptions = {
resource: customResource
};
// Enable Azure Monitor integration using the useAzureMonitor function and the AzureMonitorOpenTelemetryOptions object.
useAzureMonitor(options);
Définissez le nom du rôle cloud et l’instance de rôle cloud via les attributs Ressource. Le nom du rôle cloud utilise les attributs service.namespace et service.name, mais il retourne à la valeur service.name si service.namespace n’est pas défini. L’instance de rôle cloud utilise la valeur d’attribut service.instance.id. Pour plus d’informations sur les attributs standard pour les ressources, consultez Conventions sémantiques OpenTelemetry.
Définissez les attributs des ressources à l’aide des variables d’environnement OTEL_RESOURCE_ATTRIBUTES et/ou OTEL_SERVICE_NAME. OTEL_RESOURCE_ATTRIBUTES prend des séries de paires clé-valeur séparées par des virgules. Par exemple, pour définir le nom du rôle cloud sur my-namespace.my-helloworld-service et définir l’instance de rôle cloud sur my-instance, vous pouvez définir OTEL_RESOURCE_ATTRIBUTES et OTEL_SERVICE_NAME comme suit :
Si vous ne définissez pas l’attribut de la ressource service.namespace, vous pouvez également définir le nom du rôle cloud avec uniquement la variable d’environnement OTEL_SERVICE_NAME ou l’attribut de la ressource service.name. Par exemple, pour définir le nom du rôle cloud sur my-helloworld-service et définir l’instance de rôle cloud sur my-instance, vous pouvez définir OTEL_RESOURCE_ATTRIBUTES et OTEL_SERVICE_NAME comme suit :
Vous pouvez activer l’échantillonnage pour réduire votre volume d’ingestion de données, ce qui réduit vos coûts. Azure Monitor fournit un échantillonneur à taux fixe personnalisé qui remplit les événements avec un « ratio d’échantillonnage » qu’Application Insights convertit en ItemCount. L’échantillonneur à taux fixe garantit des expériences et des comptes d’événements précis. L’échantillonneur est conçu pour préserver vos traces entre les services, et il est interopérable avec les anciens Kits de développement logiciel (SDK) d’Application Insights. Pour plus d’informations, consultez En savoir plus sur l’échantillonnage.
Notes
Les métriques et journaux ne sont pas affectés par l’échantillonnage.
L’échantillonneur s’attend à un taux d’échantillonnage compris entre 0 et 1 inclus. Un taux de 0,1 signifie qu’environ 10 % de vos traces sont envoyées.
// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);
// Add the OpenTelemetry telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor(o =>
{
// Set the sampling ratio to 10%. This means that 10% of all traces will be sampled and sent to Azure Monitor.
o.SamplingRatio = 0.1F;
});
// Build the ASP.NET Core web application.
var app = builder.Build();
// Start the ASP.NET Core web application.
app.Run();
L’échantillonneur s’attend à un taux d’échantillonnage compris entre 0 et 1 inclus. Un taux de 0,1 signifie qu’environ 10 % de vos traces sont envoyées.
// Create a new OpenTelemetry tracer provider.
// It is important to keep the TracerProvider instance active throughout the process lifetime.
var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddAzureMonitorTraceExporter(options =>
{
// Set the sampling ratio to 10%. This means that 10% of all traces will be sampled and sent to Azure Monitor.
options.SamplingRatio = 0.1F;
});
À partir de la version 3.4.0, l’échantillonnage à fréquence limitée est disponible et constitue désormais le réglage par défaut. Pour plus d’informations sur l’échantillonnage, consultez Échantillonnage de Java.
L’échantillonneur s’attend à un taux d’échantillonnage compris entre 0 et 1 inclus. Un taux de 0,1 signifie qu’environ 10 % de vos traces sont envoyées.
// Import the useAzureMonitor function and the AzureMonitorOpenTelemetryOptions class from the @azure/monitor-opentelemetry package.
const { useAzureMonitor, AzureMonitorOpenTelemetryOptions } = require("@azure/monitor-opentelemetry");
// Create a new AzureMonitorOpenTelemetryOptions object and set the samplingRatio property to 0.1.
const options: AzureMonitorOpenTelemetryOptions = {
samplingRatio: 0.1
};
// Enable Azure Monitor integration using the useAzureMonitor function and the AzureMonitorOpenTelemetryOptions object.
useAzureMonitor(options);
La fonction configure_azure_monitor() utilise automatiquement ApplicationInsightsSampler pour assurer la compatibilité avec les kits de développement logiciel (SDK) Application Insights et pour échantillonner vos données de télémétrie. La variable d’environnement OTEL_TRACES_SAMPLER_ARG peut servir à spécifier le taux d’échantillonnage, avec une plage valide de 0 à 1, dans laquelle 0 est 0 % et 1 est 100 %.
Une valeur de 0,1 signifie par exemple que 10 % de vos traces sont envoyées.
export OTEL_TRACES_SAMPLER_ARG=0.1
Conseil
Lorsque vous utilisez un échantillonnage à taux/pourcentage fixe et que vous ne savez pas quelle valeur donner au taux d’échantillonnage, commencez à 5 % (c’est-à-dire 0,05 du taux d’échantillonnage) et ajustez le taux en fonction de la justesse des opérations affichées dans les panneaux d’échecs et de performances. Un taux plus élevé entraîne généralement une plus grande précision. Toutefois, l’échantillonnage ANY affecte la précision. Nous vous recommandons donc de générer des alertes sur les métriques OpenTelemetry, lesquelles ne sont pas affectées par l’échantillonnage.
Métriques temps réel
Mesures actives : fournissent un tableau de bord d’analyse en temps réel pour obtenir un aperçu de l’activité et de la performance de l’application.
Les utilisateurs peuvent activer/désactiver les mesures actives lors de la configuration de la distribution à l’aide de la propriété enableLiveMetrics.
Activer l’authentification Microsoft Entra ID (anciennement Azure AD)
Vous pouvez activer l’authentification Microsoft Entra pour une connexion plus sécurisée à Azure, ce qui empêche l’ingestion de données de télémétrie non autorisées dans votre abonnement.
Fournissez la classe d’informations d’identification souhaitée :
// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);
// Add the OpenTelemetry telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor(options => {
// Set the Azure Monitor credential to the DefaultAzureCredential.
// This credential will use the Azure identity of the current user or
// the service principal that the application is running as to authenticate
// to Azure Monitor.
options.Credential = new DefaultAzureCredential();
});
// Build the ASP.NET Core web application.
var app = builder.Build();
// Start the ASP.NET Core web application.
app.Run();
Nous prenons en charge les classes d’informations d’identification fournies par Identité Azure.
Nous vous recommandons DefaultAzureCredential pour le développement local.
Nous vous recommandons ManagedIdentityCredential pour les identités managées attribuées par le système et par l'utilisateur.
Pour l’affectation par le système, utilisez le constructeur par défaut sans paramètres.
Pour la valeur assignée à l’utilisateur, fournissez l’ID client au constructeur.
Nous vous recommandons ClientSecretCredential pour les principaux de service.
Indiquez l’ID de locataire, l’ID client et la clé secrète client au constructeur.
Fournissez la classe d’informations d’identification souhaitée :
// Create a DefaultAzureCredential.
var credential = new DefaultAzureCredential();
// Create a new OpenTelemetry tracer provider and set the credential.
// It is important to keep the TracerProvider instance active throughout the process lifetime.
var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddAzureMonitorTraceExporter(options =>
{
options.Credential = credential;
});
// Create a new OpenTelemetry meter provider and set the credential.
// It is important to keep the MetricsProvider instance active throughout the process lifetime.
var metricsProvider = Sdk.CreateMeterProviderBuilder()
.AddAzureMonitorMetricExporter(options =>
{
options.Credential = credential;
});
// Create a new logger factory and add the OpenTelemetry logger provider with the credential.
// It is important to keep the LoggerFactory instance active throughout the process lifetime.
var loggerFactory = LoggerFactory.Create(builder =>
{
builder.AddOpenTelemetry(options =>
{
options.AddAzureMonitorLogExporter(options =>
{
options.Credential = credential;
});
});
});
L’authentification Microsoft Entra ID est non disponible pour les applications GraalVM Native.
Nous prenons en charge les classes d’informations d’identification fournies par Identité Azure.
// Import the useAzureMonitor function, the AzureMonitorOpenTelemetryOptions class, and the ManagedIdentityCredential class from the @azure/monitor-opentelemetry and @azure/identity packages, respectively.
const { useAzureMonitor, AzureMonitorOpenTelemetryOptions } = require("@azure/monitor-opentelemetry");
const { ManagedIdentityCredential } = require("@azure/identity");
// Create a new ManagedIdentityCredential object.
const credential = new ManagedIdentityCredential();
// Create a new AzureMonitorOpenTelemetryOptions object and set the credential property to the credential object.
const options: AzureMonitorOpenTelemetryOptions = {
azureMonitorExporterOptions: {
credential: credential
}
};
// Enable Azure Monitor integration using the useAzureMonitor function and the AzureMonitorOpenTelemetryOptions object.
useAzureMonitor(options);
# Import the `ManagedIdentityCredential` class from the `azure.identity` package.
from azure.identity import ManagedIdentityCredential
# Import the `configure_azure_monitor()` function from the `azure.monitor.opentelemetry` package.
from azure.monitor.opentelemetry import configure_azure_monitor
# Configure OpenTelemetry to use Azure Monitor with a managed identity credential.
# This will allow OpenTelemetry to authenticate to Azure Monitor without requiring you to provide a connection string.
configure_azure_monitor(
credential=ManagedIdentityCredential(),
)
Stockage hors connexion et nouvelles tentatives automatiques
Pour améliorer la fiabilité et la résilience, les offres Azure Monitor basées sur OpenTelemetry écrivent dans un stockage hors connexion/local par défaut lorsqu’une application perd sa connexion avec Application Insights. Il enregistre la télémétrie de l’application pendant 48 heures et tente régulièrement de l’envoyer à nouveau. Dans les applications à charge élevée, la télémétrie est parfois supprimée pour deux raisons. Tout d’abord, lorsque la durée autorisée est dépassée, et ensuite, lorsque la taille maximale du fichier est dépassée ou que le kit de développement logiciel (SDK) n’a pas la possibilité d’effacer le fichier. Si nous devons choisir, le produit enregistre les événements les plus récents sur les anciens. En savoir plus
Le package Distro inclus AzureMonitorExporter qui utilise l’un des emplacements suivants par défaut pour le stockage hors connexion (répertorié dans l’ordre de priorité) :
Windows
%LOCALAPPDATA%\Microsoft\AzureMonitor
%TEMP%\Microsoft\AzureMonitor
Non-Windows
%TMPDIR%/Microsoft/AzureMonitor
/var/tmp/Microsoft/AzureMonitor
/tmp/Microsoft/AzureMonitor
Pour remplacer le répertoire par défaut, vous devez définir AzureMonitorOptions.StorageDirectory.
// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);
// Add the OpenTelemetry telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor(options =>
{
// Set the Azure Monitor storage directory to "C:\\SomeDirectory".
// This is the directory where the OpenTelemetry SDK will store any telemetry data that cannot be sent to Azure Monitor immediately.
options.StorageDirectory = "C:\\SomeDirectory";
});
// Build the ASP.NET Core web application.
var app = builder.Build();
// Start the ASP.NET Core web application.
app.Run();
Pour désactiver cette fonctionnalité, vous devez définir AzureMonitorOptions.DisableOfflineStorage = true.
Par défaut, AzureMonitorExporter utilise l’un des emplacements suivants pour le stockage hors connexion (répertorié dans l’ordre de priorité) :
Windows
%LOCALAPPDATA%\Microsoft\AzureMonitor
%TEMP%\Microsoft\AzureMonitor
Non-Windows
%TMPDIR%/Microsoft/AzureMonitor
/var/tmp/Microsoft/AzureMonitor
/tmp/Microsoft/AzureMonitor
Pour remplacer le répertoire par défaut, vous devez définir AzureMonitorExporterOptions.StorageDirectory.
// Create a new OpenTelemetry tracer provider and set the storage directory.
// It is important to keep the TracerProvider instance active throughout the process lifetime.
var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddAzureMonitorTraceExporter(options =>
{
// Set the Azure Monitor storage directory to "C:\\SomeDirectory".
// This is the directory where the OpenTelemetry SDK will store any trace data that cannot be sent to Azure Monitor immediately.
options.StorageDirectory = "C:\\SomeDirectory";
});
// Create a new OpenTelemetry meter provider and set the storage directory.
// It is important to keep the MetricsProvider instance active throughout the process lifetime.
var metricsProvider = Sdk.CreateMeterProviderBuilder()
.AddAzureMonitorMetricExporter(options =>
{
// Set the Azure Monitor storage directory to "C:\\SomeDirectory".
// This is the directory where the OpenTelemetry SDK will store any metric data that cannot be sent to Azure Monitor immediately.
options.StorageDirectory = "C:\\SomeDirectory";
});
// Create a new logger factory and add the OpenTelemetry logger provider with the storage directory.
// It is important to keep the LoggerFactory instance active throughout the process lifetime.
var loggerFactory = LoggerFactory.Create(builder =>
{
builder.AddOpenTelemetry(options =>
{
options.AddAzureMonitorLogExporter(options =>
{
// Set the Azure Monitor storage directory to "C:\\SomeDirectory".
// This is the directory where the OpenTelemetry SDK will store any log data that cannot be sent to Azure Monitor immediately.
options.StorageDirectory = "C:\\SomeDirectory";
});
});
});
Pour désactiver cette fonctionnalité, vous devez définir AzureMonitorExporterOptions.DisableOfflineStorage = true.
La configuration du stockage hors connexion et des nouvelles tentatives automatiques n’est pas disponible dans Java.
Pour obtenir la liste complète des configurations disponibles, consultez Options de configuration.
La configuration du stockage hors connexion et des nouvelles tentatives automatiques n’est pas disponible dans les applications image natives Java.
Par défaut, AzureMonitorExporter utilise l’un des emplacements suivants pour le stockage hors connexion.
Windows
%TEMP%\Microsoft\AzureMonitor
Non-Windows
%TMPDIR%/Microsoft/AzureMonitor
/var/tmp/Microsoft/AzureMonitor
Pour remplacer le répertoire par défaut, vous devez définir storageDirectory.
Par exemple :
// Import the useAzureMonitor function and the AzureMonitorOpenTelemetryOptions class from the @azure/monitor-opentelemetry package.
const { useAzureMonitor, AzureMonitorOpenTelemetryOptions } = require("@azure/monitor-opentelemetry");
// Create a new AzureMonitorOpenTelemetryOptions object and set the azureMonitorExporterOptions property to an object with the following properties:
//
// * connectionString: The connection string for your Azure Monitor Application Insights resource.
// * storageDirectory: The directory where the Azure Monitor OpenTelemetry exporter will store telemetry data when it is offline.
// * disableOfflineStorage: A boolean value that specifies whether to disable offline storage.
const options: AzureMonitorOpenTelemetryOptions = {
azureMonitorExporterOptions: {
connectionString: "<Your Connection String>",
storageDirectory: "C:\\SomeDirectory",
disableOfflineStorage: false
}
};
// Enable Azure Monitor integration using the useAzureMonitor function and the AzureMonitorOpenTelemetryOptions object.
useAzureMonitor(options);
Pour désactiver cette fonctionnalité, vous devez définir disableOfflineStorage = true.
Par défaut, les exportateurs Azure Monitor utilisent le chemin d’accès suivant :
Pour remplacer le répertoire par défaut, vous devez définir storage_directory sur le répertoire souhaité.
Par exemple :
...
# Configure OpenTelemetry to use Azure Monitor with the specified connection string and storage directory.
# Replace `your-connection-string` with the connection string to your Azure Monitor Application Insights resource.
# Replace `C:\\SomeDirectory` with the directory where you want to store the telemetry data before it is sent to Azure Monitor.
configure_azure_monitor(
connection_string="your-connection-string",
storage_directory="C:\\SomeDirectory",
)
...
Pour désactiver cette fonctionnalité, vous devez définir disable_offline_storage sur True. La valeur par défaut est False.
Par exemple :
...
# Configure OpenTelemetry to use Azure Monitor with the specified connection string and disable offline storage.
# Replace `your-connection-string` with the connection string to your Azure Monitor Application Insights resource.
configure_azure_monitor(
connection_string="your-connection-string",
disable_offline_storage=True,
)
...
Activer l’exportateur OTLP
Vous pouvez activer OpenTelemetry Protocol (OTLP) Exporter en plus du Azure Monitor Exporter pour envoyer vos données de télémétrie à deux emplacements.
Notes
OTLP Exporter est illustré pour des raisons pratiques uniquement. Nous ne prenons pas officiellement en charge OTLP Exporter ni les composants ou les expériences tierces qui en découlent.
Ajoutez l’extrait de code suivant : Cet exemple suppose que vous disposez d’un OpenTelemetry Collector avec un récepteur OTLP en cours d’exécution. Pour plus d’informations, consultez l' exemple relatif à GitHub.
// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);
// Add the OpenTelemetry telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();
// Add the OpenTelemetry OTLP exporter to the application.
// This exporter will send telemetry data to an OTLP receiver, such as Prometheus
builder.Services.AddOpenTelemetry().WithTracing(builder => builder.AddOtlpExporter());
builder.Services.AddOpenTelemetry().WithMetrics(builder => builder.AddOtlpExporter());
// Build the ASP.NET Core web application.
var app = builder.Build();
// Start the ASP.NET Core web application.
app.Run();
Ajoutez l’extrait de code suivant : Cet exemple suppose que vous disposez d’un OpenTelemetry Collector avec un récepteur OTLP en cours d’exécution. Pour plus d’informations, consultez l' exemple relatif à GitHub.
// Create a new OpenTelemetry tracer provider and add the Azure Monitor trace exporter and the OTLP trace exporter.
// It is important to keep the TracerProvider instance active throughout the process lifetime.
var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddAzureMonitorTraceExporter()
.AddOtlpExporter();
// Create a new OpenTelemetry meter provider and add the Azure Monitor metric exporter and the OTLP metric exporter.
// It is important to keep the MetricsProvider instance active throughout the process lifetime.
var metricsProvider = Sdk.CreateMeterProviderBuilder()
.AddAzureMonitorMetricExporter()
.AddOtlpExporter();
Vous pouvez activer l’exportateur OpenTelemetry Protocol (OTLP), en plus de l’exportateur Azure Monitor, pour envoyer vos données de télémétrie à deux emplacements.
Ajoutez l’extrait de code suivant : Cet exemple suppose que vous disposez d’un OpenTelemetry Collector avec un récepteur OTLP en cours d’exécution. Pour plus d’informations, consultez l' exemple relatif à GitHub.
// Import the useAzureMonitor function, the AzureMonitorOpenTelemetryOptions class, the trace module, the ProxyTracerProvider class, the BatchSpanProcessor class, the NodeTracerProvider class, and the OTLPTraceExporter class from the @azure/monitor-opentelemetry, @opentelemetry/api, @opentelemetry/sdk-trace-base, @opentelemetry/sdk-trace-node, and @opentelemetry/exporter-trace-otlp-http packages, respectively.
const { useAzureMonitor, AzureMonitorOpenTelemetryOptions } = require("@azure/monitor-opentelemetry");
const { BatchSpanProcessor } = require('@opentelemetry/sdk-trace-base');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');
// Create a new OTLPTraceExporter object.
const otlpExporter = new OTLPTraceExporter();
// Enable Azure Monitor integration.
const options: AzureMonitorOpenTelemetryOptions = {
// Add the SpanEnrichingProcessor
spanProcessors: [new BatchSpanProcessor(otlpExporter)]
}
useAzureMonitor(options);
Ajoutez l’extrait de code suivant : Cet exemple suppose que vous disposez d’un OpenTelemetry Collector avec un récepteur OTLP en cours d’exécution. Pour plus d’informations, consultez ce fichier Lisez-moi.
# Import the `configure_azure_monitor()`, `trace`, `OTLPSpanExporter`, and `BatchSpanProcessor` classes from the appropriate packages.
from azure.monitor.opentelemetry import configure_azure_monitor
from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace.export import BatchSpanProcessor
# Configure OpenTelemetry to use Azure Monitor with the specified connection string.
# Replace `<your-connection-string>` with the connection string to your Azure Monitor Application Insights resource.
configure_azure_monitor(
connection_string="<your-connection-string>",
)
# Get the tracer for the current module.
tracer = trace.get_tracer(__name__)
# Create an OTLP span exporter that sends spans to the specified endpoint.
# Replace `http://localhost:4317` with the endpoint of your OTLP collector.
otlp_exporter = OTLPSpanExporter(endpoint="http://localhost:4317")
# Create a batch span processor that uses the OTLP span exporter.
span_processor = BatchSpanProcessor(otlp_exporter)
# Add the batch span processor to the tracer provider.
trace.get_tracer_provider().add_span_processor(span_processor)
# Start a new span with the name "test".
with tracer.start_as_current_span("test"):
print("Hello world!")
Configurations OpenTelemetry
Les configurations OpenTelemetry suivantes sont accessibles via des variables d’environnement lors de l’utilisation des distributions Azure Monitor OpenTelemetry.
Copiez-le dans la chaîne de connexion à partir de votre ressource Application Insights.
APPLICATIONINSIGHTS_STATSBEAT_DISABLED
Définissez-le sur true pour refuser la collecte de métriques interne.
OTEL_RESOURCE_ATTRIBUTES
Paires clé-valeur à utiliser comme attributs de ressource. Pour plus d’informations sur les attributs de ressource, consultez la spécification du SDK de ressources.
OTEL_SERVICE_NAME
Définit la valeur de l’attribut de ressource service.name. Si la valeur service.name est également fournie dans OTEL_RESOURCE_ATTRIBUTES, OTEL_SERVICE_NAME est alors prioritaire.
Variable d’environnement
Description
APPLICATIONINSIGHTS_CONNECTION_STRING
Copiez-le dans la chaîne de connexion à partir de votre ressource Application Insights.
APPLICATIONINSIGHTS_STATSBEAT_DISABLED
Définissez-le sur true pour refuser la collecte de métriques interne.
OTEL_RESOURCE_ATTRIBUTES
Paires clé-valeur à utiliser comme attributs de ressource. Pour plus d’informations sur les attributs de ressource, consultez la spécification du SDK de ressources.
OTEL_SERVICE_NAME
Définit la valeur de l’attribut de ressource service.name. Si la valeur service.name est également fournie dans OTEL_RESOURCE_ATTRIBUTES, OTEL_SERVICE_NAME est alors prioritaire.
Pour plus d’informations sur la configuration du kit de développement logiciel (SDK) OpenTelemetry, consultez la documentation relative à OpenTelemetry.
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.
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é :
Réduit l’effort d’activation
Prise en charge par Microsoft
Intègre des fonctionnalités spécifiques à Azure, telles que :
L’échantillonnage compatible avec les kits SDK Application Insights classiques
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 ?
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.
❌ Cette fonctionnalité n’est pas disponible ou n’est pas applicable.
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 ?
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 ?
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.
É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.
É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.
Étape 1 : activer la journalisation des diagnostics
É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
Si vous téléchargez la bibliothèque de client Application Insights pour effectuer une installation depuis un navigateur, le fichier JAR téléchargé est parfois endommagé et sa taille est d’environ la moitié de celle du fichier source. Si vous rencontrez ce problème, téléchargez le fichier JAR en exécutant la commande curl ou wget, comme illustré dans les exemples d’appels de commande suivants :
Les exemples d’appels de commande s’appliquent à Application Insights pour Java version 3.4.11. Pour trouver le numéro de version et l’adresse URL de la version actuelle d’Application Insights pour Java, consultez https://github.com/microsoft/ApplicationInsights-Java/releases.
Les étapes suivantes s’appliquent aux applications natives Spring Boot.
Étape 1 : vérifier la version d’OpenTelemetry
Vous remarquerez peut-être le message suivant au démarrage de l’application :
WARN c.a.m.a.s.OpenTelemetryVersionCheckRunner - The OpenTelemetry version is not compatible with the spring-cloud-azure-starter-monitor dependency.
The OpenTelemetry version should be <version>
Dans ce cas, vous devez importer la nomenclature d’OpenTelemetry en suivant la documentation OpenTelemetry dans le starter Spring Boot.
Étape 2 : activer les auto-diagnostics
Si quelque chose ne fonctionne pas comme attendu, vous pouvez activer les auto-diagnostics au niveau DEBUG pour obtenir des insights. Pour ce faire, définissez le niveau d’auto-diagnostic sur ERROR, WARN, INFO, DEBUG ou TRACE en utilisant la variable d’environnement APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL.
Pour activer les auto-diagnostics au niveau DEBUG lors de l’exécution d’un conteneur Docker, exécutez la commande suivante :
docker run -e APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL=DEBUG <image-name>
Remarque
Remplacez <image-name> par le nom de l’image Docker approprié.
Exclusion de responsabilité de tiers
Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.
Étape 1 : activer la journalisation des diagnostics
L’exportateur Azure Monitor utilise l’enregistreur de l’API OpenTelemetry pour les journaux internes. Pour activer l’enregistreur, exécutez l’extrait de code suivant :
É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.
Le nom du serveur de base de données est manquant dans le nom de la dépendance. Comme le nom du serveur de base de données n’est pas inclus, les exportateurs OpenTelemetry agrègent incorrectement les tables qui ont le même nom sur différents serveurs.
Étape 1 : activer la journalisation des diagnostics
L’exportateur Microsoft Azure Monitor utilise la bibliothèque de journalisation standard Python pour sa journalisation interne. Pour une activité anormale, le niveau de gravité WARNING ou ERROR est affecté aux journaux de l’API OpenTelemetry et de l’exportateur Azure Monitor. Le niveau de gravité INFO est utilisé pour une activité normale ou réussie.
Par défaut, la bibliothèque de journalisation Python définit le niveau de gravité sur WARNING. Par conséquent, vous devez changer le niveau de gravité pour voir les journaux avec ce paramètre de gravité. L’exemple suivant montre comment envoyer les journaux de tous les niveaux de gravité vers la console et dans un fichier :
É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.
Étape 3 : éviter les données de télémétrie en doublon
Des données de télémétrie en doublon sont souvent provoquées par la création de plusieurs instances de processeurs ou d’exportateurs. Veillez à exécuter un seul exportateur et un seul processeur à la fois pour chaque pilier de télémétrie (les journaux, les métriques et le suivi distribué).
Les sections suivantes décrivent les scénarios qui peuvent provoquer des données de télémétrie en doublon.
Journaux de suivi en doublon dans Azure Functions
Si vous voyez une paire d’entrées pour chaque journal de suivi dans Application Insights, c’est que vous avez probablement activé les types d’instrumentation de journalisation suivants :
L’instrumentation de journalisation native dans Azure Functions
L’instrumentation de journalisation azure-monitor-opentelemetry dans la distribution
Pour éviter la duplication, vous pouvez désactiver la journalisation de la distribution, mais laisser activée l’instrumentation de journalisation native dans Azure Functions. Pour ce faire, définissez la variable d’environnement OTEL_LOGS_EXPORTER sur None.
Données de télémétrie en doublon dans Azure Functions « Always On »
Si le paramètre Always On dans Azure Functions est défini sur Activé, Azure Functions conserve certains processus en cours d’exécution en arrière-plan une fois chaque exécution terminée. Par exemple, supposons que vous avez une fonction de minuteur de cinq minutes qui appelle chaque fois configure_azure_monitor. Après 20 minutes, vous pouvez avoir quatre exportateurs de métriques qui s’exécutent en même temps. Cette situation peut être la raison de la duplication de vos données de télémétrie de métriques.
Dans ce cas, définissez le paramètre Always On sur Désactivé ou essayez en arrêtant manuellement les fournisseurs entre chaque appel configure_azure_monitor. Pour arrêter chaque fournisseur, exécutez des appels d’arrêt pour chaque fournisseur de compteur, de traceur et d’enregistreur, comme illustré dans le code suivant :
Les classeurs Azure et les notebooks Jupyter peuvent conserver des processus d’exportateur en cours d’exécution en arrière-plan. Pour éviter les données de télémétrie en doublon, effacez le cache avant d’effectuer d’autres appels à configure_azure_monitor.
Étape 4 : vérifier que les données des requêtes Flask sont collectées
Si vous implémentez une application Flask, vous pouvez constater que vous ne pouvez pas collecter les données de la table des requêtes depuis Application Insights pendant que vous utilisez la bibliothèque de client de la distribution OpenTelemetry Azure Monitor pour Python. Ce problème peut se produire si vous ne structurez pas correctement vos déclarations import. Vous importez peut-être le framework d’application web flask.Flask avant d’appeler la fonction configure_azure_monitor pour instrumenter la bibliothèque Flask. Par exemple, le code suivant n’instrumente pas correctement l’application Flask :
from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask
configure_azure_monitor()
app = Flask(__name__)
Au lieu de cela, nous vous recommandons d’importer le module flask dans son ensemble, puis d’appeler configure_azure_monitor afin de configurer OpenTelemetry pour qu’il utilise Azure Monitor avant d’accéder à flask.Flask :
from azure.monitor.opentelemetry import configure_azure_monitor
import flask
configure_azure_monitor()
app = flask.Flask(__name__)
Vous pouvez aussi appeler configure_azure_monitor avant d’importer flask.Flask :
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
from flask import Flask
app = Flask(__name__)
Support
Sélectionnez un onglet correspondant à la langue de votre choix pour découvrir les options de support.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.