Este artigo fornece opções de ajuda, suporte e feedback para o OpenTelemetry no Application Insights do Azure Monitor para aplicativos .NET, Java, Node.js e Python.
É 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 ao aceitar 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 (Software Development Kits) e agentes do Application Insights enviam telemetria para ser ingerida 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 ao aceitar 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
A Microsoft não oferece nenhuma garantia, implícita ou não, sobre o desempenho ou a confiabilidade desses produtos independentes de terceiros.
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.
Habilitar log de diagnósticos
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:
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.
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 atingir essa meta, 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.
Ausência de telemetria de Solicitações em aplicativos FastAPI ou Flask
Se você está com dados da tabela de Solicitações ausentes, mas não de outras categorias, é provável que seu framework HTTP não esteja sendo instrumentado. Isso pode ocorrer em aplicativos FastAPI e Flask que usam a biblioteca de clientes do Azure Monitor OpenTelemetry Distro para Python se você não estruturar suas declarações import corretamente. Você pode estar importando o fastapi.FastAPI ou o flask.Flask, respectivamente, antes de chamar a função configure_azure_monitor para instrumentar as bibliotecas FastAPI e Flask. Por exemplo, o código a seguir não instrumenta com sucesso os aplicativos FastAPI e Flask:
# FastAPI
from azure.monitor.opentelemetry import configure_azure_monitor
from fastapi import FastAPI
configure_azure_monitor()
app = FastAPI()
# 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 os módulos fastapi ou flask como um todo e, em seguida, chame configure_azure_monitor para configurar o OpenTelemetry para usar o Azure Monitor antes de acessar fastapi.FastAPI ou flask.Flask:
Saiba mais sobre observabilidade e como implementá-la em um aplicativo nativo de nuvem. Use os pacotes OpenTelemetry para gerar logs, métricas e dados de rastreamento e analisar os dados no Application Insights e em aplicativos de terceiros.