Azure Monitor Exporter n'inclut pas de bibliothèques d'instrumentation.
Demandes
Consommateurs JMS
Consommateurs Kafka
Netty
Quartz
RabbitMQ
Servlets
Planification de Spring
Notes
L’instrumentation automatique Servlet et Netty couvre la majorité des services Java HTTP, notamment Java EE, Jakarta EE, Spring Boot, Quarkus et Micronaut.
Dépendances (avec propagation de trace distribuée en aval)
Apache HttpClient
Apache HttpAsyncClient
AsyncHttpClient
Google HttpClient
gRPC
java.net.HttpURLConnection
Java 11 HttpClient
Client JAX-RS
Jetty HttpClient
JMS
Kafka
Client Netty
OkHttp
RabbitMQ
Dépendances (sans propagation de trace distribuée en aval)
Cassandra
JDBC
MongoDB (asynchrone et synchrone)
Redis (Lettuce et Jedis)
Métriques
Métriques Micrometer, notamment les métriques Spring Boot Actuator
Métriques JMX
Journaux
Logback (y compris les propriétés MDC) ¹ ³
Log4j (y compris les propriétés MDC/Contexte de thread) ¹ ³
Journalisation JBoss (y compris les propriétés MDC) ¹ ³
java.util.logging ¹ ³
Collection par défaut
Les données de télémétrie émises par les SDK Azure suivants sont automatiquement collectées par défaut :
Vous trouverez des exemples d’utilisation de la bibliothèque de journalisation Python sur GitHub.
Les données de télémétrie émises par ces kits de développement logiciel (SDK) Azure sont automatiquement collectées par défaut.
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.
// 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();
// Create a new OpenTelemetry meter provider and add runtime instrumentation and the Azure Monitor metric exporter.
// It is important to keep the MetricsProvider instance active throughout the process lifetime.
var metricsProvider = Sdk.CreateMeterProviderBuilder()
.AddRuntimeInstrumentation()
.AddAzureMonitorMetricExporter();
Vous ne pouvez pas étendre la Distribution Java avec des bibliothèques d’instrumentation de la communauté. Pour nous demander d'inclure une autre bibliothèque d'instrumentation, ouvrez un problème sur notre page GitHub. Vous trouverez un lien vers notre page GitHub dans Étapes suivantes.
Vous ne pouvez pas utiliser de bibliothèques d’instrumentation communautaires avec des applications natives GraalVM Java.
D’autres instrumentations OpenTelemetry sont disponibles ici et peuvent être ajoutées à l’aide de TraceHandler dans ApplicationInsightsClient :
// Import the Azure Monitor OpenTelemetry plugin and OpenTelemetry API
const { useAzureMonitor } = require("@azure/monitor-opentelemetry");
const { metrics, trace, ProxyTracerProvider } = require("@opentelemetry/api");
// Import the OpenTelemetry instrumentation registration function and Express instrumentation
const { registerInstrumentations } = require( "@opentelemetry/instrumentation");
const { ExpressInstrumentation } = require('@opentelemetry/instrumentation-express');
// Get the OpenTelemetry tracer provider and meter provider
const tracerProvider = (trace.getTracerProvider() as ProxyTracerProvider).getDelegate();
const meterProvider = metrics.getMeterProvider();
// Enable Azure Monitor integration
useAzureMonitor();
// Register the Express instrumentation
registerInstrumentations({
// List of instrumentations to register
instrumentations: [
new ExpressInstrumentation(), // Express instrumentation
],
// OpenTelemetry tracer provider
tracerProvider: tracerProvider,
// OpenTelemetry meter provider
meterProvider: meterProvider
});
Pour ajouter une bibliothèque d’instrumentation de la communauté (non prise en charge officiellement/incluse dans la distribution Azure Monitor), vous pouvez instrumenter directement avec les instrumentations. La liste des bibliothèques d’instrumentation de la communauté est disponible ici.
Remarque
Il n’est pas recommandé d’instrumenter manuellement une bibliothèque d’instrumentation prise en charge avec instrument() en lien avec la distribution configure_azure_monitor(). Ce scénario n’est pas pris en charge et vous pouvez obtenir un comportement indésirable pour vos données de télémétrie.
# Import the `configure_azure_monitor()`, `SQLAlchemyInstrumentor`, `create_engine`, and `text` functions from the appropriate packages.
from azure.monitor.opentelemetry import configure_azure_monitor
from opentelemetry.instrumentation.sqlalchemy import SQLAlchemyInstrumentor
from sqlalchemy import create_engine, text
# Configure OpenTelemetry to use Azure Monitor.
configure_azure_monitor()
# Create a SQLAlchemy engine.
engine = create_engine("sqlite:///:memory:")
# SQLAlchemy instrumentation is not officially supported by this package, however, you can use the OpenTelemetry `instrument()` method manually in conjunction with `configure_azure_monitor()`.
SQLAlchemyInstrumentor().instrument(
engine=engine,
)
# Database calls using the SQLAlchemy library will be automatically captured.
with engine.connect() as conn:
result = conn.execute(text("select 'hello world'"))
print(result.all())
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
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.
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"));
public class Program
{
// Create a static readonly Meter object named "OTel.AzureMonitor.Demo".
// This meter will be used to track metrics about the application.
private static readonly Meter meter = new("OTel.AzureMonitor.Demo");
public static void Main()
{
// Create a new MeterProvider object using the OpenTelemetry SDK.
// The MeterProvider object is responsible for managing meters and sending
// metric data to exporters.
// It is important to keep the MetricsProvider instance active
// throughout the process lifetime.
//
// The MeterProviderBuilder is configured to add a meter named
// "OTel.AzureMonitor.Demo" and an Azure Monitor metric exporter.
using var meterProvider = Sdk.CreateMeterProviderBuilder()
.AddMeter("OTel.AzureMonitor.Demo")
.AddAzureMonitorMetricExporter()
.Build();
// Create a new Histogram metric named "FruitSalePrice".
// This metric will track the distribution of fruit sale prices.
Histogram<long> myFruitSalePrice = meter.CreateHistogram<long>("FruitSalePrice");
// Create a new Random object. This object will be used to generate random sale prices.
var rand = new Random();
// Record a few random sale prices for apples and lemons, with different colors.
// Each record includes a timestamp, a value, and a set of attributes.
// The attributes can be used to filter and analyze the metric data.
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"));
// Display a message to the user and wait for them to press Enter.
// This allows the user to see the message and the console before the
// application exits.
System.Console.WriteLine("Press Enter key to exit.");
System.Console.ReadLine();
}
}
import io.opentelemetry.api.GlobalOpenTelemetry;
import io.opentelemetry.api.metrics.DoubleHistogram;
import io.opentelemetry.api.metrics.Meter;
public class Program {
public static void main(String[] args) {
Meter meter = GlobalOpenTelemetry.getMeter("OTEL.AzureMonitor.Demo");
DoubleHistogram histogram = meter.histogramBuilder("histogram").build();
histogram.record(1.0);
histogram.record(100.0);
histogram.record(30.0);
}
}
import io.opentelemetry.api.metrics.DoubleHistogram;
import io.opentelemetry.api.metrics.Meter;
Meter meter = openTelemetry.getMeter("OTEL.AzureMonitor.Demo");
DoubleHistogram histogram = meter.histogramBuilder("histogram").build();
histogram.record(1.0);
histogram.record(100.0);
histogram.record(30.0);
// Import the Azure Monitor OpenTelemetry plugin and OpenTelemetry API
const { useAzureMonitor } = require("@azure/monitor-opentelemetry");
const { metrics } = require("@opentelemetry/api");
// Enable Azure Monitor integration
useAzureMonitor();
// Get the meter for the "testMeter" namespace
const meter = metrics.getMeter("testMeter");
// Create a histogram metric
let histogram = meter.createHistogram("histogram");
// Record values to the histogram metric with different tags
histogram.record(1, { "testKey": "testValue" });
histogram.record(30, { "testKey": "testValue2" });
histogram.record(100, { "testKey2": "testValue" });
# Import the `configure_azure_monitor()` and `metrics` functions from the appropriate packages.
from azure.monitor.opentelemetry import configure_azure_monitor
from opentelemetry import metrics
# 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 a meter provider and a meter with the name "otel_azure_monitor_histogram_demo".
meter = metrics.get_meter_provider().get_meter("otel_azure_monitor_histogram_demo")
# Record three values to the histogram.
histogram = meter.create_histogram("histogram")
histogram.record(1.0, {"test_key": "test_value"})
histogram.record(100.0, {"test_key2": "test_value"})
histogram.record(30.0, {"test_key": "test_value2"})
# Wait for background execution.
input()
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"));
public class Program
{
// Create a static readonly Meter object named "OTel.AzureMonitor.Demo".
// This meter will be used to track metrics about the application.
private static readonly Meter meter = new("OTel.AzureMonitor.Demo");
public static void Main()
{
// Create a new MeterProvider object using the OpenTelemetry SDK.
// The MeterProvider object is responsible for managing meters and sending
// metric data to exporters.
// It is important to keep the MetricsProvider instance active
// throughout the process lifetime.
//
// The MeterProviderBuilder is configured to add a meter named
// "OTel.AzureMonitor.Demo" and an Azure Monitor metric exporter.
using var meterProvider = Sdk.CreateMeterProviderBuilder()
.AddMeter("OTel.AzureMonitor.Demo")
.AddAzureMonitorMetricExporter()
.Build();
// Create a new counter metric named "MyFruitCounter".
// This metric will track the number of fruits sold.
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"));
// Display a message to the user and wait for them to press Enter.
// This allows the user to see the message and the console before the
// application exits.
System.Console.WriteLine("Press Enter key to exit.");
System.Console.ReadLine();
}
}
import io.opentelemetry.api.GlobalOpenTelemetry;
import io.opentelemetry.api.common.AttributeKey;
import io.opentelemetry.api.common.Attributes;
import io.opentelemetry.api.metrics.LongCounter;
import io.opentelemetry.api.metrics.Meter;
public class Program {
public static void main(String[] args) {
Meter meter = GlobalOpenTelemetry.getMeter("OTEL.AzureMonitor.Demo");
LongCounter myFruitCounter = meter
.counterBuilder("MyFruitCounter")
.build();
myFruitCounter.add(1, Attributes.of(AttributeKey.stringKey("name"), "apple", AttributeKey.stringKey("color"), "red"));
myFruitCounter.add(2, Attributes.of(AttributeKey.stringKey("name"), "lemon", AttributeKey.stringKey("color"), "yellow"));
myFruitCounter.add(1, Attributes.of(AttributeKey.stringKey("name"), "lemon", AttributeKey.stringKey("color"), "yellow"));
myFruitCounter.add(2, Attributes.of(AttributeKey.stringKey("name"), "apple", AttributeKey.stringKey("color"), "green"));
myFruitCounter.add(5, Attributes.of(AttributeKey.stringKey("name"), "apple", AttributeKey.stringKey("color"), "red"));
myFruitCounter.add(4, Attributes.of(AttributeKey.stringKey("name"), "lemon", AttributeKey.stringKey("color"), "yellow"));
}
}
// Import the Azure Monitor OpenTelemetry plugin and OpenTelemetry API
const { useAzureMonitor } = require("@azure/monitor-opentelemetry");
const { metrics } = require("@opentelemetry/api");
// Enable Azure Monitor integration
useAzureMonitor();
// Get the meter for the "testMeter" namespace
const meter = metrics.getMeter("testMeter");
// Create a counter metric
let counter = meter.createCounter("counter");
// Add values to the counter metric with different tags
counter.add(1, { "testKey": "testValue" });
counter.add(5, { "testKey2": "testValue" });
counter.add(3, { "testKey": "testValue2" });
# Import the `configure_azure_monitor()` and `metrics` functions from the appropriate packages.
from azure.monitor.opentelemetry import configure_azure_monitor
from opentelemetry import metrics
# 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 a meter provider and a meter with the name "otel_azure_monitor_counter_demo".
meter = metrics.get_meter_provider().get_meter("otel_azure_monitor_counter_demo")
# Create a counter metric with the name "counter".
counter = meter.create_counter("counter")
# Add three values to the counter.
# The first argument to the `add()` method is the value to add.
# The second argument is a dictionary of dimensions.
# Dimensions are used to group related metrics together.
counter.add(1.0, {"test_key": "test_value"})
counter.add(5.0, {"test_key2": "test_value"})
counter.add(3.0, {"test_key": "test_value2"})
# Wait for background execution.
input()
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));
}
}
public class Program
{
// Create a static readonly Meter object named "OTel.AzureMonitor.Demo".
// This meter will be used to track metrics about the application.
private static readonly Meter meter = new("OTel.AzureMonitor.Demo");
public static void Main()
{
// Create a new MeterProvider object using the OpenTelemetry SDK.
// The MeterProvider object is responsible for managing meters and sending
// metric data to exporters.
// It is important to keep the MetricsProvider instance active
// throughout the process lifetime.
//
// The MeterProviderBuilder is configured to add a meter named
// "OTel.AzureMonitor.Demo" and an Azure Monitor metric exporter.
using var meterProvider = Sdk.CreateMeterProviderBuilder()
.AddMeter("OTel.AzureMonitor.Demo")
.AddAzureMonitorMetricExporter()
.Build();
// Get the current process.
var process = Process.GetCurrentProcess();
// 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));
// Display a message to the user and wait for them to press Enter.
// This allows the user to see the message and the console before the
// application exits.
System.Console.WriteLine("Press Enter key to exit.");
System.Console.ReadLine();
}
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));
}
}
}
import io.opentelemetry.api.GlobalOpenTelemetry;
import io.opentelemetry.api.common.AttributeKey;
import io.opentelemetry.api.common.Attributes;
import io.opentelemetry.api.metrics.Meter;
public class Program {
public static void main(String[] args) {
Meter meter = GlobalOpenTelemetry.getMeter("OTEL.AzureMonitor.Demo");
meter.gaugeBuilder("gauge")
.buildWithCallback(
observableMeasurement -> {
double randomNumber = Math.floor(Math.random() * 100);
observableMeasurement.record(randomNumber, Attributes.of(AttributeKey.stringKey("testKey"), "testValue"));
});
}
}
// Import the useAzureMonitor function and the metrics module from the @azure/monitor-opentelemetry and @opentelemetry/api packages, respectively.
const { useAzureMonitor } = require("@azure/monitor-opentelemetry");
const { metrics } = require("@opentelemetry/api");
// Enable Azure Monitor integration.
useAzureMonitor();
// Get the meter for the "testMeter" meter name.
const meter = metrics.getMeter("testMeter");
// Create an observable gauge metric with the name "gauge".
let gauge = meter.createObservableGauge("gauge");
// Add a callback to the gauge metric. The callback will be invoked periodically to generate a new value for the gauge metric.
gauge.addCallback((observableResult: ObservableResult) => {
// Generate a random number between 0 and 99.
let randomNumber = Math.floor(Math.random() * 100);
// Set the value of the gauge metric to the random number.
observableResult.observe(randomNumber, {"testKey": "testValue"});
});
# Import the necessary packages.
from typing import Iterable
from azure.monitor.opentelemetry import configure_azure_monitor
from opentelemetry import metrics
from opentelemetry.metrics import CallbackOptions, Observation
# 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 a meter provider and a meter with the name "otel_azure_monitor_gauge_demo".
meter = metrics.get_meter_provider().get_meter("otel_azure_monitor_gauge_demo")
# Define two observable gauge generators.
# The first generator yields a single observation with the value 9.
# The second generator yields a sequence of 10 observations with the value 9 and a different dimension value for each observation.
def observable_gauge_generator(options: CallbackOptions) -> Iterable[Observation]:
yield Observation(9, {"test_key": "test_value"})
def observable_gauge_sequence(options: CallbackOptions) -> Iterable[Observation]:
observations = []
for i in range(10):
observations.append(
Observation(9, {"test_key": i})
)
return observations
# Create two observable gauges using the defined generators.
gauge = meter.create_observable_gauge("gauge", [observable_gauge_generator])
gauge2 = meter.create_observable_gauge("gauge2", [observable_gauge_sequence])
# Wait for background execution.
input()
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" });
}
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("ExceptionExample");
try
{
// Try to execute some code.
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" });
}
Vous pouvez utiliser opentelemetry-api pour mettre à jour l’état d’une étendue et d’enregistrer des exceptions.
Ajoutez opentelemetry-api-1.0.0.jar (ou version ultérieure) à votre application :
// Import the Azure Monitor OpenTelemetry plugin and OpenTelemetry API
const { useAzureMonitor } = require("@azure/monitor-opentelemetry");
const { trace } = require("@opentelemetry/api");
// Enable Azure Monitor integration
useAzureMonitor();
// Get the tracer for the "testTracer" namespace
const tracer = trace.getTracer("testTracer");
// Start a span with the name "hello"
let span = tracer.startSpan("hello");
// Try to throw an error
try{
throw new Error("Test Error");
}
// Catch the error and record it to the span
catch(error){
span.recordException(error);
}
Le Kit de développement logiciel (SDK) Python OpenTelemetry est implémenté de telle sorte que les exceptions levées soient capturées et enregistrées automatiquement. Consultez l’exemple de code suivant pour obtenir un exemple de ce comportement :
# Import the necessary packages.
from azure.monitor.opentelemetry import configure_azure_monitor
from opentelemetry import trace
# 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 a tracer for the current module.
tracer = trace.get_tracer("otel_azure_monitor_exception_demo")
# Exception events
try:
# Start a new span with the name "hello".
with tracer.start_as_current_span("hello") as span:
# This exception will be automatically recorded
raise Exception("Custom exception message.")
except Exception:
print("Exception raised")
Si vous souhaitez enregistrer manuellement des exceptions, vous pouvez désactiver cette option dans le gestionnaire de contexte et directement utiliser record_exception() comme dans l’exemple suivant :
...
# Start a new span with the name "hello" and disable exception recording.
with tracer.start_as_current_span("hello", record_exception=False) as span:
try:
# Raise an exception.
raise Exception("Custom exception message.")
except Exception as ex:
# Manually record exception
span.record_exception(ex)
...
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.
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.
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.
// Create an OpenTelemetry tracer provider builder.
// It is important to keep the TracerProvider instance active throughout the process lifetime.
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddSource("ActivitySourceName")
.AddAzureMonitorTraceExporter()
.Build();
// Create an activity source named "ActivitySourceName".
var activitySource = new ActivitySource("ActivitySourceName");
// 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
}
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.
Utiliser l’annotation OpenTelemetry
Le moyen le plus simple d’ajouter vos propres étendues consiste à utiliser l’annotation @WithSpan OpenTelemetry.
Les étendues remplissent les tables requests et dependencies dans Application Insights.
Ajoutez opentelemetry-instrumentation-annotations-1.32.0.jar (ou version ultérieure) à votre application :
Par défaut, l’étendue apparaît dans le tableau dependencies avec le type de dépendance InProc.
Pour les méthodes représentant une tâche en arrière-plan non capturée par l’instrumentation automatique, nous vous recommandons d’appliquer l’attribut kind = SpanKind.SERVER à l’annotation @WithSpan pour vous assurer que cela apparaît dans le tableau requests Application Insights.
Utiliser l’API OpenTelemetry
Si la précédente annotation @WithSpan OpenTelemetry ne répond pas à vos besoins, vous pouvez ajouter vos étendues à l’aide de l’API OpenTelemetry.
Ajoutez opentelemetry-api-1.0.0.jar (ou version ultérieure) à votre application :
import io.opentelemetry.api.trace.Tracer;
static final Tracer tracer = openTelemetry.getTracer("com.example");
Créez une étendue, définissez-la comme étendue actuelle, puis terminez-la :
Span span = tracer.spanBuilder("my first span").startSpan();
try (Scope ignored = span.makeCurrent()) {
// do stuff within the context of this
} catch (Throwable t) {
span.recordException(t);
} finally {
span.end();
}
// Import the Azure Monitor OpenTelemetry plugin and OpenTelemetry API
const { useAzureMonitor } = require("@azure/monitor-opentelemetry");
const { trace } = require("@opentelemetry/api");
// Enable Azure Monitor integration
useAzureMonitor();
// Get the tracer for the "testTracer" namespace
const tracer = trace.getTracer("testTracer");
// Start a span with the name "hello"
let span = tracer.startSpan("hello");
// End the span
span.end();
L’API OpenTelemetry peut servir à ajouter vos propres étendues qui apparaissent dans les tableaux requests et dependencies dans Application Insights.
L’exemple de code montre comment utiliser la méthode tracer.start_as_current_span() pour démarrer, rendre l’étendue actuelle et terminer l’étendue dans son contexte.
...
# Import the necessary packages.
from opentelemetry import trace
# Get a tracer for the current module.
tracer = trace.get_tracer(__name__)
# Start a new span with the name "my first span" and make it the current span.
# The "with" context manager starts, makes the span current, and ends the span within it's context
with tracer.start_as_current_span("my first span") as span:
try:
# Do stuff within the context of this span.
# All telemetry generated within this scope will be attributed to this span.
except Exception as ex:
# Record the exception on the span.
span.record_exception(ex)
...
Par défaut, l’étendue apparaît dans le tableau dependencies avec le type de dépendance InProc.
Si votre méthode représente une tâche en arrière-plan qui n’est pas encore capturée par instrumentation automatique, il est recommandé de définir l’attribut kind = SpanKind.SERVER afin qu’il apparaisse dans le tableau requests Application Insights.
...
# Import the necessary packages.
from opentelemetry import trace
from opentelemetry.trace import SpanKind
# Get a tracer for the current module.
tracer = trace.get_tracer(__name__)
# Start a new span with the name "my request span" and the kind set to SpanKind.SERVER.
with tracer.start_as_current_span("my request span", kind=SpanKind.SERVER) as span:
# Do stuff within the context of this span.
...
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.
Il n’est pas possible d’envoyer des données de télémétrie personnalisées avec l’API classique Application Insights en natif Java.
Si vous souhaitez ajouter des événements personnalisés ou accéder à l’API Application Insights, remplacez le package @azure/monitor-opentelemetry par le applicationinsightspackage v3 bêta. Il offre les mêmes méthodes et interfaces, et tous les exemples de code pour @azure/monitor-opentelemetry s’appliquent au package v3 bêta.
// Import the TelemetryClient class from the Application Insights SDK for JavaScript.
const { TelemetryClient } = require("applicationinsights");
// Create a new TelemetryClient instance.
const telemetryClient = new TelemetryClient();
Utilisez ensuite le TelemetryClient pour envoyer des données télémétriques personnalisées :
Événements
// Create an event telemetry object.
let eventTelemetry = {
name: "testEvent"
};
// Send the event telemetry object to Azure Monitor Application Insights.
telemetryClient.trackEvent(eventTelemetry);
Journaux
// Create a trace telemetry object.
let traceTelemetry = {
message: "testMessage",
severity: "Information"
};
// Send the trace telemetry object to Azure Monitor Application Insights.
telemetryClient.trackTrace(traceTelemetry);
Exceptions
// Try to execute a block of code.
try {
...
}
// If an error occurs, catch it and send it to Azure Monitor Application Insights as an exception telemetry item.
catch (error) {
let exceptionTelemetry = {
exception: error,
severity: "Critical"
};
telemetryClient.trackException(exceptionTelemetry);
}
Contrairement à d’autres langages, Python n’a pas de Kit de développement logiciel (SDK) Application Insights. Vous pouvez répondre à tous vos besoins d’analyse avec la distribution OpenTelemetry d’Azure Monitor, à l’exception de l’envoi de customEvents. Jusqu’à ce que l’API des événements OpenTelemetry se stabilise, utilisez l’extension d’événements Azure Monitor avec la distribution OpenTelemetry d’Azure Monitor pour envoyer customEvents à Application Insights.
Utilisez l’API track_event proposée dans l’extension pour envoyer customEvents :
...
from azure.monitor.events.extension import track_event
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
# Use the track_event() api to send custom event telemetry
# Takes event name and custom dimensions
track_event("Test event", {"key1": "value1", "key2": "value2"})
input()
...
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.
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.
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 :
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");
}
}
Pour ajouter des attributs span, utilisez l’une des deux méthodes suivantes :
Avec les options fournies par les bibliothèques d’instrumentation.
Ajout d’un processeur d’étendue personnalisé.
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 lui-même. Ils peuvent sélectionner n’importe quoi et le stocker en tant qu’attribut.
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 :
Ajoutez le processeur indiqué ci-dessous avant Azure Monitor Exporter.
// Create an OpenTelemetry tracer provider builder.
// It is important to keep the TracerProvider instance active throughout the process lifetime.
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
// Add a source named "OTel.AzureMonitor.Demo".
.AddSource("OTel.AzureMonitor.Demo") // Add a new processor named ActivityEnrichingProcessor.
.AddProcessor(new ActivityEnrichingProcessor()) // Add the Azure Monitor trace exporter.
.AddAzureMonitorTraceExporter() // Add the Azure Monitor trace exporter.
.Build();
Ajoutez ActivityEnrichingProcessor.cs à votre projet avec le code ci-dessous :
public class ActivityEnrichingProcessor : BaseProcessor<Activity>
{
// The OnEnd method is called when an activity is finished. This is the ideal place to enrich the activity with additional data.
public override void OnEnd(Activity activity)
{
// Update the activity's display name.
// The updated activity will be available to all processors which are called after this processor.
activity.DisplayName = "Updated-" + activity.DisplayName;
// Set custom tags on the activity.
activity.SetTag("CustomDimension1", "Value1");
activity.SetTag("CustomDimension2", "Value2");
}
}
Vous pouvez utiliser opentelemetry-api pour ajouter des attributs à des étendues.
L’ajout d’un ou de plusieurs attributs d’étendue permet de renseigner le champ customDimensions dans la table requests, dependencies, traces ou exceptions.
Ajoutez opentelemetry-api-1.0.0.jar (ou version ultérieure) à votre application :
...
# Import the necessary packages.
from azure.monitor.opentelemetry import configure_azure_monitor
from opentelemetry import trace
# Create a SpanEnrichingProcessor instance.
span_enrich_processor = SpanEnrichingProcessor()
# 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>",
# Configure the custom span processors to include span enrich processor.
span_processors=[span_enrich_processor],
)
...
Ajoutez SpanEnrichingProcessor à votre projet avec le code ci-dessous :
# Import the SpanProcessor class from the opentelemetry.sdk.trace module.
from opentelemetry.sdk.trace import SpanProcessor
class SpanEnrichingProcessor(SpanProcessor):
def on_end(self, span):
# Prefix the span name with the string "Updated-".
span._name = "Updated-" + span.name
# Add the custom dimension "CustomDimension1" with the value "Value1".
span._attributes["CustomDimension1"] = "Value1"
# Add the custom dimension "CustomDimension2" with the value "Value2".
span._attributes["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.
// 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>");
// 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>");
...
// Import the SemanticAttributes class from the @opentelemetry/semantic-conventions package.
const { SemanticAttributes } = require("@opentelemetry/semantic-conventions");
// Create a new SpanEnrichingProcessor class.
class SpanEnrichingProcessor implements SpanProcessor {
onEnd(span) {
// Set the HTTP_CLIENT_IP attribute on the span to the IP address of the client.
span.attributes[SemanticAttributes.HTTP_CLIENT_IP] = "<IP Address>";
}
}
# Set the `http.client_ip` attribute of the span to the specified IP address.
span._attributes["http.client_ip"] = "<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é.
...
// Import the SemanticAttributes class from the @opentelemetry/semantic-conventions package.
import { SemanticAttributes } from "@opentelemetry/semantic-conventions";
// Create a new SpanEnrichingProcessor class.
class SpanEnrichingProcessor implements SpanProcessor {
onEnd(span: ReadableSpan) {
// Set the ENDUSER_ID attribute on the span to the ID of the user.
span.attributes[SemanticAttributes.ENDUSER_ID] = "<User ID>";
}
}
OpenTelemetry utilise le ILogger de .NET.
Vous pouvez joindre des dimensions personnalisées aux journaux à l’aide d’un modèle de message.
OpenTelemetry utilise le ILogger de .NET.
Vous pouvez joindre des dimensions personnalisées aux journaux à l’aide d’un modèle de message.
Logback, Log4j et java.util.logging sont instrumentés automatiquement. L’attachement de dimensions personnalisées à vos journaux peut s’effectuer des manières suivantes :
Log4j 2.0 MapMessage (une clé MapMessage de "message" est capturée sous forme de message de journal)
La bibliothèque de journalisation Python est instrumentée automatiquement. Vous pouvez lier des dimensions personnalisées à vos journaux en passant un dictionnaire dans l’argument extra de vos journaux :
...
# Create a warning log message with the properties "key1" and "value1".
logger.warning("WARNING: Warning log with properties", extra={"key1": "value1"})
...
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.
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 :
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;
}
}
}
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.
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 :
// Create an OpenTelemetry tracer provider builder.
// It is important to keep the TracerProvider instance active throughout the process lifetime.
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddSource("OTel.AzureMonitor.Demo") // Add a source named "OTel.AzureMonitor.Demo".
.AddProcessor(new ActivityFilteringProcessor()) // Add a new processor named ActivityFilteringProcessor.
.AddAzureMonitorTraceExporter() // Add the Azure Monitor trace exporter.
.Build();
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;
}
}
}
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.
// Import the useAzureMonitor function and the ApplicationInsightsOptions class from the @azure/monitor-opentelemetry package.
const { useAzureMonitor, ApplicationInsightsOptions } = require("@azure/monitor-opentelemetry");
// Import the HttpInstrumentationConfig class from the @opentelemetry/instrumentation-http package.
const { HttpInstrumentationConfig }= require("@opentelemetry/instrumentation-http");
// Import the IncomingMessage and RequestOptions classes from the http and https packages, respectively.
const { IncomingMessage } = require("http");
const { RequestOptions } = require("https");
// Create a new HttpInstrumentationConfig object.
const httpInstrumentationConfig: HttpInstrumentationConfig = {
enabled: true,
ignoreIncomingRequestHook: (request: IncomingMessage) => {
// Ignore OPTIONS incoming requests.
if (request.method === 'OPTIONS') {
return true;
}
return false;
},
ignoreOutgoingRequestHook: (options: RequestOptions) => {
// Ignore outgoing requests with the /test path.
if (options.path === '/test') {
return true;
}
return false;
}
};
// Create a new ApplicationInsightsOptions object.
const config: ApplicationInsightsOptions = {
instrumentationOptions: {
http: {
httpInstrumentationConfig
}
}
};
// Enable Azure Monitor integration using the useAzureMonitor function and the ApplicationInsightsOptions object.
useAzureMonitor(config);
Utiliser un processeur personnalisé. Vous pouvez utiliser un processeur d’étendues personnalisé pour exclure certaines étendues de l’exportation. Pour marquer des étendues à ne pas exporter, définissez leur TraceFlag sur DEFAULT.
Cela exclut le point de terminaison indiqué dans l’exemple Flask suivant :
...
# Import the Flask and Azure Monitor OpenTelemetry SDK libraries.
import flask
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 to your Azure Monitor Application Insights resource.
configure_azure_monitor(
connection_string="<your-connection-string>",
)
# Create a Flask application.
app = flask.Flask(__name__)
# Define a route. Requests sent to this endpoint will not be tracked due to
# flask_config configuration.
@app.route("/ignore")
def ignore():
return "Request received but not tracked."
...
Utiliser un processeur personnalisé. Vous pouvez utiliser un processeur d’étendues personnalisé pour exclure certaines étendues de l’exportation. Pour marquer des étendues à ne pas exporter, définissez leur TraceFlag sur DEFAULT :
...
# Import the necessary libraries.
from azure.monitor.opentelemetry import configure_azure_monitor
from opentelemetry import trace
# 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>",
# Configure the custom span processors to include span filter processor.
span_processors=[span_filter_processor],
)
...
Ajoutez SpanFilteringProcessor à votre projet avec le code ci-dessous :
# Import the necessary libraries.
from opentelemetry.trace import SpanContext, SpanKind, TraceFlags
from opentelemetry.sdk.trace import SpanProcessor
# Define a custom span processor called `SpanFilteringProcessor`.
class SpanFilteringProcessor(SpanProcessor):
# Prevents exporting spans from internal activities.
def on_start(self, span, parent_context):
# Check if the span is an internal activity.
if span._kind is SpanKind.INTERNAL:
# Create a new span context with the following properties:
# * The trace ID is the same as the trace ID of the original span.
# * The span ID is the same as the span ID of the original span.
# * The is_remote property is set to `False`.
# * The trace flags are set to `DEFAULT`.
# * The trace state is the same as the trace state of the original span.
span._context = SpanContext(
span.context.trace_id,
span.context.span_id,
span.context.is_remote,
TraceFlags(TraceFlags.DEFAULT),
span.context.trace_state,
)
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.
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();
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();
Vous pouvez utiliser opentelemetry-api pour obtenir l’ID de trace ou l’ID d’étendue.
Ajoutez opentelemetry-api-1.0.0.jar (ou version ultérieure) à votre application :
Obtenez l’ID de trace et l’ID d’étendue de la requête dans votre code :
// Import the trace module from the OpenTelemetry API.
const { trace } = require("@opentelemetry/api");
// Get the span ID and trace ID of the active span.
let spanId = trace.getActiveSpan().spanContext().spanId;
let traceId = trace.getActiveSpan().spanContext().traceId;
Obtenez l’ID de trace et l’ID d’étendue de la requête dans votre code :
# Import the necessary libraries.
from opentelemetry import trace
# Get the trace ID and span ID of the current span.
trace_id = trace.get_current_span().get_span_context().trace_id
span_id = trace.get_current_span().get_span_context().span_id
Pour installer le package NuGet, recherchez les mises à jour ou affichez les notes de publication, et consultez la page Package NuGet Azure Monitor AspNetCore.
Pour installer le package NuGet, recherchez les mises à jour ou affichez les notes de publication, visitez la page Package NuGet Azure Monitor Exporter.
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 investit dans OpenTelemetry pour les raisons suivantes :
Cette solution est neutre en termes de fournisseur et fournit des API et SDK homogènes 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.
En outre, les kits de développement logiciel (SDK) OpenTelemetry ont tendance à être plus performants à grande échelle que leurs prédécesseurs, les kits de développement logiciel Application Insights.
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.