Ajuda, suporte e feedback do OpenTelemetry

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.

• Examine as perguntas frequentes
• Execute as etapas da solução de problemas
• Obter suporte
• Fornecer comentários

Perguntas frequentes

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.
• OpenTelemetry está alinhado com a estratégia da Microsoft de adotar o código aberto.

Qual é o status do OpenTelemetry?

Confira Status do OpenTelemetry.

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
  • autenticação do Microsoft Entra
  • Armazenamento offline e novas tentativas automáticas
  • Statsbeat
  • Métricas Padrão do Application Insights
  • Detectar metadados de recurso para preencher automaticamente o Nome da Função na Nuvem e a Instância da Função na Nuvem em vários ambientes do Azure
  • Métricas Dinâmicas

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?

Confira nossos documentos de ativação para .NET, Java, JavaScript (Node.js) e Python.

Devo usar o OpenTelemetry ou o SDK do Application Insights?

É recomendável usar a Distribuição do OpenTelemetry, a menos que você exija um recurso disponível apenas com suporte formal no SDK do Application Insights.

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.

Para cenários de telemetria do Python mais complexos que exigem configuração avançada, recomendamos usar o Exportador OpenTelemetry do Azure Monitor do Python.

Qual é o estado atual da versão dos recursos na Distribuição OpenTelemetry do Azure Monitor?

O gráfico a seguir divide o suporte ao recurso OpenTelemetry para cada idioma.

Recurso	.NET	Node.js	Python	Java
Rastreamento distribuído	✅	✅	✅	✅
Métricas personalizadas	✅	✅	✅	✅
Métricas padrão	✅	✅	✅	✅
Amostragem de taxa fixa	✅	✅	✅	✅
Armazenamento offline e novas tentativas automáticas	✅	✅	✅	✅
Relatório de exceção	✅	✅	✅	✅
Coleção de logs	✅	⚠️	✅	✅
Eventos personalizados	⚠️	⚠️	⚠️	✅
autenticação do Microsoft Entra	✅	✅	✅	✅
Live Metrics	✅	✅	✅	✅
Filtragem de métricas dinâmicas	✅	❌	❌	❌
Detectar Contexto do Recurso de VM/VMSS e Serviço de Aplicativo	✅	❌	✅	✅
Detectar o contexto de recursos para o AKS (Serviço de Kubernetes do Azure) e o Functions	❌	❌	❌	✅
Eventos de teste de disponibilidade gerados usando a API de Disponibilidade de Acompanhamento	❌	❌	❌	✅
Filtrar solicitações, dependências, logs e exceções por ID de usuário anônima e origem sintética	❌	❌	❌	✅
Filtrar dependências, logs e exceções por nome da operação	❌	❌	❌	✅
amostragem adaptável	❌	❌	❌	✅
Profiler	❌	❌	❌	⚠️
Depurador de instantâneo	❌	❌	❌	❌

Chave

• ✅ Esse recurso está disponível para todos os clientes com suporte formal.
• ⚠ Esse recurso está disponível em versão prévia pública. Consulte os Termos de uso complementares para versões prévias do Microsoft Azure.
• ❌ 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?

Não recomendamos isso. Consulte os Termos de uso complementares para versões prévias do Microsoft Azure.

Qual é a diferença entre a instrumentação automática e manual?

Consulte a Visão geral do OpenTelemetry.

Posso usar o Coletor do OpenTelemetry?

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.

Solução de problemas

ASP.NET Core

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 (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.

.NET

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.

Java

Etapa 1: Habilitar o log de diagnóstico

Por padrão, o log de diagnóstico está habilitado no Application Insights do Azure Monitor. Para obter mais informações, consulte Guia de solução de problemas: Application Insights do Azure Monitor para Java.

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:

  curl --location --output applicationinsights-agent-3.6.2.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download//applicationinsights-agent-3.6.2.jar
  

  wget --output-document=applicationinsights-agent-3.6.2.jar https://github.com/microsoft/ApplicationInsights-Java/releases/download//applicationinsights-agent-3.6.2.jar
  

  Observação

  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.

Nativo do Java

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.

Node.js

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:

const { diag, DiagConsoleLogger, DiagLogLevel } = require("@opentelemetry/api");
const { NodeTracerProvider } = require("@opentelemetry/sdk-trace-node");

const provider = new NodeTracerProvider();
diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.ALL);
provider.register();

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.

