Noções básicas de coleta de dados do Azure Monitor Application Insights
Artigo
Antes que você possa monitorar seu aplicativo, ele precisa ser instrumentado.
Nas seções a seguir, abordamos algumas noções básicas de coleta de dados do Azure Monitor Application Insights.
Opções de instrumentação
Em um nível básico, "instrumentação" é simplesmente permitir que um aplicativo capture telemetria.
Existem dois métodos para instrumentar a sua aplicação:
Instrumentação automática (autoinstrumentação)
Instrumentação manual
A autoinstrumentação permite a coleta de telemetria por meio da configuração sem tocar no código do aplicativo. Embora seja mais conveniente, tende a ser menos configurável. Também não está disponível em todos os idiomas. Consulte Ambientes e idiomas suportados pela Autoinstrumentação. Quando a autoinstrumentação está disponível, é a maneira mais fácil de habilitar o Azure Monitor Application Insights.
A instrumentação manual é codificada em relação ao Application Insights ou à API OpenTelemetria. No contexto de um usuário, normalmente refere-se à instalação de um SDK específico do idioma em um aplicativo. Isso significa que você tem que gerenciar as atualizações para a versão mais recente do pacote por conta própria. Você pode usar essa opção se precisar fazer chamadas de dependência personalizadas ou chamadas de API que não são capturadas por padrão com a autoinstrumentação. Existem duas opções para instrumentação manual:
Embora vejamos o OpenTelemetry como nossa direção futura, não temos planos de parar de coletar dados de SDKs mais antigos. Ainda temos um caminho a percorrer antes que nossas Distros do Azure OpenTelemetry alcancem a paridade de recursos com nossos SDKs do Application Insights. Em muitos casos, os clientes continuam a optar por usar SDKs do Application Insights por algum tempo.
Importante
"Manual" não significa que você será obrigado a escrever código complexo para definir extensões para rastreamentos distribuídos, embora continue sendo uma opção. As bibliotecas de instrumentação incluídas em nossas distros permitem que você capture sinais de telemetria sem esforço em estruturas e bibliotecas comuns. Estamos trabalhando ativamente para instrumentar os SDKs de Serviço do Azure mais populares usando OpenTelemetry para que esses sinais estejam disponíveis para clientes que usam a Distro OpenTelemetry do Azure Monitor.
Tipos de telemetria
A telemetria, os dados recolhidos para observar a sua aplicação, pode ser dividida em três tipos ou "pilares":
Rastreamento distribuído
Métricas
Registos
Uma história completa de observabilidade inclui todos os três pilares, e o Application Insights divide esses pilares em tabelas com base em nosso modelo de dados. Nossos SDKs do Application Insights ou distros OpenTelemetry do Azure Monitor incluem tudo o que você precisa para potencializar o monitoramento de desempenho de aplicativos no Azure. A instalação do pacote em si é gratuita e você paga apenas pelos dados ingeridos no Azure Monitor.
Observabilidade de Sistemas Distribuídos por Cindy Sridharan
Roteamento de telemetria
Há duas maneiras de enviar seus dados para o Azure Monitor (ou qualquer fornecedor):
Através de um exportador direto
Através de um agente
Um exportador direto envia telemetria em processo (do código do aplicativo) diretamente para o ponto de extremidade de ingestão do Azure Monitor. A principal vantagem desta abordagem é a simplicidade da integração.
Os SDKs do Application Insights atualmente disponíveis e as Distros OpenTelemetry do Azure Monitor dependem de um exportador direto.
Nota
Para obter a posição do Monitor do Azure no OpenTelemetry-Collector, consulte as Perguntas frequentes sobre OpenTelemetria.
Gorjeta
Se você estiver planejando usar o OpenTelemetry-Collector para amostragem ou processamento de dados adicionais, poderá obter esses mesmos recursos internos ao Azure Monitor. Os clientes que migraram para o Application Insights baseado em espaço de trabalho podem se beneficiar das transformações em tempo de ingestão. Para habilitar, siga os detalhes no tutorial, ignorando a etapa que mostra como configurar uma configuração de diagnóstico, já que com o Application Insights centrado no espaço de trabalho isso já está configurado. Se você estiver filtrando menos de 50% do volume total, não há custo adicional. Depois de 50%, há um custo, mas muito menor do que o padrão por GB de carga.
OpenTelemetry
A Microsoft está entusiasmada em adotar o OpenTelemetry como o futuro da instrumentação de telemetria. Você, nossos clientes, pediu instrumentação neutra do fornecedor e temos o prazer de fazer parceria com a comunidade OpenTelemetry para criar APIs e SDKs consistentes em todos os idiomas.
A Microsoft trabalhou com as partes interessadas do projeto de dois projetos de telemetria de código aberto anteriormente populares, OpenCensus e OpenTracing. Juntos, ajudamos a criar um único projeto, o OpenTelemetry. O OpenTelemetry inclui contribuições de todos os principais fornecedores de nuvem e Application Performance Management (APM) e vive dentro da Cloud Native Computing Foundation (CNCF). A Microsoft é membro Platinum do CNCF.
Para terminologia, consulte o glossário nas especificações do OpenTelemetry .
Alguns termos herdados no Application Insights são confusos devido à convergência do setor no OpenTelemetry. A tabela a seguir destaca essas diferenças. Os termos do OpenTelemetry estão substituindo os termos do Application Insights.
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 fonte nomeada OpenTelemetry-AzureMonitor-Exporter. Para conhecer 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
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 seu servidor Web ou computador host de 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 Azure Monitor Application Insights.
Problemas conhecidos
Os seguintes itens são problemas conhecidos para os Exportadores 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 de 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 fonte nomeada OpenTelemetry-AzureMonitor-Exporter. Para conhecer 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
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 seu servidor Web ou computador host de 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 Azure Monitor Application Insights.
Problemas conhecidos
Os seguintes itens são problemas conhecidos para os Exportadores 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 de 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
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 seu servidor Web ou computador host de 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 Azure Monitor Application Insights.
Problemas conhecidos
Se você baixar a biblioteca de cliente do Application Insights para instalação a partir de um navegador, às vezes o arquivo JAR baixado está corrompido e tem cerca de metade do tamanho do arquivo de origem. Se você enfrentar esse problema, baixe o arquivo JAR executando o comando curl ou wget , conforme mostrado nas seguintes chamadas de comando de exemplo:
As chamadas de comando de exemplo aplicam-se ao Application Insights for Java versão 3.4.11. Para encontrar o número da versão e o endereço URL da versão atual do Application Insights for 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 notar 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 iniciador do Spring Boot.
Etapa 2: Habilitar o autodiagnóstico
Se algo não funcionar como esperado, você pode habilitar o DEBUG autodiagnóstico no nível para obter alguns insights. Para fazer isso, defina o nível de autodiagnóstico como ERROR, WARN, INFO, DEBUG, ou TRACE usando a APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL variável de ambiente.
Para habilitar o autodiagnóstico no nível ao DEBUG executar um contêiner do docker, execute o seguinte comando:
docker run -e APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL=DEBUG <image-name>
Nota
Substitua <image-name> pelo nome da imagem do docker de acordo.
Exclusão de responsabilidade de informações de terceiros
Os produtos de terceiros referidos neste artigo são fabricados por empresas independentes da Microsoft. A Microsoft não concede qualquer garantia, implícita ou de outra natureza, relativamente ao desempenho ou à fiabilidade destes produtos.
Etapa 1: Habilitar o log de diagnóstico
O Azure Monitor Exporter usa o logger da API OpenTelemetry para logs internos. Para habilitar o registrador, execute o seguinte trecho de código:
Etapa 2: Testar a conectividade entre o host do aplicativo e o serviço de ingestão
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 seu servidor Web ou computador host de 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 Azure Monitor Application Insights.
Problemas conhecidos
Os seguintes itens são problemas conhecidos para os Exportadores 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 de 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 OpenTelemetry agregam incorretamente tabelas que têm o mesmo nome em servidores diferentes.
Etapa 1: Habilitar o log de diagnóstico
O Microsoft Azure Monitor Exporter usa a biblioteca de log padrão Python para seu log interno. A API OpenTelemetry e os logs do Exportador do Azure Monitor recebem um nível de gravidade de WARNING ou ERROR para atividade irregular. O INFO nível de gravidade é usado para atividade regular ou bem-sucedida.
Por padrão, a biblioteca de log Python define o nível de gravidade como WARNING. Portanto, você deve alterar o nível de gravidade para ver os logs sob essa configuração de gravidade. O código de exemplo a seguir mostra como exportar 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
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 seu servidor Web ou computador host de 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 Azure Monitor Application Insights.
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 de cada 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.
Duplicar logs de rastreamento 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 azure-monitor-opentelemetry instrumentação de registro na distribuição
Para evitar 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 OTEL_LOGS_EXPORTER variável de ambiente como None.
Telemetria duplicada no Azure Functions "Always On"
Se a configuração Always On no Azure Functions estiver definida como Ativado, 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ê pode 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 Desativado ou tente desligar manualmente os provedores entre cada configure_azure_monitor chamada. Para desligar cada provedor, execute chamadas de desligamento para cada provedor de medidor, rastreador e registrador atual, conforme mostrado no código a seguir:
Pastas de trabalho do Azure e blocos de anotações do Jupyter
As Pastas de Trabalho do Azure e os Blocos de Anotações do Jupyter podem manter os processos de exportação em execução em segundo plano. Para evitar telemetria duplicada, limpe o cache antes de fazer mais chamadas para configure_azure_monitoro .
Passo 4: Certifique-se de que os dados de solicitação do Flask são coletados
Se você implementar um aplicativo Flask, poderá descobrir que não pode coletar dados da tabela de Solicitações do Application Insights enquanto usa a biblioteca de cliente do Azure Monitor OpenTelemetry Distro para Python. Esse problema pode ocorrer se você não estruturar suas import declarações corretamente. Você pode estar importando a estrutura da flask.Flask aplicação Web antes de chamar a configure_azure_monitor função para instrumentar a biblioteca 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 como um todo e, em seguida, chame configure_azure_monitor para configurar o OpenTelemetry para usar o flask Azure Monitor antes de acessarflask.Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
import flask
configure_azure_monitor()
app = flask.Flask(__name__)
Como alternativa, você pode ligar 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 opções de suporte.