Este artigo fornece diretrizes sobre como adicionar, modificar e filtrar o OpenTelemetry para aplicativos usando o Application Insights do Azure Monitor.
O Exportador do Azure Monitor não inclui nenhuma biblioteca de instrumentação.
Solicitações
Consumidores JMS
Consumidores do Kafka
Netty
Quartz
RabbitMQ
Servlets
Agendamento do Spring
Observação
A instrumentação automática do Servlet e Netty abrange a maioria dos serviços HTTP Java, incluindo Java EE, Jakarta EE, Spring Boot, Quarkus e Micronaut.
Dependências (mais a propagação de rastreamento distribuída downstream)
Apache HttpClient
Apache HttpAsyncClient
AsyncHttpClient
Google HttpClient
gRPC
java.net.HttpURLConnection
Java 11 HttpClient
Cliente JAX-RS
Jetty HttpClient
JMS
Kafka
Cliente Netty
OkHttp
RabbitMQ
Dependências (sem a propagação de rastreamento distribuído downstream)
Cassandra
JDBC
MongoDB (assíncrono e síncrono)
Redis (Lettuce e Jedis)
Métricas
Métricas do micrômetro, incluindo as métricas do acionador do Spring Boot
Métricas JMX
Logs
Logback (incluindo propriedades do MDC) ¹ ³
Log4j (incluindo propriedades do MDC/contexto de thread) ¹ ³
Registro em log JBoss (incluindo propriedades do MDC) ¹ ³
java.util.logging ¹ ³
Coleção padrão
A telemetria emitida pelos seguintes SDKs do Azure é coletada automaticamente por padrão:
As seguintes bibliotecas de Instrumentação do OpenTelemetry estão incluídas como parte da Distribuição do Application Insights do Azure Monitor. Para obter mais informações, confira SDK do Azure para JavaScript.
Os exemplos de uso da biblioteca de registro em log do Python podem ser encontrados no GitHub.
A telemetria emitida por esses SDKs do Azure é coletada automaticamente por padrão.
Notas de rodapé
¹: dá suporte a relatórios automáticos de exceções não tratadas/não detectadas
²: dá suporte a métricas do OpenTelemetry
³: por padrão, o registro em log só é coletado no nível INFO ou superior. Para alterar essa configuração, consulte as opções de configuração.
⁴: por padrão, o registro em log só é coletado quando esse registro em log é executado no nível WARNING ou superior.
Observação
As Distribuições do OpenTelemetry do Azure Monitor incluem mapeamento personalizado e lógica para emitir automaticamente métricas padrão do Application Insights.
Dica
Todas as métricas do OpenTelemetry, sejam coletadas automaticamente de bibliotecas de instrumentação ou coletadas manualmente da codificação personalizada, atualmente são consideradas "métricas personalizadas" do Application Insights para fins de cobrança. Saiba mais.
Adicionar uma biblioteca de instrumentação da comunidade
Você pode coletar mais dados automaticamente quando incluir as bibliotecas de instrumentação da comunidade OpenTelemetry.
Cuidado
Não damos suporte nem garantimos a qualidade das bibliotecas de instrumentação da comunidade. Para sugerir uma para nossa distribuição, faça uma postagem ou vote a favor em nossa comunidade de comentários. Lembre-se de que algumas são baseadas em especificações experimentais do OpenTelemetry e podem introduzir futuras alterações interruptivas.
Para adicionar uma biblioteca de comunidade, use os métodos ConfigureOpenTelemetryMeterProvider ou ConfigureOpenTelemetryTracerProvider depois de adicionar o pacote NuGet à biblioteca.
O exemplo a seguir demonstra como a Instrumentação do Runtime pode ser adicionada para coletar métricas adicionais:
// 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();
O exemplo a seguir demonstra como a Instrumentação do Runtime pode ser adicionada para coletar métricas adicionais:
// 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();
Você não pode estender a Distribuição Java com as bibliotecas de instrumentação de comunidade. Para solicitar a inclusão de outra biblioteca de instrumentação, abra uma problema em nossa página do GitHub. Você pode encontrar um link para a nossa página do GitHub nas Próximas etapas.
Você não pode usar as bibliotecas de instrumentação da comunidade com aplicativos nativos de GraalVM Java.
Outras Instrumentações do OpenTelemetry estão disponíveis aqui e podem ser adicionadas usando o TraceHandler no 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
});
Para adicionar uma biblioteca de instrumentação da comunidade (sem suporte oficial/incluído na distribuição do Azure Monitor), você pode instrumentar diretamente com as instrumentações. A lista de bibliotecas de instrumentação da comunidade pode ser encontrada aqui.
Observação
Não é recomendável instrumentar uma biblioteca de instrumentação com suporte manualmente com instrument() em conjunto com a distribuição configure_azure_monitor(). Esse não é um cenário com suporte e você pode obter um comportamento indesejado para sua telemetria.
# 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())
Coletar telemetria personalizada
Esta seção explica como coletar telemetria personalizada do aplicativo.
Dependendo do idioma e do tipo de sinal, há diferentes maneiras de coletar telemetria personalizada, incluindo:
A seguinte tabela representa os tipos de telemetria personalizada com suporte no momento:
Idioma
Eventos personalizados
Métricas personalizadas
Dependências
Exceções
Visualizações de página
Requests
Rastreamentos
ASP.NET Core
API do OpenTelemetry
Sim
Sim
Sim
Yes
ILogger API
Sim
API clássica de IA
Java
API do OpenTelemetry
Sim
Sim
Sim
Yes
Logback, Log4j, JUL
Sim
Sim
Métricas do Micrometer
Sim
API clássica de IA
Yes
Sim
Sim
Sim
Sim
Sim
Sim
Node.js
API do OpenTelemetry
Sim
Sim
Sim
Sim
Python
API do OpenTelemetry
Sim
Sim
Sim
Sim
Módulo de registro em log do Python
Sim
Extensão de eventos
Sim
Sim
Observação
O Java 3.x d Application Insights escuta a telemetria enviada para a API Clássica do Application Insights. Da mesma forma, o Node.js 3.x do Application Insights coleta eventos criados com a API Clássica do Application Insights. Isso facilita o upgrade e preenche uma lacuna em nosso suporte de telemetria personalizada até que todos os tipos de telemetria personalizada tenham suporte por meio da API OpenTelemetry.
Adicionar métricas personalizadas
Nesse contexto, as métricas personalizadas referem-se a instrumentar manualmente seu código para coletar métricas adicionais além do que as Bibliotecas de Instrumentação OpenTelemetry coletam automaticamente.
A API do OpenTelemetry oferece seis “instrumentos” métricos para cobrir vários cenários métricos e você precisa escolher o “Tipo de Agregação” correto ao visualizar as métricas no Metrics Explorer. Esse requisito é válido ao usar a API de Métrica do OpenTelemetry para enviar métricas e ao usar uma biblioteca de instrumentação.
A tabela a seguir mostra os tipos de agregação recomendados para cada um dos Instrumentos de Métrica do OpenTelemetry.
Instrumento do OpenTelemetry
Tipo de agregação do Azure Monitor
Contador
Somar
Contador assíncrono
Somar
Histograma
Min, Max, Average, Sum e Count
Medidor assíncrono
Média
UpDownCounter
Somar
UpDownCounter assíncrono
Somar
Cuidado
Normalmente, os tipos de agregação além dos mostrados na tabela são irrelevantes.
O histograma é o mais versátil e o mais equivalente à API Clássica de GetMetric do Application Insights. Atualmente, o Azure Monitor nivela o instrumento de histograma em nossos cinco tipos de agregação com suporte e o suporte para percentis está em andamento. Embora menos versáteis, outros instrumentos do OpenTelemetry têm um impacto menor no desempenho do aplicativo.
A inicialização do aplicativo deve assinar um Medidor pelo nome:
// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);
// Configure the OpenTelemetry meter provider to add a meter named "OTel.AzureMonitor.Demo".
builder.Services.ConfigureOpenTelemetryMeterProvider((sp, builder) => builder.AddMeter("OTel.AzureMonitor.Demo"));
// Add the Azure Monitor telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();
// Build the ASP.NET Core web application.
var app = builder.Build();
// Start the ASP.NET Core web application.
app.Run();
O Meter deve ser inicializado usando esse mesmo nome:
// Create a new meter named "OTel.AzureMonitor.Demo".
var meter = new Meter("OTel.AzureMonitor.Demo");
// Create a new histogram metric named "FruitSalePrice".
Histogram<long> myFruitSalePrice = meter.CreateHistogram<long>("FruitSalePrice");
// Create a new Random object.
var rand = new Random();
// Record a few random sale prices for apples and lemons, with different colors.
myFruitSalePrice.Record(rand.Next(1, 1000), new("name", "apple"), new("color", "red"));
myFruitSalePrice.Record(rand.Next(1, 1000), new("name", "lemon"), new("color", "yellow"));
myFruitSalePrice.Record(rand.Next(1, 1000), new("name", "lemon"), new("color", "yellow"));
myFruitSalePrice.Record(rand.Next(1, 1000), new("name", "apple"), new("color", "green"));
myFruitSalePrice.Record(rand.Next(1, 1000), new("name", "apple"), new("color", "red"));
myFruitSalePrice.Record(rand.Next(1, 1000), new("name", "lemon"), new("color", "yellow"));
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()
A inicialização do aplicativo deve assinar um Medidor pelo nome:
// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);
// Configure the OpenTelemetry meter provider to add a meter named "OTel.AzureMonitor.Demo".
builder.Services.ConfigureOpenTelemetryMeterProvider((sp, builder) => builder.AddMeter("OTel.AzureMonitor.Demo"));
// Add the Azure Monitor telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();
// Build the ASP.NET Core web application.
var app = builder.Build();
// Start the ASP.NET Core web application.
app.Run();
O Meter deve ser inicializado usando esse mesmo nome:
// Create a new meter named "OTel.AzureMonitor.Demo".
var meter = new Meter("OTel.AzureMonitor.Demo");
// Create a new counter metric named "MyFruitCounter".
Counter<long> myFruitCounter = meter.CreateCounter<long>("MyFruitCounter");
// Record the number of fruits sold, grouped by name and color.
myFruitCounter.Add(1, new("name", "apple"), new("color", "red"));
myFruitCounter.Add(2, new("name", "lemon"), new("color", "yellow"));
myFruitCounter.Add(1, new("name", "lemon"), new("color", "yellow"));
myFruitCounter.Add(2, new("name", "apple"), new("color", "green"));
myFruitCounter.Add(5, new("name", "apple"), new("color", "red"));
myFruitCounter.Add(4, new("name", "lemon"), new("color", "yellow"));
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()
A inicialização do aplicativo deve assinar um Medidor pelo nome:
// Create a new ASP.NET Core web application builder.
var builder = WebApplication.CreateBuilder(args);
// Configure the OpenTelemetry meter provider to add a meter named "OTel.AzureMonitor.Demo".
builder.Services.ConfigureOpenTelemetryMeterProvider((sp, builder) => builder.AddMeter("OTel.AzureMonitor.Demo"));
// Add the Azure Monitor telemetry service to the application.
// This service will collect and send telemetry data to Azure Monitor.
builder.Services.AddOpenTelemetry().UseAzureMonitor();
// Build the ASP.NET Core web application.
var app = builder.Build();
// Start the ASP.NET Core web application.
app.Run();
O Meter deve ser inicializado usando esse mesmo nome:
// Get the current process.
var process = Process.GetCurrentProcess();
// Create a new meter named "OTel.AzureMonitor.Demo".
var meter = new Meter("OTel.AzureMonitor.Demo");
// Create a new observable gauge metric named "Thread.State".
// This metric will track the state of each thread in the current process.
ObservableGauge<int> myObservableGauge = meter.CreateObservableGauge("Thread.State", () => GetThreadState(process));
private static IEnumerable<Measurement<int>> GetThreadState(Process process)
{
// Iterate over all threads in the current process.
foreach (ProcessThread thread in process.Threads)
{
// Create a measurement for each thread, including the thread state, process ID, and thread ID.
yield return new((int)thread.ThreadState, new("ProcessId", process.Id), new("ThreadId", thread.Id));
}
}
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()
Adicionar exceções personalizadas
Selecione as bibliotecas de instrumentação para reportar automaticamente as exceções ao Application Insights.
No entanto, convém relatar manualmente exceções além daquelas relatadas nas bibliotecas de instrumentação.
Por exemplo, as exceções capturadas pelo código não são relatadas normalmente. Talvez você queira relatá-las para chamar a atenção para experiências relevantes, incluindo a seção de falhas e exibições de transação de ponta a ponta.
// 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);
}
}
Para registrar uma exceção usando o 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" });
}
Para registrar uma exceção usando uma atividade:
// 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);
}
}
Para registrar uma exceção usando o 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" });
}
Você pode usar opentelemetry-api para atualizar o status de um intervalo e registrar as exceções.
Adicione opentelemetry-api-1.0.0.jar (ou posterior) ao seu aplicativo:
// Import the Azure Monitor OpenTelemetry plugin and OpenTelemetry API
const { useAzureMonitor } = require("@azure/monitor-opentelemetry");
const { trace, SpanKind } = 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", {
kind: SpanKind.SERVER
});
// 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);
}
O SDK do Python do OpenTelemetry é implementado de tal forma que as exceções lançadas são automaticamente capturadas e registradas. Veja o código de exemplo a seguir para obter um exemplo desse comportamento:
# 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")
Se desejar registrar exceções manualmente, desabilite essa opção no gerenciador de contexto e use record_exception() diretamente, conforme mostrado no exemplo a seguir:
...
# 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)
...
Adicionar intervalos personalizados
Talvez você queira adicionar um intervalo personalizado em dois cenários. Primeiro, quando há uma solicitação de dependência que ainda não foi coletada por uma biblioteca de instrumentação. Segundo, quando você deseja modelar um processo de inscrição como uma extensão da exibição de transações de ponta a ponta.
As classes Activity e ActivitySource do namespace System.Diagnostics representam os conceitos Span e Tracer do OpenTelemetry, respectivamente. Você cria ActivitySource diretamente usando o construtor dele em vez de usar TracerProvider. Cada classe ActivitySource deve ser conectada explicitamente ao TracerProvider usando AddSource(). Isso ocorre porque partes da API de rastreamento do OpenTelemetry são incorporadas diretamente no runtime do .NET. Para saber mais, confira Introdução à API de rastreamento do OpenTelemetry .NET.
// 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 tem ActivityKind.Internal como padrão, mas você pode fornecer qualquer outro ActivityKind.
ActivityKind.Client, ActivityKind.Producer e ActivityKind.Internal são mapeados para o Application Insights dependencies.
ActivityKind.Server e ActivityKind.Consumer são mapeados para o Application Insights requests.
Observação
As classes Activity e ActivitySource do namespace System.Diagnostics representam os conceitos Span e Tracer do OpenTelemetry, respectivamente. Você cria ActivitySource diretamente usando o construtor dele em vez de usar TracerProvider. Cada classe ActivitySource deve ser conectada explicitamente ao TracerProvider usando AddSource(). Isso ocorre porque partes da API de rastreamento do OpenTelemetry são incorporadas diretamente no runtime do .NET. Para saber mais, confira Introdução à API de rastreamento do OpenTelemetry .NET.
// 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 tem ActivityKind.Internal como padrão, mas você pode fornecer qualquer outro ActivityKind.
ActivityKind.Client, ActivityKind.Producer e ActivityKind.Internal são mapeados para o Application Insights dependencies.
ActivityKind.Server e ActivityKind.Consumer são mapeados para o Application Insights requests.
Usar a anotação OpenTelemetry
A maneira mais simples de adicionar os seus próprios intervalos é usando a anotação @WithSpan do OpenTelemetry.
Os intervalos preenchem as tabelas requests e dependencies no Application Insights.
Adicione opentelemetry-instrumentation-annotations-1.32.0.jar (ou posterior) ao seu aplicativo:
Por padrão, o intervalo acaba na tabela dependencies com o tipo de dependência InProc.
Para métodos que representam um trabalho em segundo plano não capturado pela instrumentação automática, recomendamos aplicar o atributo kind = SpanKind.SERVER à anotação @WithSpan para garantir que eles apareçam na tabela requests do Application Insights.
Usar a API OpenTelemetry
Se a anotação @WithSpan do OpenTelemetry acima não atender às suas necessidades, adicione seus intervalos usando a API do OpenTelemetry.
Adicione opentelemetry-api-1.0.0.jar (ou posterior) ao seu aplicativo:
import io.opentelemetry.api.trace.Tracer;
static final Tracer tracer = openTelemetry.getTracer("com.example");
Crie um intervalo, torne-o atual e, em seguida, encerre-o:
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();
A API do OpenTelemetry pode ser usada para adicionar seus próprios intervalos, que aparecem nas tabelas requests e dependencies no Application Insights.
O exemplo de código mostra como usar o método tracer.start_as_current_span() para iniciar, tornar o intervalo atual e terminar o intervalo dentro de seu contexto.
...
# 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)
...
Por padrão, o intervalo está na tabela dependencies com um tipo de dependência de InProc.
Se seu método representar um trabalho em segundo plano que ainda não foi capturado pela instrumentação automática, recomendamos definir o atributo kind = SpanKind.SERVER para garantir que ele apareça na tabela requests do 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.
...
Enviar telemetria personalizada usando a API Clássica do Application Insights
Recomendamos que você use as APIs OpenTelemetry sempre que possível, mas pode haver alguns cenários em que você precise usar as API Clássica do Application Insights.
Não é possível enviar telemetria personalizada usando a API Clássica do Application Insights em Java native.
Se você quiser adicionar eventos personalizados ou acessar a API do Application Insights, substitua o pacote @azure/monitor-opentelemetry pelo applicationinsightspacote v3 Beta. Ele oferece os mesmos métodos e interfaces e todo o código de exemplo para @azure/monitor-opentelemetry aplica-se ao pacote v3 Beta.
// Import the TelemetryClient class from the Application Insights SDK for JavaScript.
const { TelemetryClient } = require("applicationinsights");
// Create a new TelemetryClient instance.
const telemetryClient = new TelemetryClient();
Use o TelemetryClient para enviar a telemetria personalizada:
Eventos
// Create an event telemetry object.
let eventTelemetry = {
name: "testEvent"
};
// Send the event telemetry object to Azure Monitor Application Insights.
telemetryClient.trackEvent(eventTelemetry);
Logs
// Create a trace telemetry object.
let traceTelemetry = {
message: "testMessage",
severity: "Information"
};
// Send the trace telemetry object to Azure Monitor Application Insights.
telemetryClient.trackTrace(traceTelemetry);
Exceções
// 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);
}
Ao contrário de outras linguagens, o Python não tem um SDK do Application Insights. Você pode atender a todas as suas necessidades de monitoramento com a Distribuição OpenTelemetry do Azure Monitor, exceto para enviar customEvents. Até que a API de Eventos OpenTelemetry se estabilize, use a Extensão de eventos do Azure Monitor com a Distribuição OpenTelemetry do Azure Monitor para enviar customEvents ao Application Insights.
Use a API track_event oferecida na extensão para enviar 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()
...
Modificar telemetria
Esta seção explica como modificar a telemetria.
Adicionar atributos de intervalo
Esses atributos podem incluir a adição de uma propriedade personalizada à telemetria. Você também pode usar atributos para definir campos opcionais no esquema do Application Insights, como IP do Cliente.
Adicionar uma propriedade personalizada a um intervalo
Todos os atributos adicionados aos intervalos são exportados como propriedades personalizadas. Elas preenchem o campo customDimensions na tabela de solicitações, dependências, rastreamentos ou exceções.
Adicione um processador de intervalo personalizado.
Dica
A vantagem de usar as opções fornecidas pelas bibliotecas de instrumentação, quando disponíveis, é que todo o contexto fica disponível. Assim, os usuários podem optar por adicionar ou filtrar mais atributos. Por exemplo, a opção enriquecer na biblioteca de instrumentação do HttpClient dá aos usuários acesso ao HttpRequestMessage e ao próprio HttpResponseMessage. Eles podem selecionar qualquer coisa nela e armazenar como um atributo.
Muitas bibliotecas de instrumentação fornecem uma opção de enriquecimento. Para obter diretrizes, confira os arquivos Leiame das bibliotecas de instrumentação individuais:
Adicione o processador mostrado aqui antes de adicionar o 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();
Adicione ActivityEnrichingProcessor.cs ao seu projeto com o seguinte código:
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");
}
}
Adicione atributos de intervalo de uma destas maneiras:
Use as opções fornecidas pelas bibliotecas de instrumentação.
Adicione um processador de intervalo personalizado.
Dica
A vantagem de usar as opções fornecidas pelas bibliotecas de instrumentação, quando disponíveis, é que todo o contexto fica disponível. Assim, os usuários podem optar por adicionar ou filtrar mais atributos. Por exemplo, a opção enriquecer na biblioteca de instrumentação do HttpClient dá aos usuários acesso à httpRequestMessage. Eles podem selecionar qualquer coisa nela e armazenar como um atributo.
Muitas bibliotecas de instrumentação fornecem uma opção de enriquecimento. Para obter diretrizes, confira os arquivos Leiame das bibliotecas de instrumentação individuais:
Adicione o processador mostrado aqui antes do Exportador do Azure Monitor.
// 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();
Adicione ActivityEnrichingProcessor.cs ao seu projeto com o seguinte código:
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");
}
}
Você pode usar opentelemetry-api para adicionar atributos a intervalos.
Adicionar um ou mais atributos de intervalo preenche o campo customDimensions na tabela requests, dependencies, traces ou exceptions.
Adicione opentelemetry-api-1.0.0.jar (ou posterior) ao seu aplicativo:
...
# 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],
)
...
Adicione SpanEnrichingProcessor ao seu projeto com o seguinte código:
# 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"
Definir o IP do usuário
Você pode popular o campo client_IP para solicitações definindo um atributo no intervalo. A Application Insights usa o endereço IP para gerar atributos de localização do usuário e, em seguida, o descarta por padrão.
// 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>"
Definir a ID do usuário ou a ID do usuário autenticado
Você pode preencher o campo user_Id ou user_AuthenticatedId para solicitações usando as diretrizes a seguir. A ID do usuário é um identificador de usuário anônimo. A ID do usuário autenticado é um identificador de usuário conhecido.
Importante
Veja as leis de privacidade aplicáveis antes de configurar a ID de Usuário autenticado.
...
// 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>";
}
}
A biblioteca de registro em log do Python é instrumentada automaticamente. É possível anexar dimensões personalizadas aos seus logs passando um dicionário para o argumento extra de seus logs:
...
# Create a warning log message with the properties "key1" and "value1".
logger.warning("WARNING: Warning log with properties", extra={"key1": "value1"})
...
Filtrar telemetria
Use as maneiras a seguir de filtrar a telemetria antes que ela saia do aplicativo.
Muitas bibliotecas de instrumentação fornecem uma opção de filtro. Para obter diretrizes, confira os arquivos Leiame das bibliotecas de instrumentação individuais:
Adicione o processador mostrado aqui antes de adicionar o 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();
Adicione ActivityFilteringProcessor.cs ao seu projeto com o seguinte código:
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;
}
}
}
Se uma fonte específica não for explicitamente adicionada usando AddSource("ActivitySourceName"), nenhuma das atividades criadas usando essa fonte será exportada.
Muitas bibliotecas de instrumentação fornecem uma opção de filtro. Para obter diretrizes, confira os arquivos Leiame das bibliotecas de instrumentação individuais:
// 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();
Adicione ActivityFilteringProcessor.cs ao seu projeto com o seguinte código:
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;
}
}
}
Se uma fonte específica não for explicitamente adicionada usando AddSource("ActivitySourceName"), nenhuma das atividades criadas usando essa fonte será exportada.
// 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);
Use um processador personalizado. Você pode usar um processador de span personalizado para excluir determinadas extensões de serem exportadas. Para marcar intervalos para que não sejam exportados, defina TraceFlag como DEFAULT.
Isso exclui o ponto de extremidade mostrado no exemplo de Flask a seguir:
...
# 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."
...
Use um processador personalizado. Você pode usar um processador de span personalizado para excluir determinadas extensões de serem exportadas. Para marcar intervalos para que não sejam exportados, defina TraceFlag como 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],
)
...
Adicione SpanFilteringProcessor ao seu projeto com o seguinte código:
# 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,
)
Obter a ID de rastreamento ou a ID do intervalo
Você pode obter a Trace ID e a Span ID do Intervalo ativo atualmente usando as etapas a seguir.
As classes Activity e ActivitySource do namespace System.Diagnostics representam os conceitos Span e Tracer do OpenTelemetry, respectivamente. Isso ocorre porque partes da API de rastreamento do OpenTelemetry são incorporadas diretamente no runtime do .NET. Para saber mais, confira Introdução à API de rastreamento do OpenTelemetry .NET.
// 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();
Observação
As classes Activity e ActivitySource do namespace System.Diagnostics representam os conceitos Span e Tracer do OpenTelemetry, respectivamente. Isso ocorre porque partes da API de rastreamento do OpenTelemetry são incorporadas diretamente no runtime do .NET. Para saber mais, confira Introdução à API de rastreamento do OpenTelemetry .NET.
// 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();
Você pode usar opentelemetry-api para obter a ID de rastreamento ou a ID de intervalo.
Adicione opentelemetry-api-1.0.0.jar (ou posterior) ao seu aplicativo:
Obtenha a ID de rastreamento de solicitação e a ID de intervalo em seu código:
// 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;
Obtenha a ID de rastreamento de solicitação e a ID de intervalo em seu código:
# 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
Esta seção fornece respostas para perguntas comuns.
O que é o OpenTelemetry?
É um novo padrão de código aberto para observabilidade. Saiba mais em OpenTelemetry.
Por que o Microsoft Azure Monitor está investindo no OpenTelemetry?
A Microsoft está investindo no OpenTelemetry pelos seguintes motivos:
É neutro em relação a fornecedores e fornece APIs/SDKs consistentes entre diferentes linguagens.
Ao longo do tempo, acreditamos que o OpenTelemetry permitirá que os clientes do Azure Monitor observem os aplicativos escritos em linguagens além das nossas linguagens com suporte.
Ele expande os tipos de dados que podem ser coletados por meio de um conjunto avançado de bibliotecas de instrumentação.
Os Kits de Desenvolvimento de Software (SDKs) do OpenTelemetry tendem a ser mais eficientes em grande escala do que seus predecessores, os SDKs do Application Insights.
O que é a Distribuição OpenTelemetry do Azure Monitor?
Você pode pensar nela como um wrapper fino que reúne todos os componentes do OpenTelemetry para uma experiência de primeira classe no Azure. Esse wrapper também é chamado de distribuição no OpenTelemetry.
Por que devo usar a Distribuição OpenTelemetry do Azure Monitor?
Há várias vantagens em usar a Distribuição OpenTelemetry do Azure Monitor em relação ao OpenTelemetry nativo da comunidade:
Reduz o esforço da habilitação
Compatível com a Microsoft
Inclui recursos específicos do Azure, como:
Amostragem compatível com os SDKs clássicos do Application Insights
No espírito do OpenTelemetry, projetamos a distribuição para ser aberta e extensível. Por exemplo, você pode adicionar:
Um exportador do Protocolo OpenTelemetry (OTLP) e enviar para um segundo destino simultaneamente
Outras bibliotecas de instrumentação não incluídas na distribuição
Como a Distribuição oferece uma distribuição do OpenTelemetry, ela suporta tudo o que é suportado pelo OpenTelemetry. Por exemplo, você pode adicionar mais processadores de telemetria, exportadores ou bibliotecas de instrumentação se o OpenTelemetry der suporte a eles.
Observação
A Distribuição define o amostrador para um amostrador personalizado de taxa fixa para o Application Insights. Você pode alterar isso para um amostrador diferente, mas fazê-lo pode desabilitar alguns dos recursos incluídos na Distribuição.
Para obter mais informações sobre o amostrador com suporte, consulte a seção Habilitar Amostragem de Configurar o OpenTelemetry do Azure Monitor.
Para idiomas sem um exportador autônomo do OpenTelemetry com suporte, a Distribuição do OpenTelemetry para Azure Monitor é atualmente a única maneira com suporte para usar o OpenTelemetry com o Azure Monitor. Para idiomas com um exportador autônomo do OpenTelemetry com suporte, você tem a opção de usar tanto a Distribuição do OpenTelemetry do Azure Monitor quanto o exportador autônomo apropriado do OpenTelemetry, dependendo do seu cenário de telemetria. Para obter mais informações, consulte Quando devo usar o exportador do OpenTelemetry do Azure Monitor?.
Como posso testar a Distribuição OpenTelemetry do Azure Monitor?
A adoção do OpenTelemetry agora impede a migração em uma data posterior.
Quando devo usar a o exportador do OpenTelemetry do Azure Monitor?
No caso do ASP.NET Core, do Java, do Node.js e do Python, recomendamos usar a Distribuição do OpenTelemetry para Azure Monitor. Basta uma linha de código para começar.
Para todos os outros cenários de .NET, incluindo ASP.NET clássico, aplicativos de console, Windows Forms (WinForms) etc., recomendamos o uso do exportador OpenTelemetry do Azure Monitor para .NET: Azure.Monitor.OpenTelemetry.Exporter.
❌ Esse recurso não está disponível ou não é aplicável.
O OpenTelemetry pode ser usado para navegadores da Web?
Sim, mas não recomendamos e o Azure não dá suporte a ele. O Javascript do OpenTelemetry é altamente otimizado para Node.js. Nesse caso, recomendamos usar o SDK do JavaScript do Application Insights.
Quando podemos esperar que o SDK do OpenTelemetry esteja disponível para uso em navegadores da Web?
O SDK da Web do OpenTelemetry não tem uma linha do tempo de disponibilidade determinada. Deve demorar alguns anos para algum SDK de navegador ser uma alternativa viável ao SDK do JavaScript do Application Insights.
Posso testar o OpenTelemetry em um navegador da Web hoje?
A área restrita Web do OpenTelemetry é uma bifurcação projetada para fazer o OpenTelemetry funcionar em um navegador. Ainda não é possível enviar telemetria para o Application Insights. O SDK não define eventos gerais do cliente.
Há suporte para a execução do Application Insights junto com agentes concorrentes, como o AppDynamics, DataDog e NewRelic?
Essa prática não é algo que planejamos testar ou oferecer suporte, embora nossas distribuições permitam que você exporte para um ponto de extremidade OTLP junto com o Azure Monitor simultaneamente.
Posso usar versão prévia do recurso em ambientes de produção?
Alguns clientes usam o Coletor do OpenTelemetry como uma alternativa de agente, embora a Microsoft ainda não dê suporte oficial a uma abordagem baseada em agente para o monitoramento de aplicativos. Enquanto isso, a comunidade de código aberto contribuiu com um Exportador do Azure Monitor para o Coletor do OpenTelemetry, que alguns clientes estão usando para enviar dados para o Application Insights do Azure Monitor. Isso não tem suporte da Microsoft.
Qual é a diferença entre o OpenCensus e o OpenTelemetry?
O OpenCensus é o precursor do OpenTelemetry. A Microsoft ajudou a reunir o OpenTracing e o OpenCensus para criar o OpenTelemetry, um padrão de observabilidade exclusivo para o mundo. O SDK do Python recomendado para produção atual para o Azure Monitor é baseado no OpenCensus. A Microsoft está comprometida em dar suporte ao OpenTelemetry no Azure Monitor.
No Grafana, por que estou vendo Status: 500. Can't visualize trace events using the trace visualizer?
Você pode estar tentando visualizar logs de texto bruto em vez de rastreamentos do OpenTelemetry.
No Application Insights, a tabela "Traces" armazena logs de texto bruto para fins de diagnóstico. Eles ajudam a identificar e correlacionar rastreamentos associados a solicitações de usuários, outros eventos e relatórios de exceções. No entanto, a tabela "Traces" não contribui diretamente para a visualização da transação de ponta a ponta (gráfico em cascata) em ferramentas de visualização como o Grafana.
Com a crescente adoção de práticas nativas da nuvem, há uma evolução na coleta e na terminologia de telemetria. OpenTelemetry tornou-se um padrão para coleta e instrumentação de dados de telemetria. Nesse contexto, o termo "Traços" ganhou um novo significado. Em vez de logs brutos, 'Traces' no OpenTelemetry referem-se a uma forma de telemetria mais rica e estruturada que inclui spans, que representam unidades individuais de trabalho. Esses intervalos são cruciais para a construção de visualizações detalhadas de transações, permitindo melhor monitoramento e diagnóstico de aplicativos nativos da nuvem.
O Exportador do Azure Monitor usa EventSource para seu log interno. Os logs do exportador estão disponíveis para qualquer EventListener aceitando a origem chamada OpenTelemetry-AzureMonitor-Exporter. Para obter as etapas de solução de problemas, consulte Solução de problemas do OpenTelemetry no GitHub.
Etapa 2: Testar a conectividade entre o host do aplicativo e o serviço de ingestão
Os SDKs e agentes do Application Insights enviam telemetria para serem ingeridos como chamadas REST em nossos pontos de extremidade de ingestão. Para testar a conectividade do servidor Web ou do computador host do aplicativo com os pontos de extremidade do serviço de ingestão, use comandos cURL ou solicitações REST brutas do PowerShell. Para obter mais informações, consulte Solucionar problemas de telemetria de aplicativo ausente no Application Insights do Azure Monitor.
Problemas conhecidos
Os seguintes itens são problemas conhecidos para os exportadores do OpenTelemetry do Azure Monitor:
O nome da operação está ausente da telemetria de dependência. O nome da operação ausente causa falhas e afeta negativamente a experiência da guia de desempenho.
O modelo do dispositivo está ausente da telemetria de solicitação e dependência. O modelo de dispositivo ausente afeta negativamente a análise de coorte de dispositivos.
Etapa 1: Habilitar o log de diagnóstico
O Exportador do Azure Monitor usa EventSource para seu log interno. Os logs do exportador estão disponíveis para qualquer EventListener aceitando a origem chamada OpenTelemetry-AzureMonitor-Exporter. Para obter as etapas de solução de problemas, consulte Solução de problemas do OpenTelemetry no GitHub.
Etapa 2: Testar a conectividade entre o host do aplicativo e o serviço de ingestão
Os SDKs e agentes do Application Insights enviam telemetria para serem ingeridos como chamadas REST em nossos pontos de extremidade de ingestão. Para testar a conectividade do servidor Web ou do computador host do aplicativo com os pontos de extremidade do serviço de ingestão, use comandos cURL ou solicitações REST brutas do PowerShell. Para obter mais informações, consulte Solucionar problemas de telemetria de aplicativo ausente no Application Insights do Azure Monitor.
Problemas conhecidos
Os seguintes itens são problemas conhecidos para os exportadores do OpenTelemetry do Azure Monitor:
O nome da operação está ausente da telemetria de dependência. O nome da operação ausente causa falhas e afeta negativamente a experiência da guia de desempenho.
O modelo do dispositivo está ausente da telemetria de solicitação e dependência. O modelo de dispositivo ausente afeta negativamente a análise de coorte de dispositivos.
Etapa 2: Testar a conectividade entre o host do aplicativo e o serviço de ingestão
Os SDKs e agentes do Application Insights enviam telemetria para serem ingeridos como chamadas REST em nossos pontos de extremidade de ingestão. Para testar a conectividade do servidor Web ou do computador host do aplicativo com os pontos de extremidade do serviço de ingestão, use comandos cURL ou solicitações REST brutas do PowerShell. Para obter mais informações, consulte Solucionar problemas de telemetria de aplicativo ausente no Application Insights do Azure Monitor.
Problemas conhecidos
Se você baixar a biblioteca de clientes do Application Insights para instalação de um navegador, às vezes o arquivo JAR baixado está corrompido e tem cerca de metade do tamanho do arquivo de origem. Se você tiver esse problema, baixe o arquivo JAR executando o comando curl ou wget, conforme mostrado nas chamadas de comando de exemplo a seguir:
As chamadas de comando de exemplo se aplicam ao Application Insights para Java versão 3.4.11. Para encontrar o número da versão e o endereço de URL da versão atual do Application Insights para Java, consulte https://github.com/microsoft/ApplicationInsights-Java/releases.
As etapas a seguir são aplicáveis a aplicativos nativos do Spring Boot.
Etapa 1: Verificar a versão do OpenTelemetry
Você pode observar a seguinte mensagem durante a inicialização do aplicativo:
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>
Nesse caso, você precisa importar as listas de materiais do OpenTelemetry seguindo a documentação do OpenTelemetry no Spring Boot starter.
Etapa 2: Ativar o autodiagnóstico
Se algo não funcionar conforme o esperado, você poderá habilitar o autodiagnóstico no nível DEBUG para obter alguns insights. Para fazer isso, defina o nível de autodiagnóstico como ERROR, WARN, INFO, DEBUG ou TRACE usando a variável de ambiente APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL.
Para habilitar o autodiagnóstico no nível DEBUG ao executar um contêiner do docker, execute o seguinte comando:
docker run -e APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL=DEBUG <image-name>
Observação
Substitua <image-name> pelo nome da imagem do docker de acordo.
Aviso de isenção de responsabilidade para informações de terceiros
Os produtos de terceiros mencionados neste artigo são produzidos por empresas independentes da Microsoft. A Microsoft não oferece nenhuma garantia, implícita ou não, do desempenho ou da confiabilidade desses produtos.
Etapa 1: Habilitar o log de diagnóstico
O Exportador do Azure Monitor usa o agente da API OpenTelemetry para logs internos. Para habilitar o agente, execute o seguinte snippet de código:
Etapa 2: Testar a conectividade entre o host do aplicativo e o serviço de ingestão
Os SDKs e agentes do Application Insights enviam telemetria para serem ingeridos como chamadas REST em nossos pontos de extremidade de ingestão. Para testar a conectividade do servidor Web ou do computador host do aplicativo com os pontos de extremidade do serviço de ingestão, use comandos cURL ou solicitações REST brutas do PowerShell. Para obter mais informações, consulte Solucionar problemas de telemetria de aplicativo ausente no Application Insights do Azure Monitor.
Problemas conhecidos
Os seguintes itens são problemas conhecidos para os exportadores do OpenTelemetry do Azure Monitor:
O nome da operação está ausente da telemetria de dependência. O nome da operação ausente causa falhas e afeta negativamente a experiência da guia de desempenho.
O modelo do dispositivo está ausente da telemetria de solicitação e dependência. O modelo de dispositivo ausente afeta negativamente a análise de coorte de dispositivos.
O nome do servidor de banco de dados está ausente do nome da dependência. Como o nome do servidor de banco de dados não está incluído, os Exportadores do OpenTelemetry agregam incorretamente tabelas que têm o mesmo nome em servidores diferentes.
Etapa 1: Habilitar o log de diagnóstico
O Exportador do Microsoft Azure Monitor usa a biblioteca de log padrão do Python para seu log interno. Os logs da API do OpenTelemetry e do Exportador do Azure Monitor recebem um nível de gravidade de WARNING ou ERROR para atividades irregulares. O nível de gravidade INFO é usado para atividades regulares ou bem-sucedidas.
Por padrão, a biblioteca de log do Python define o nível de gravidade como WARNING. Portanto, você deve alterar o nível de gravidade para ver os logs nessa configuração de gravidade. O código de exemplo a seguir mostra como gerar logs de todos os níveis de gravidade para o console e um arquivo:
Etapa 2: Testar a conectividade entre o host do aplicativo e o serviço de ingestão
Os SDKs e agentes do Application Insights enviam telemetria para serem ingeridos como chamadas REST em nossos pontos de extremidade de ingestão. Para testar a conectividade do servidor Web ou do computador host do aplicativo com os pontos de extremidade do serviço de ingestão, use comandos cURL ou solicitações REST brutas do PowerShell. Para obter mais informações, consulte Solucionar problemas de telemetria de aplicativo ausente no Application Insights do Azure Monitor.
Etapa 3: Evitar telemetria duplicada
A telemetria duplicada geralmente é causada se você criar várias instâncias de processadores ou exportadores. Certifique-se de executar apenas um exportador e processador por vez para cada pilar de telemetria (logs, métricas e rastreamento distribuído).
As seções a seguir descrevem cenários que podem causar telemetria duplicada.
Logs de rastreamento duplicados no Azure Functions
Se você vir um par de entradas para cada log de rastreamento no Application Insights, provavelmente habilitou os seguintes tipos de instrumentação de log:
A instrumentação de log nativa no Azure Functions
A instrumentação de log azure-monitor-opentelemetry dentro da distribuição
Para evitar a duplicação, você pode desabilitar o log da distribuição, mas deixar a instrumentação de log nativa no Azure Functions habilitada. Para fazer isso, defina a variável de ambiente OTEL_LOGS_EXPORTER como None.
Telemetria duplicada no Azure Functions "Always On"
Se a configuração Always On no Azure Functions estiver definida como On, o Azure Functions manterá alguns processos em execução em segundo plano após a conclusão de cada execução. Por exemplo, suponha que você tenha uma função de temporizador de cinco minutos que chama configure_azure_monitor cada vez. Após 20 minutos, você poderá ter quatro exportadores de métricas em execução ao mesmo tempo. Essa situação pode ser a origem da telemetria de métricas duplicadas.
Nessa situação, defina a configuração Always On como Off ou tente desligar manualmente os provedores entre cada chamada configure_azure_monitor. Para desligar cada provedor, execute chamadas de desligamento para cada provedor de medidor, rastreador e agente atual, conforme mostrado no código a seguir:
As pastas de trabalho do Azure e os Jupyter Notebooks podem manter os processos do exportador em execução em segundo plano. Para evitar telemetria duplicada, limpe o cache antes de fazer mais chamadas para configure_azure_monitor.
Etapa 4: Verificar se os dados de solicitação do Flask foram coletados
Se você implementar um aplicativo Flask, poderá descobrir que não pode coletar dados da tabela Requests do Application Insights enquanto usa a biblioteca de clientes Azure Monitor OpenTelemetry Distro para Python. Esse problema pode ocorrer se você não estruturar suas declarações de import corretamente. Você pode estar importando a estrutura do aplicativo Web flask.Flask antes de chamar a função configure_azure_monitor para instrumentar a biblioteca do Flask. Por exemplo, o código a seguir não instrumenta com êxito o aplicativo Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask
configure_azure_monitor()
app = Flask(__name__)
Em vez disso, recomendamos que você importe o módulo flask como um todo e, em seguida, chame configure_azure_monitor para configurar o OpenTelemetry para usar o Azure Monitor antes de acessar flask.Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
import flask
configure_azure_monitor()
app = flask.Flask(__name__)
Como alternativa, você pode chamar configure_azure_monitor antes de importar flask.Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
from flask import Flask
app = Flask(__name__)
Suporte
Selecione uma guia para o idioma de sua escolha para descobrir as opções de suporte.