Python

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:

...
import logging

logging.basicConfig(format = "%(asctime)s:%(levelname)s:%(message)s", level = logging.DEBUG)

logger = logging.getLogger(__name__)
file = logging.FileHandler("example.log")
stream = logging.StreamHandler()
logger.addHandler(file)
logger.addHandler(stream)
...

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:

get_meter_provider().shutdown()
get_tracer_provider().shutdown()
get_logger_provider().shutdown()

Pastas de trabalho do Azure e Jupyter Notebooks

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:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor
import fastapi

configure_azure_monitor()

app = fastapi.FastAPI(__name__)

# Flask

from azure.monitor.opentelemetry import configure_azure_monitor
import flask

configure_azure_monitor()

app = flask.Flask(__name__)

Alternativamente, você pode chamar o configure_azure_monitor antes de importar fastapi.FastAPI ou flask.Flask:

# FastAPI

from azure.monitor.opentelemetry import configure_azure_monitor

configure_azure_monitor()

from fastapi import FastAPI

app = FastAPI(__name__)

# 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.

ASP.NET Core

• Se você tiver problemas com o Suporte do Azure, abra um tíquete de suporte do Azure.
• Para problemas de OpenTelemetry, entre em contato diretamente com a comunidade do OpenTelemetry .NET.
• Para obter uma lista de problemas abertos relacionados ao Exportador do Azure Monitor, confira a Página de Problemas do GitHub.

.NET

• Se você tiver problemas com o Suporte do Azure, abra um tíquete de suporte do Azure.
• Para problemas de OpenTelemetry, entre em contato diretamente com a comunidade do OpenTelemetry .NET.
• Para obter uma lista de problemas abertos relacionados ao Exportador do Azure Monitor, confira a Página de Problemas do GitHub.

Java

• Se você tiver problemas com o Suporte do Azure, abra um tíquete de suporte do Azure.
• Para obter ajuda com a solução de problemas, revise as etapas da solução de problemas.
• Para problemas de OpenTelemetry, entre em contato diretamente com a comunidade do OpenTelemetry.
• Para obter uma lista de problemas abertos relacionados à Instrumentação Automática do Java do Azure Monitor, confira a Página de Problemas do GitHub.

Nativo do Java

• Se você tiver problemas com o Suporte do Azure, abra um tíquete de suporte do Azure.
• Para problemas de OpenTelemetry, entre em contato diretamente com a comunidade do OpenTelemetry.
• Para obter uma lista de problemas abertos com aplicativos nativos do Spring Boot, consulte a página Problemas do GitHub.
• Para obter uma lista de problemas abertos com aplicativos nativos do Quarkus, consulte a página Problemas do GitHub.

Node.js

• Se você tiver problemas com o Suporte do Azure, abra um tíquete de suporte do Azure.
• Para problemas de OpenTelemetry, entre em contato diretamente com a comunidade JavaScript do OpenTelemetry.
• Para obter uma lista de problemas abertos relacionados ao Exportador do Azure Monitor, confira a Página de Problemas do GitHub.

Python

• Se você tiver problemas com o Suporte do Azure, abra um tíquete de suporte do Azure.
• Para problemas de OpenTelemetry, entre em contato diretamente com a comunidade Python do OpenTelemetry.
• Para obter uma lista de problemas em aberto relacionados à Distribuição do Azure Monitor, veja a Página de Problemas do GitHub.

Comentários sobre o OpenTelemetry

Para fornecer comentários:

• Preencha a pesquisa de comentários do cliente da Comunidade do OpenTelemetry.
• Fale um pouco sobre você para a Microsoft: ingresse na Comunidade de usuário pioneiro do OpenTelemetry.
• Entre em contato com outros usuários do Azure Monitor na Comunidade de tecnologia da Microsoft.
• Solicite um recurso no Fórum de comentários do Azure.