Compartilhar via


Application Insights para Java 2.x

Cuidado

Este artigo se aplica ao Application Insights Java 2.x, que não é mais recomendado.

A documentação da versão mais recente pode ser encontrada no Application Insights Java 3.x.

Neste artigo, você aprenderá a usar o Application Insights Java 2.x. Este artigo mostra como:

  • Comece, e aprenda a instrutar solicitações, acompanhar dependências, coletar contadores de desempenho, diagnosticar problemas de desempenho e exceções, e escrever código para acompanhar o que os usuários fazem com seu aplicativo.
  • Envie logs de rastreamento para o Application Insights e explore-os usando o portal do Application Insights.
  • Monitorar dependências, exceções capturadas e tempos de execução de método em aplicativos Web Java.
  • Filtrar a telemetria em seu aplicativo Web Java.
  • Explore as métricas de desempenho do sistema Linux no Application Insights usando collectd.
  • Medir métricas para o código de aplicações baseadas na JVM (Java Virtual Machine). Exporte os dados para seus sistemas de monitoramento favoritos usando o monitoramento de aplicativos do Micrometer.

Observação

Em 31 de março de 31, 2025, o suporte à ingestão de chave de instrumentação será encerrado. A ingestão de chave de instrumentação continuará funcionando, mas não forneceremos mais atualizações ou suporte para o recurso. Transição para cadeias de conexão para aproveitar as novas funcionalidades.

Introdução ao Application Insights em um projeto Web Java

Nesta seção, você usará o SDK do Application Insights para instrumentar solicitações, controlar dependências, coletar contadores de desempenho, diagnosticar problemas de desempenho e exceções e escrever código para acompanhar o que os usuários fazem com seu aplicativo.

O Application Insights é um serviço de análise extensível para desenvolvedores Web que ajuda você a entender o desempenho e o uso de seu aplicativo dinâmico. O Application Insights dá suporte a aplicativos Java em execução no Linux, Unix ou Windows.

Pré-requisitos

Você precisa de:

Obter uma chave de instrumentação do Application Insights

  1. Entre no portal do Azure.

  2. No portal do Azure, crie um recurso do Application Insights. Defina o tipo de aplicativo como aplicativo Web Java.

  3. Localize a chave de instrumentação do novo recurso. Você precisará colar essa chave em seu projeto de código em breve.

    Captura de tela do painel Visão geral de um recurso do Application Insights no portal do Azure com a chave de instrumentação realçada.

Adicionar o SDK do Application Insights para Java ao seu projeto

Escolha o tipo de projeto.

Se o projeto já estiver configurado para usar o Maven para compilação, mescle o código a seguir ao arquivo pom.xml . Em seguida, atualize as dependências do projeto para baixar os binários.

    <dependencies>
      <dependency>
        <groupId>com.microsoft.azure</groupId>
        <artifactId>applicationinsights-web-auto</artifactId>
        <!-- or applicationinsights-web for manual web filter registration -->
        <!-- or applicationinsights-core for bare API -->
        <version>2.6.4</version>
      </dependency>
    </dependencies>

Perguntas frequentes

  • Qual é a relação entre os componentes -web-auto, -web e -core?

    • applicationinsights-web-auto fornece métricas que acompanham as contagens de solicitações de servlet HTTP e os tempos de resposta registrando automaticamente o filtro de servlet do Application Insights em tempo de execução.
    • applicationinsights-web também fornece métricas que rastreiam contagens de solicitações de servlet HTTP e tempos de resposta. Mas o registro manual do filtro de servlet do Application Insights em seu aplicativo é necessário.
    • applicationinsights-core oferece a API básica, por exemplo, se o aplicativo não for baseado em servlet.
  • Como devo atualizar o SDK para a versão mais recente?

    • A partir de novembro de 2020, para monitorar aplicativos Java, recomendamos usar o Application Insights Java 3.x. Para obter mais informações sobre como começar, consulte o Application Insights Java 3.x.

Adicionar um arquivo ApplicationInsights.xml

Adicione ApplicationInsights.xml à pasta de recursos em seu projeto ou verifique se ele foi adicionado ao caminho de classe de implantação do projeto. Copie o XML a seguir para ele.

Substitua a chave de instrumentação pela que você obteve do portal do Azure.

<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings" schemaVersion="2014-05-30">

   <!-- The key from the portal: -->
   <InstrumentationKey>** Your instrumentation key **</InstrumentationKey>

   <!-- HTTP request component (not required for bare API) -->
   <TelemetryModules>
      <Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModule"/>
      <Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebSessionTrackingTelemetryModule"/>
      <Add type="com.microsoft.applicationinsights.web.extensibility.modules.WebUserTrackingTelemetryModule"/>
   </TelemetryModules>

   <!-- Events correlation (not required for bare API) -->
   <!-- These initializers add context data to each event -->
   <TelemetryInitializers>
      <Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationIdTelemetryInitializer"/>
      <Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationNameTelemetryInitializer"/>
      <Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebSessionTelemetryInitializer"/>
      <Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserTelemetryInitializer"/>
      <Add type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserAgentTelemetryInitializer"/>
   </TelemetryInitializers>

</ApplicationInsights>

Opcionalmente, o arquivo de configuração pode estar em qualquer local acessível ao seu aplicativo. A propriedade -Dapplicationinsights.configurationDirectory do sistema especifica o diretório que contém ApplicationInsights.xml. Por exemplo, um arquivo de configuração localizado em E:\myconfigs\appinsights\ApplicationInsights.xml seria configurado com a propriedade -Dapplicationinsights.configurationDirectory="E:\myconfigs\appinsights".

  • A chave de instrumentação é acompanhada de cada item de telemetria e indica ao Application Insights que deve exibi-la em seu recurso.
  • O componente solicitação HTTP é opcional. Ele envia automaticamente a telemetria sobre solicitações e tempos de resposta para o portal.
  • A correlação de eventos é uma adição ao componente de solicitação HTTP. Ele atribui um identificador a cada solicitação recebida pelo servidor. Em seguida, ele adiciona esse identificador como uma propriedade a cada item de telemetria como a propriedade Operation.Id. Ele permite correlacionar a telemetria associada a cada solicitação definindo um filtro na pesquisa de diagnóstico.

Maneiras alternativas de definir a chave de instrumentação

O SDK do Application Insights procura a chave nesta ordem:

  • Propriedade do sistema: -DAPPINSIGHTS_INSTRUMENTATIONKEY=your_ikey
  • Variável de ambiente: APPINSIGHTS_INSTRUMENTATIONKEY
  • Arquivo de configuração: ApplicationInsights.xml

Você também pode defini-lo no código:

    String instrumentationKey = "00000000-0000-0000-0000-000000000000";

    if (instrumentationKey != null)
    {
        TelemetryConfiguration.getActive().setInstrumentationKey(instrumentationKey);
    }

Adicionar agente

Instale o agente Java para capturar chamadas HTTP de saída, consultas JDBC, log de aplicativos e melhor nomenclatura de operação.

Execute seu aplicativo.

Execute-o no modo de depuração no computador de desenvolvimento ou publique-o no servidor.

Ver sua telemetria no Application Insights

Retorne ao recurso do Application Insights no portal do Azure.

Os dados de solicitações HTTP são exibidos no painel de visão geral. Se ele não estiver lá, aguarde alguns segundos e selecione Atualizar.

Captura de tela que mostra dados de exemplo de visão geral.

Saiba mais sobre as métricas.

Clique em qualquer gráfico para ver métricas agregadas mais detalhadas.

Captura de tela que mostra um painel de falhas do Application Insights com gráficos.

Dados da instância

Clique em um tipo de solicitação específico para ver instâncias individuais.

Captura de tela que mostra a exploração detalhada de uma visualização de exemplo específica.

Log Analytics: linguagem de consulta avançada

À medida que você acumula mais dados, você pode executar consultas para agregar dados e encontrar instâncias individuais. O Log Analytics é uma ferramenta poderosa para entender o desempenho e o uso e para fins de diagnóstico.

Captura de tela que mostra um exemplo do Log Analytics no portal do Azure.

Instalar seu aplicativo no servidor

Agora, publique seu aplicativo no servidor, permita que as pessoas o usem e assista à telemetria aparecer no portal.

  • Verifique se o firewall permite que seu aplicativo envie telemetria para estas portas:

    • dc.services.visualstudio.com:443
    • f5.services.visualstudio.com:443
  • Se o tráfego de saída precisar ser roteado por meio de um firewall, defina as propriedades http.proxyHost do sistema e http.proxyPort.

  • Em servidores Windows, instale:

Serviço de Aplicativo do Azure, Serviço de Kubernetes do Azure, configuração de VMs

A melhor e mais fácil abordagem para monitorar seus aplicativos em execução em qualquer provedor de recursos do Azure é usar o Application Insights Java 3.x.

Exceções e falhas de solicitação

Exceções sem tratamento e falhas de solicitação são coletadas automaticamente pelo filtro web do Application Insights.

Para coletar dados em outras exceções, você pode inserir chamadas para trackException() em seu código.

Monitorar chamadas de método e dependências externas

Instale o agente Java para registrar em log métodos internos e chamadas feitas por meio do JDBC, com dados de tempo e para nomenclatura automática de operação.

Rastreamento distribuído W3C

O SDK do Application Insights para Java agora dá suporte ao rastreamento distribuído W3C.

A configuração do SDK de entrada é explicada ainda mais na correlação de telemetria no Application Insights.

A configuração do SDK de saída é definida no arquivo AI-Agent.xml .

Contadores de desempenho

Selecione Investigar>Métricas para ver um intervalo de contadores de desempenho.

Captura de tela que mostra o painel Métricas para um recurso do Application Insights no portal do Azure com bytes privados de processo selecionados.

Personalizar a coleção de contadores de desempenho

Para desabilitar a coleta do conjunto padrão de contadores de desempenho, adicione o seguinte código no nó raiz do arquivo ApplicationInsights.xml :

    <PerformanceCounters>
       <UseBuiltIn>False</UseBuiltIn>
    </PerformanceCounters>

Coletar mais contadores de desempenho

Você pode especificar mais contadores de desempenho a serem coletados.

Contadores JMX (expostos pela máquina virtual Java)
    <PerformanceCounters>
      <Jmx>
        <Add objectName="java.lang:type=ClassLoading" attribute="TotalLoadedClassCount" displayName="Loaded Class Count"/>
        <Add objectName="java.lang:type=Memory" attribute="HeapMemoryUsage.used" displayName="Heap Memory Usage-used" type="composite"/>
      </Jmx>
    </PerformanceCounters>
  • displayName: o nome exibido no portal do Application Insights.
  • objectName: o nome do objeto JMX.
  • attribute: o atributo do nome do objeto JMX a ser buscado.
  • type (opcional): o tipo de atributo do objeto JMX:
    • Padrão: Tipo simples, como int ou long.
    • composite: os dados do contador perf estão no formato de Attribute.Data.
    • tabular: os dados do contador perf estão no formato de uma linha de tabela.
Contadores de desempenho do Windows

Cada contador de desempenho do Windows é um membro de uma categoria (da mesma forma que um campo é membro de uma classe). As categorias podem ser globais ou ter instâncias numeradas ou nomeadas.

    <PerformanceCounters>
      <Windows>
        <Add displayName="Process User Time" categoryName="Process" counterName="%User Time" instanceName="__SELF__" />
        <Add displayName="Bytes Printed per Second" categoryName="Print Queue" counterName="Bytes Printed/sec" instanceName="Fax" />
      </Windows>
    </PerformanceCounters>
  • displayName: o nome exibido no portal do Application Insights.
  • categoryName: a categoria do contador de desempenho (objeto de desempenho) com a qual esse contador de desempenho está associado.
  • counterName: o nome do contador de desempenho.
  • instanceName: o nome da instância de categoria do contador de desempenho ou uma cadeia de caracteres vazia (""), se a categoria contiver uma única instância. Se categoryName estiver Process e o contador de desempenho que você deseja coletar for do processo JVM atual no qual seu aplicativo está em execução, especifique "__SELF__".

Contadores de desempenho do Unix

Instale collectd com o plug-in do Application Insights para acessar uma ampla variedade de dados de sistema e rede.

Obter dados de usuário e sessão

Agora você está enviando telemetria do servidor Web. Para obter a exibição completa de 360 graus do aplicativo, você pode adicionar mais monitoramento:

Enviar sua própria telemetria

Agora que instalou o SDK, você pode usar a API para enviar sua própria telemetria:

Testes da Web de disponibilidade

O Application Insights pode testar seu site em intervalos regulares para verificar se ele está funcionando e respondendo bem.

Saiba mais sobre como configurar testes web de disponibilidade.

Resolução de problemas

Confira o artigo de solução de problemas dedicado.

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 nos nossos pontos de extremidade de ingestão. Você pode testar a conectividade do servidor Web ou do computador host do aplicativo nos pontos de extremidade do serviço de ingestão usando clientes REST brutos do PowerShell ou comandos curl. Consulte Como solucionar problemas de ausência de telemetria de aplicativos no Azure Monitor Application Insights.

Explorar logs de rastreamento do Java no Application Insights

Se você estiver usando Logback ou Log4J (v1.2 ou v2.0) para rastreamento, poderá enviar seus logs de rastreamento automaticamente para o Application Insights, onde você pode explorá-los e pesquisá-los.

Dica

Você precisa definir sua chave de instrumentação do Application Insights apenas uma vez para seu aplicativo. Se você estiver usando uma estrutura como o Java Spring, talvez já tenha registrado a chave em outro lugar na configuração do aplicativo.

Usar o agente Java do Application Insights

Por padrão, o agente Java do Application Insights captura automaticamente o registro de log realizado no nível WARN e superior.

Você pode alterar o limite de captura de logs usando o arquivo AI-Agent.xml:

<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsightsAgent>
   <Instrumentation>
      <BuiltIn>
         <Logging threshold="info"/>
      </BuiltIn>
   </Instrumentation>
</ApplicationInsightsAgent>

Você pode desabilitar a captura de log do agente Java usando o arquivo AI-Agent.xml :

<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsightsAgent>
   <Instrumentation>
      <BuiltIn>
         <Logging enabled="false"/>
      </BuiltIn>
   </Instrumentation>
</ApplicationInsightsAgent>

Alternatives

Em vez de usar o agente Java, você pode seguir estas instruções.

Instalar o SDK do Java

Siga as instruções para instalar o SDK do Application Insights para Java, caso ainda não tenha feito isso.

Adicionar bibliotecas de log ao seu projeto

Escolha a maneira apropriada para seu projeto.

Especialista

Se o projeto já estiver configurado para usar o Maven para build, mescle um dos snippets de código a seguir no arquivo pom.xml . Em seguida, atualize as dependências do projeto para baixar os binários.

Logback


    <dependencies>
       <dependency>
          <groupId>com.microsoft.azure</groupId>
          <artifactId>applicationinsights-logging-logback</artifactId>
          <version>[2.0,)</version>
       </dependency>
    </dependencies>

Log4J v2.0


    <dependencies>
       <dependency>
          <groupId>com.microsoft.azure</groupId>
          <artifactId>applicationinsights-logging-log4j2</artifactId>
          <version>[2.0,)</version>
       </dependency>
    </dependencies>

Log4J v1.2


    <dependencies>
       <dependency>
          <groupId>com.microsoft.azure</groupId>
          <artifactId>applicationinsights-logging-log4j1_2</artifactId>
          <version>[2.0,)</version>
       </dependency>
    </dependencies>
Gradle

Se o projeto já estiver configurado para usar o Gradle para compilação, adicione uma das linhas a seguir ao dependencies grupo no arquivo build.gradle . Em seguida, atualize as dependências do projeto para baixar os binários.

Logback


    compile group: 'com.microsoft.azure', name: 'applicationinsights-logging-logback', version: '2.0.+'

Log4J v2.0

    compile group: 'com.microsoft.azure', name: 'applicationinsights-logging-log4j2', version: '2.0.+'

Log4J v1.2

    compile group: 'com.microsoft.azure', name: 'applicationinsights-logging-log4j1_2', version: '2.0.+'

Siga as diretrizes para instalar manualmente o SDK do Java do Application Insights e baixar o jar. Na página Central do Maven, selecione o jar link na seção de download do appender apropriado. Adicione o appender jar baixado ao projeto.

Logger Baixar Biblioteca
Logback Logback appender Jar applicationinsights-logging-logback
Log4J v2.0 Log4J v2 appender Jar applicationinsights-logging-log4j2
Log4j v1.2 Log4J v1.2 appender Jar applicationinsights-logging-log4j1_2

Adicione o appender ao seu framework de log

Para começar a obter registros, mescle o snippet de código relevante ao arquivo de configuração do Logback ou Log4J.

Logback


    <appender name="aiAppender" 
      class="com.microsoft.applicationinsights.logback.ApplicationInsightsAppender">
        <instrumentationKey>[APPLICATION_INSIGHTS_KEY]</instrumentationKey>
    </appender>
    <root level="trace">
      <appender-ref ref="aiAppender" />
    </root>

Log4J v2.0


    <Configuration packages="com.microsoft.applicationinsights.log4j.v2">
      <Appenders>
        <ApplicationInsightsAppender name="aiAppender" instrumentationKey="[APPLICATION_INSIGHTS_KEY]" />
      </Appenders>
      <Loggers>
        <Root level="trace">
          <AppenderRef ref="aiAppender"/>
        </Root>
      </Loggers>
    </Configuration>

Log4J v1.2


    <appender name="aiAppender" 
         class="com.microsoft.applicationinsights.log4j.v1_2.ApplicationInsightsAppender">
        <param name="instrumentationKey" value="[APPLICATION_INSIGHTS_KEY]" />
    </appender>
    <root>
      <priority value ="trace" />
      <appender-ref ref="aiAppender" />
    </root>

Os apêndices do Application Insights podem ser referenciados por qualquer logger configurado e não necessariamente pelo logger raiz, como mostrado nos exemplos de código anteriores.

Explorar seus rastreamentos no portal do Application Insights

Agora que você configurou seu projeto para enviar rastreamentos ao Application Insights, você pode exibir e pesquisar esses rastreamentos no portal do Application Insights no painel Pesquisa .

As exceções enviadas por meio de registradores serão exibidas no portal como telemetria de Exceções.

Captura de tela que mostra o painel Pesquisa de um recurso do Application Insights no portal do Azure.

Monitorar dependências, exceções capturadas e tempos de execução de método em aplicativos Web Java

Se você instrumentou seu aplicativo Web Java com o SDK do Application Insights, poderá usar o agente Java para obter informações mais profundas, sem alterações de código:

  • Dependências: dados sobre chamadas que seu aplicativo faz para outros componentes, incluindo:

    • Chamadas HTTP de saída: chamadas feitas por meio de Apache HttpClient, OkHttp e java.net.HttpURLConnection são capturadas.
    • Chamadas Redis: Chamadas feitas pelo cliente Jedis são capturadas.
    • Consultas JDBC: para MySQL e PostgreSQL, se a chamada levar mais de 10 segundos, o agente relatará o plano de consulta.
  • Registro de logs de aplicativos: capture e correlacione seus logs de aplicativos com solicitações HTTP e outra telemetria:

    • Log4j 1.2
    • Log4j2
    • Logback
  • Melhor nomenclatura de operação: usado para agregação de solicitações no portal.

    • Spring: Com base em @RequestMapping.
    • JAX-RS: Com base em @Path.

Para usar o agente Java, instale-o no servidor. Seus aplicativos Web devem ser instrumentados com o SDK java do Application Insights.

Instalar o agente do Application Insights para Java

  1. No computador que executa o servidor Java, baixe o agente 2.x. Verifique se a versão do agente Java 2.x que você usa corresponde à versão do SDK java do Application Insights 2.x que você usa.

  2. Edite o script de inicialização do servidor de aplicativos e adicione o seguinte argumento JVM:

    -javaagent:<full path to the agent JAR file>

    Por exemplo, no Tomcat em um computador Linux:

    export JAVA_OPTS="$JAVA_OPTS -javaagent:<full path to agent JAR file>"

  3. Reinicie o servidor de aplicativos.

Configurar o agente

Crie um arquivo chamado AI-Agent.xml e coloque-o na mesma pasta que o arquivo jar do agente.

Defina o conteúdo do arquivo XML. Edite o exemplo a seguir para incluir ou omitir os recursos desejados.

<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsightsAgent>
   <Instrumentation>
      <BuiltIn enabled="true">

         <!-- capture logging via Log4j 1.2, Log4j2, and Logback, default is true -->
         <Logging enabled="true" />

         <!-- capture outgoing HTTP calls performed through Apache HttpClient, OkHttp,
              and java.net.HttpURLConnection, default is true -->
         <HTTP enabled="true" />

         <!-- capture JDBC queries, default is true -->
         <JDBC enabled="true" />

         <!-- capture Redis calls, default is true -->
         <Jedis enabled="true" />

         <!-- capture query plans for JDBC queries that exceed this value (MySQL, PostgreSQL),
              default is 10000 milliseconds -->
         <MaxStatementQueryLimitInMS>1000</MaxStatementQueryLimitInMS>

      </BuiltIn>
   </Instrumentation>
</ApplicationInsightsAgent>

Mais configuração (Spring Boot)

java -javaagent:/path/to/agent.jar -jar path/to/TestApp.jar

Para o Serviço de Aplicativo do Azure, siga estas etapas:

  1. Selecione Configurações>de Aplicativo.

  2. Em Configurações do Aplicativo, adicione um novo par de valores de chave:

    • Chave: JAVA_OPTS
    • Valor: -javaagent:D:/home/site/wwwroot/applicationinsights-agent-2.6.4.jar

    O agente deve ser empacotado como um recurso em seu projeto para que ele acabe no diretório D:/home/site/wwwroot/ . Para confirmar se o seu agente está no diretório correto do App Service, acesse Ferramentas de Desenvolvimento>Ferramentas Avançadas>Console de Depuração e examine o conteúdo do diretório do site.

  3. Salve as configurações e reinicie o aplicativo. Essas etapas se aplicam somente aos serviços de aplicativo em execução no Windows.

Observação

AI-Agent.xml e o arquivo jar do agente devem estar na mesma pasta. Eles geralmente são colocados juntos na pasta /resources do projeto.

Habilitar o rastreamento distribuído do W3C

Adicione o seguinte snippet a AI-Agent.xml:

<Instrumentation>
   <BuiltIn enabled="true">
      <HTTP enabled="true" W3C="true" enableW3CBackCompat="true"/>
   </BuiltIn>
</Instrumentation>

Observação

O modo de compatibilidade com versões anteriores é habilitado por padrão. O enableW3CBackCompat parâmetro é opcional e deve ser usado somente quando você quiser desativá-lo.

Idealmente, esse seria o caso quando todos os serviços foram atualizados para versões mais recentes de SDKs que dão suporte ao protocolo W3C. Recomendamos que você mude para versões mais recentes de SDKs com suporte do W3C o mais rápido possível.

Verifique se as configurações de entrada e saída (agente) são exatamente as mesmas.

Exibir os dados

No recurso do Application Insights, os tempos de execução de método e dependência remota agregados aparecem no bloco Desempenho.

Para pesquisar instâncias individuais de relatórios de dependência, exceção e método, abra Pesquisa.

Saiba mais sobre como diagnosticar problemas de dependência.

Perguntas ou problemas?

Use os seguintes recursos:

Filtrar telemetria em seu aplicativo Web Java

Os filtros fornecem uma maneira de selecionar a telemetria que seu aplicativo Web Java envia ao Application Insights. Há alguns filtros prontos para uso disponíveis. Você também pode escrever seus próprios filtros personalizados.

Os filtros prontos para uso incluem:

  • Nível de severidade de rastreamento.
  • URLs específicas, palavras-chave ou códigos de resposta.
  • Respostas rápidas. Em outras palavras, solicitações às quais seu aplicativo respondeu rapidamente.
  • Nomes de eventos específicos.

Observação

Os filtros distorcem as métricas do aplicativo. Por exemplo, você pode decidir que, para diagnosticar respostas lentas, você definirá um filtro para descartar tempos de resposta rápidos. Mas você deve estar ciente de que os tempos médios de resposta relatados pelo Application Insights serão mais lentos do que a velocidade verdadeira. Além disso, a contagem de solicitações será menor que a contagem real.

Se isso for uma preocupação, use Amostragem.

Definir filtros

Em ApplicationInsights.xml, adicione uma TelemetryProcessors seção como este exemplo:


    <ApplicationInsights>
      <TelemetryProcessors>

        <BuiltInProcessors>
           <Processor type="TraceTelemetryFilter">
                  <Add name="FromSeverityLevel" value="ERROR"/>
           </Processor>

           <Processor type="RequestTelemetryFilter">
                  <Add name="MinimumDurationInMS" value="100"/>
                  <Add name="NotNeededResponseCodes" value="200-400"/>
           </Processor>

           <Processor type="PageViewTelemetryFilter">
                  <Add name="DurationThresholdInMS" value="100"/>
                  <Add name="NotNeededNames" value="home,index"/>
                  <Add name="NotNeededUrls" value=".jpg,.css"/>
           </Processor>

           <Processor type="TelemetryEventFilter">
                  <!-- Names of events we don't want to see -->
                  <Add name="NotNeededNames" value="Start,Stop,Pause"/>
           </Processor>

           <!-- Exclude telemetry from availability tests and bots -->
           <Processor type="SyntheticSourceFilter">
                <!-- Optional: specify which synthetic sources,
                     comma-separated
                     - default is all synthetics -->
                <Add name="NotNeededSources" value="Application Insights Availability Monitoring,BingPreview"
           </Processor>

        </BuiltInProcessors>

        <CustomProcessors>
          <Processor type="com.fabrikam.MyFilter">
            <Add name="Successful" value="false"/>
          </Processor>
        </CustomProcessors>

      </TelemetryProcessors>
    </ApplicationInsights>

Inspecione o conjunto completo de processadores internos.

Filtros internos

Esta seção discute os filtros internos disponíveis.

Filtro de métricas de telemetria


           <Processor type="MetricTelemetryFilter">
                  <Add name="NotNeeded" value="metric1,metric2"/>
           </Processor>
  • NotNeeded: lista separada por vírgulas de nomes de métrica personalizados

Filtro de telemetria de visualização de página


           <Processor type="PageViewTelemetryFilter">
                  <Add name="DurationThresholdInMS" value="500"/>
                  <Add name="NotNeededNames" value="page1,page2"/>
                  <Add name="NotNeededUrls" value="url1,url2"/>
           </Processor>
  • DurationThresholdInMS: duração refere-se ao tempo necessário para carregar a página. Se esse parâmetro for definido, as páginas carregadas mais rapidamente do que essa hora não serão relatadas.
  • NotNeededNames: lista separada por vírgulas de nomes de página.
  • NotNeededUrls: lista separada por vírgulas de fragmentos de URL. Por exemplo, "home" filtra todas as páginas que têm "home" na URL.

Solicitar filtro de telemetria


           <Processor type="RequestTelemetryFilter">
                  <Add name="MinimumDurationInMS" value="500"/>
                  <Add name="NotNeededResponseCodes" value="page1,page2"/>
                  <Add name="NotNeededUrls" value="url1,url2"/>
           </Processor>

Filtro de origem sintética

Filtra toda a telemetria que tem valores na propriedade SyntheticSource. As solicitações de bots, rastreadores e testes de disponibilidade são incluídas.

Filtra a telemetria para todas as solicitações sintéticas:


           <Processor type="SyntheticSourceFilter" />

Filtra a telemetria de fontes sintéticas específicas.


           <Processor type="SyntheticSourceFilter" >
                  <Add name="NotNeeded" value="source1,source2"/>
           </Processor>
  • NotNeeded: lista separada por vírgulas de nomes de origem sintética

Filtro de evento de telemetria

Filtra eventos personalizados que foram registrados usando TrackEvent():


           <Processor type="TelemetryEventFilter" >
                  <Add name="NotNeededNames" value="event1, event2"/>
           </Processor>
  • NotNeededNames: lista separada por vírgulas de nomes de eventos

Filtro de telemetria de rastreamento

Filtra rastreamentos de log registrados usando TrackTrace() ou um coletor de estrutura de log:


           <Processor type="TraceTelemetryFilter">
                  <Add name="FromSeverityLevel" value="ERROR"/>
           </Processor>
  • Os FromSeverityLevel valores válidos são:

    • OFF: filtra todos os rastreamentos.
    • TRACE: sem filtragem. É igual ao nível TRACE.
    • INFO: Filtra o nível de TRACE.
    • AVISO: filtra TRACE e INFO.
    • ERRO: exclui WARN, INFO e TRACE.
    • CRÍTICO: Filtra tudo menos CRÍTICO.

Filtros personalizados

As seções a seguir mostram as etapas para criar seus próprios filtros personalizados.

Codificar seu filtro

Em seu código, crie uma classe que implemente TelemetryProcessor:


    package com.fabrikam.MyFilter;
    import com.microsoft.applicationinsights.extensibility.TelemetryProcessor;
    import com.microsoft.applicationinsights.telemetry.Telemetry;

    public class SuccessFilter implements TelemetryProcessor {

        /* Any parameters that are required to support the filter.*/
        private final String successful;

        /* Initializers for the parameters, named "setParameterName" */
        public void setNotNeeded(String successful)
        {
            this.successful = successful;
        }

        /* This method is called for each item of telemetry to be sent.
           Return false to discard it.
           Return true to allow other processors to inspect it. */
        @Override
        public boolean process(Telemetry telemetry) {
            if (telemetry == null) { return true; }
            if (telemetry instanceof RequestTelemetry)
            {
                RequestTelemetry requestTelemetry = (RequestTelemetry)    telemetry;
                return request.getSuccess() == successful;
            }
            return true;
        }
    }

Invocar seu filtro no arquivo de configuração

Agora, em ApplicationInsights.xml:



    <ApplicationInsights>
      <TelemetryProcessors>
        <CustomProcessors>
          <Processor type="com.fabrikam.SuccessFilter">
            <Add name="Successful" value="false"/>
          </Processor>
        </CustomProcessors>
      </TelemetryProcessors>
    </ApplicationInsights>

Invocar seu filtro (Java Spring)

Para aplicativos baseados no Spring Framework, os processadores de telemetria personalizados devem ser registrados em sua classe de aplicativo principal como um bean. Em seguida, eles serão conectados automaticamente quando o aplicativo for iniciado.

@Bean
public TelemetryProcessor successFilter() {
      return new SuccessFilter();
}

Você cria seus próprios parâmetros de filtro em application.properties. Em seguida, você usa a estrutura de configuração externalizada do Spring Boot para passar esses parâmetros para o filtro personalizado.

Resolução de problemas

Esta seção oferece uma dica de solução de problemas.

Meu filtro não está funcionando

Verifique se você forneceu valores de parâmetro válidos. Por exemplo, as durações devem ser números inteiros. Valores inválidos farão com que o filtro seja ignorado. Se o filtro personalizado gerar uma exceção de um método de construtor ou de conjunto, ele será ignorado.

collectd: Métricas de desempenho do Linux no Application Insights (obsoleto)

Para explorar as métricas de desempenho do sistema Linux no Application Insights, instale collectd junto com o plug-in do Application Insights. Essa solução de software livre reúne várias estatísticas de sistema e de rede.

Normalmente, você usará collectd se já tiver instrumentado seu serviço web Java com o Application Insights. Ele fornece mais dados para ajudá-lo a melhorar o desempenho do aplicativo ou diagnosticar problemas.

Obter sua chave de instrumentação

No portal do Azure, abra o recurso do Application Insights em que você deseja que os dados apareçam. Ou você pode criar um novo recurso.

Faça uma cópia da Chave de Instrumentação, que identifica o recurso.

Captura de tela que mostra o painel de visão geral de um recurso do Application Insights no portal do Azure com a chave de instrumentação realçada.

Instalar coletado e o plug-in

Em seus computadores de servidor Linux:

  1. Instale a versão 5.4.0 ou posterior do collectd.
  2. Baixe o plug-in de gravador coletado do Application Insights. Observe o número da versão.
  3. Copie o arquivo JAR do plug-in em /usr/share/collectd/java.
  4. Editar /etc/collectd/collectd.conf:
    • Verifique se o plug-in Java está habilitado.

    • Atualize o JVMArg para o java.class.path incluir o seguinte arquivo JAR. Atualize o número da versão para corresponder ao que você baixou:

      • /usr/share/collectd/java/applicationinsights-collectd-1.0.5.jar
    • Adicione este snippet usando a chave de instrumentação do recurso:

      
           LoadPlugin "com.microsoft.applicationinsights.collectd.ApplicationInsightsWriter"
           <Plugin ApplicationInsightsWriter>
              InstrumentationKey "Your key"
           </Plugin>
      

      Aqui está parte de um arquivo de configuração de exemplo:

      
          ...
          # collectd plugins
          LoadPlugin cpu
          LoadPlugin disk
          LoadPlugin load
          ...
      
          # Enable Java Plugin
          LoadPlugin "java"
      
          # Configure Java Plugin
          <Plugin "java">
            JVMArg "-verbose:jni"
            JVMArg "-Djava.class.path=/usr/share/collectd/java/applicationinsights-collectd-1.0.5.jar:/usr/share/collectd/java/collectd-api.jar"
      
            # Enabling Application Insights plugin
            LoadPlugin "com.microsoft.applicationinsights.collectd.ApplicationInsightsWriter"
      
            # Configuring Application Insights plugin
            <Plugin ApplicationInsightsWriter>
              InstrumentationKey "12345678-1234-1234-1234-123456781234"
            </Plugin>
      
            # Other plugin configurations ...
            ...
          </Plugin>
          ...
      

Configure outros plug-ins do collectd, que podem coletar vários dados de fontes diferentes.

Reinicie collectd de acordo com seu manual.

Exibir os dados no Application Insights

Em seu recurso do Application Insights, abra Métricas e adicione gráficos. Selecione as métricas que você deseja ver na categoria Personalizado .

Por padrão, as métricas são agregadas em todos os computadores host dos quais as métricas foram coletadas. Para exibir as métricas por host, no painel detalhes do gráfico , ative o Agrupamento e, em seguida, escolha agrupar por CollectD-Host.

Excluir o upload de estatísticas específicas

Por padrão, o plug-in do Application Insights envia todos os dados coletados por todos os plug-ins habilitados collectd read .

Para excluir dados de plug-ins específicos ou fontes de dados:

  • Edite o arquivo de configuração.

  • Em <Plugin ApplicationInsightsWriter>, adicione linhas de diretiva como as do seguinte quadro:

    Diretiva Efeito
    Exclude disk Exclua todos os dados coletados pelo disk plug-in.
    Exclude disk:read,write Exclua as fontes chamadas read e write do plugin disk.

Separe as diretivas com uma nova linha.

Problemas?

Esta seção oferece dicas de solução de problemas.

Não vejo dados no portal

Tente estas opções:

  • Abra a Pesquisa para ver se os eventos brutos chegaram. Às vezes, eles demoram mais para aparecer no gerenciador de métricas.
  • Talvez seja necessário definir exceções de firewall para dados de saída.
  • Habilite o rastreamento no plug-in do Application Insights. Adicione esta linha dentro de <Plugin ApplicationInsightsWriter>:
    • SDKLogger true
  • Abra um terminal e inicie collectd no modo detalhado para ver os problemas que ele está relatando:
    • sudo collectd -f

Problema conhecido

O plug-in de gravação do Application Insights é incompatível com determinados plug-ins de leitura. Alguns plug-ins às vezes enviam NaN, mas o plug-in do Application Insights espera um número de ponto flutuante.

  • Sintoma: o collectd log mostra erros que incluem "IA: ... SintaxeError: Token inesperado N."
  • Solução alternativa: exclua os dados coletados pelos plug-ins de gravação do problema.

O monitoramento de aplicativos de micrometer mede as métricas do código do aplicativo baseado em JVM e permite exportar os dados para seus sistemas de monitoramento favoritos. Esta seção ensina como usar o Micrometer com o Application Insights para aplicativos Spring Boot e não Spring Boot.

Usar o Spring Boot 1.5x

Adicione as seguintes dependências ao pom.xml ou build.gradle :

  • Starter do Spring Boot do Application Insights 2.5.0 ou versão posterior.
  • Micrometer Azure Registry 1.1.0 ou superior.
  • Micrometer Spring Legacy 1.1.0 ou superior. Ele realiza backports do código de autoconfiguração no Spring framework.
  • Recurso ApplicationInsights.

Siga estas etapas:

  1. Atualize o arquivo pom.xml do aplicativo Spring Boot e adicione as seguintes dependências a ele:

    <dependency>
        <groupId>com.microsoft.azure</groupId>
        <artifactId>applicationinsights-spring-boot-starter</artifactId>
        <version>2.5.0</version>
    </dependency>
    
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-spring-legacy</artifactId>
        <version>1.1.0</version>
    </dependency>
    
    <dependency>
        <groupId>io.micrometer</groupId>
        <artifactId>micrometer-registry-azure-monitor</artifactId>
        <version>1.1.0</version>
    </dependency>
    
    
  2. Atualize o arquivo application.properties ou YML com a chave de instrumentação do Application Insights usando a seguinte propriedade:

    azure.application-insights.instrumentation-key=<your-instrumentation-key-here>

  3. Crie seu aplicativo e execute-o.

As etapas anteriores devem deixar você pronto com métricas pré-agregadas coletadas automaticamente no Azure Monitor.

Use o Spring 2.x

Adicione as seguintes dependências ao pom.xml ou build.gradle:

Siga estas etapas:

  1. Atualize o arquivo pom.xml do aplicativo Spring Boot e adicione a seguinte dependência a ele:

    <dependency> 
          <groupId>com.microsoft.azure</groupId>
          <artifactId>azure-spring-boot-metrics-starter</artifactId>
          <version>2.0.7</version>
    </dependency>
    
  2. Atualize o arquivo application.properties ou YML com a chave de instrumentação do Application Insights usando a seguinte propriedade:

    azure.application-insights.instrumentation-key=<your-instrumentation-key-here>

  3. Crie seu aplicativo e execute-o.

As etapas anteriores devem fazer você entrar em operação com métricas pré-agregadas coletadas automaticamente no Azure Monitor. Para obter mais informações sobre como fazer ajustes no starter Spring Boot do Application Insights, consulte o leiame no GitHub.

Métricas padrão:

  • Métricas configuradas automaticamente para Tomcat, JVM, Métricas de Logback, Métricas do Log4J, Métricas de Tempo de Atividade, Métricas do Processador e FileDescriptorMetrics.
  • Por exemplo, se o Netflix Hystrix estiver presente no class path, também obteremos essas métricas.
  • As seguintes métricas podem estar disponíveis adicionando os respectivos feijões:
    • CacheMetrics (CaffeineCache, EhCache2, GuavaCache, HazelcastCachee JCache)
    • DataBaseTableMetrics
    • HibernateMetrics
    • JettyMetrics
    • OkHttp3 Métricas
    • Kafka Métricas

Desativar a coleção automática de métricas:

  • Métricas de JVM:
    • management.metrics.binders.jvm.enabled=false
  • Métricas de logback:
    • management.metrics.binders.logback.enabled=false
  • Métricas de tempo de atividade:
    • management.metrics.binders.uptime.enabled=false
  • Métricas do processador:
    • management.metrics.binders.processor.enabled=false
  • FileDescriptorMetrics:
    • management.metrics.binders.files.enabled=false
  • Métricas do Hystrix se a biblioteca estiver em classpath:
    • management.metrics.binders.hystrix.enabled=false
  • Métricas de AspectJ se biblioteca em classpath:
    • spring.aop.enabled=false

Observação

Especifique as propriedades anteriores no arquivo application.properties ou application.yml do aplicativo Spring Boot.

Usar o Micrometer com aplicativos Web que não são do Spring Boot

Adicione as seguintes dependências ao arquivo pom.xml ou ao build.gradle :

Siga estas etapas:

  1. Adicione as seguintes dependências no pom.xml ou build.gradle:

        <dependency>
            <groupId>io.micrometer</groupId>
            <artifactId>micrometer-registry-azure-monitor</artifactId>
            <version>1.1.0</version>
        </dependency>
    
        <dependency>
            <groupId>com.microsoft.azure</groupId>
            <artifactId>applicationinsights-web-auto</artifactId>
            <version>2.5.0</version>
        </dependency>
    
  2. Se você ainda não fez isso, adicione o arquivo ApplicationInsights.xml na pasta de recursos. Para obter mais informações, consulte Adicionar um arquivo ApplicationInsights.xml.

  3. Classe Servlet de exemplo (emite uma métrica de temporizador):

        @WebServlet("/hello")
        public class TimedDemo extends HttpServlet {
    
          private static final long serialVersionUID = -4751096228274971485L;
    
          @Override
          @Timed(value = "hello.world")
          protected void doGet(HttpServletRequest request, HttpServletResponse response)
              throws ServletException, IOException {
    
            response.getWriter().println("Hello World!");
            MeterRegistry registry = (MeterRegistry) getServletContext().getAttribute("AzureMonitorMeterRegistry");
    
        //create new Timer metric
            Timer sampleTimer = registry.timer("timer");
            Stream<Integer> infiniteStream = Stream.iterate(0, i -> i+1);
            infiniteStream.limit(10).forEach(integer -> {
              try {
                Thread.sleep(1000);
                sampleTimer.record(integer, TimeUnit.MILLISECONDS);
              } catch (Exception e) {}
               });
          }
          @Override
          public void init() throws ServletException {
            System.out.println("Servlet " + this.getServletName() + " has started");
          }
          @Override
          public void destroy() {
            System.out.println("Servlet " + this.getServletName() + " has stopped");
          }
    
        }
    
    
  4. Classe de configuração de exemplo:

         @WebListener
         public class MeterRegistryConfiguration implements ServletContextListener {
    
           @Override
           public void contextInitialized(ServletContextEvent servletContextEvent) {
    
         // Create AzureMonitorMeterRegistry
           private final AzureMonitorConfig config = new AzureMonitorConfig() {
             @Override
             public String get(String key) {
                 return null;
             }
            @Override
               public Duration step() {
                 return Duration.ofSeconds(60);}
    
             @Override
             public boolean enabled() {
                 return false;
             }
         };
    
      MeterRegistry azureMeterRegistry = AzureMonitorMeterRegistry.builder(config);
    
             //set the config to be used elsewhere
             servletContextEvent.getServletContext().setAttribute("AzureMonitorMeterRegistry", azureMeterRegistry);
    
           }
    
           @Override
           public void contextDestroyed(ServletContextEvent servletContextEvent) {
    
           }
         }
    

Para saber mais sobre métricas, consulte a documentação do Micrometer.

Outros códigos de exemplo sobre como criar diferentes tipos de métricas podem ser encontrados no repositório oficial do GitHub do Micrometer.

Associar mais coleções de métricas

As seções a seguir mostram como coletar mais métricas.

SpringBoot/Spring

Crie um bean da respectiva categoria de métrica. Por exemplo, digamos que você precise de métricas do Guava Cache:

    @Bean
    GuavaCacheMetrics guavaCacheMetrics() {
        Return new GuavaCacheMetrics();
    }

Várias métricas não são habilitadas por padrão, mas podem ser associadas da maneira anterior. Para obter uma lista completa, consulte o repositório GitHub do Micrometer.

Aplicativos que não são spring

Adicione o seguinte código de associação ao arquivo de configuração:

    New GuavaCacheMetrics().bind(registry);

API principal para eventos e métricas personalizados

Insira algumas linhas de código em seu aplicativo para descobrir o que os usuários estão fazendo com ele ou para ajudar a diagnosticar problemas. Você pode enviar telemetria de aplicativos de dispositivo e desktop, clientes Web e servidores Web. Use a API de telemetria principal do Application Insights para enviar eventos e métricas personalizados e suas próprias versões da telemetria padrão. Essa API é a mesma API que os coletores de dados padrão do Application Insights usam.

Resumo da API

A API principal é uniforme em todas as plataformas, além de algumas variações como GetMetric (somente .NET).

Método Usado para
TrackPageView Páginas, telas, painéis ou formulários.
TrackEvent Ações do usuário e outros eventos. Usado para acompanhar o comportamento do usuário ou monitorar o desempenho.
TrackMetric Medidas de desempenho, como comprimentos de fila não relacionados a eventos específicos.
TrackException Registro de exceções para diagnóstico. Rastreie onde eles ocorrem em relação a outros eventos e examine os rastreamentos de pilha.
TrackRequest Registrando em log a frequência e a duração das solicitações de servidor para análise de desempenho.
TrackTrace Mensagens de log de Diagnóstico de Recursos. Você também pode capturar logs de terceiros.
TrackDependency Registrar em log a duração e a frequência das chamadas para componentes externos dos quais seu aplicativo depende.

Você pode anexar propriedades e métricas à maioria dessas chamadas de telemetria.

Pré-requisitos

Se você ainda não possui uma referência ao SDK do Application Insights:

  • Adicione o SDK do Application Insights ao seu projeto.

  • No código do dispositivo ou servidor Web, inclua:

    import com.microsoft.applicationinsights.TelemetryClient;
    

Obter uma instância do TelemetryClient

Obter uma instância de TelemetryClient:

private TelemetryClient telemetry = new TelemetryClient();

TelemetryClient é thread-safe.

Observação

Se você usar o Azure Functions v2+ ou o Azure WebJobs v3+, consulte Monitorar o Azure Functions.

Talvez você queira criar mais instâncias de TelemetryClient para outros módulos do seu aplicativo. Por exemplo, você pode ter uma TelemetryClient instância em sua classe middleware para relatar eventos de lógica de negócios. Você pode definir propriedades como UserId e DeviceId identificar o computador. Essas informações são anexadas a todos os eventos que a instância envia.

telemetry.getContext().getUser().setId("...");
telemetry.getContext().getDevice().setId("...");

TrackEvent

No Application Insights, um evento personalizado é um ponto de dados que você pode exibir no Metrics Explorer como uma contagem agregada e na Pesquisa de Diagnóstico como ocorrências individuais. (Não está relacionado ao MVC ou a outros "eventos") da estrutura.

Insira TrackEvent chamadas em seu código para contar vários eventos. Por exemplo, talvez você queira acompanhar a frequência com que os usuários escolhem um recurso específico. Ou talvez você queira saber com que frequência eles atingem determinadas metas ou cometem tipos específicos de erros.

Por exemplo, em um aplicativo de jogo, envie um evento sempre que um usuário ganhar o jogo:

telemetry.trackEvent("WinGame");

Eventos personalizados no Log Analytics

A telemetria está disponível na customEvents tabela na guia Logs do Application Insights ou na experiência de uso. Os eventos podem vir do trackEvent(..) ou do plug-in de coleta automática do Click Analytics.

Se a amostragem estiver em operação, a itemCount propriedade mostrará um valor maior que 1. Por exemplo, itemCount==10 significa que, de 10 chamadas para trackEvent(), o processo de amostragem transmitiu apenas uma delas. Para obter uma contagem correta de eventos personalizados, use código como customEvents | summarize sum(itemCount).

Observação

itemCount tem um valor mínimo de um; o registro em si representa uma entrada.

TrackMetric

O Application Insights pode mapear métricas que não estão anexadas a eventos específicos. Por exemplo, você pode monitorar um comprimento de fila em intervalos regulares. Com as métricas, as medidas individuais são de menor interesse do que as variações e tendências e, portanto, os gráficos estatísticos são úteis.

Para enviar métricas para o Application Insights, você pode usar a TrackMetric(..) API. Há duas maneiras de enviar uma métrica:

  • Valor único. Sempre que você executa uma medida em seu aplicativo, envia o valor correspondente para o Application Insights.

    Por exemplo, suponha que você tenha uma métrica que descreva o número de itens em um contêiner. Durante um período de tempo específico, primeiro você coloca três itens no contêiner e, em seguida, remove dois itens. Assim, você ligaria TrackMetric duas vezes. Primeiro, você passaria o valor 3 e, em seguida, passaria o valor -2. O Application Insights armazena os dois valores para você.

  • Agregação. Quando você trabalha com métricas, cada medida raramente é de interesse. Em vez disso, um resumo do que aconteceu durante um determinado período de tempo é importante. Chamamos essa síntese de agregação.

    No exemplo anterior, a soma da métrica de agregação para esse período de tempo é 1 e a contagem dos valores de métrica é 2. Ao usar a abordagem de agregação, você invoca TrackMetric apenas uma vez por período de tempo e envia os valores agregados. Recomendamos essa abordagem porque ela pode reduzir significativamente a sobrecarga de custo e desempenho enviando menos pontos de dados para o Application Insights, enquanto ainda coleta todas as informações relevantes.

Exemplos de valor único

Para enviar um único valor de métrica:

telemetry.trackMetric("queueLength", 42.0);

Métricas personalizadas no Log Analytics

A telemetria está disponível na tabela no customMetricsApplication Insights Analytics. Cada linha representa uma chamada em trackMetric(..) seu aplicativo.

  • valueSum: a soma das medidas. Para obter o valor médio, divida por valueCount.
  • valueCount: o número de medições que foram agregadas nesta trackMetric(..) chamada.

Observação

valueCount tem um valor mínimo de um; o registro em si representa uma entrada.

Exibições de página

Em um aplicativo ou página da Web, a telemetria de exibição de página é enviada por padrão quando cada tela ou página é carregada. Mas você pode alterar o padrão para acompanhar exibições de página em momentos mais ou diferentes. Por exemplo, em um aplicativo que exibe guias ou painéis, talvez você queira rastrear uma página sempre que o usuário abrir um novo painel.

Os dados do usuário e da sessão são enviados como propriedades, juntamente com exibições de página, para que os gráficos de usuário e de sessão ganhem vida quando houver telemetria de exibição de página.

Exibições de página personalizadas

telemetry.trackPageView("GameReviewPage");

Telemetria de página no Log Analytics

No Log Analytics, duas tabelas mostram dados das operações do navegador:

  • pageViews: contém dados sobre a URL e o título da página.
  • browserTimings: contém dados sobre o desempenho do cliente, como o tempo necessário para processar os dados de entrada.

Para descobrir quanto tempo o navegador leva para processar páginas diferentes:

browserTimings
| summarize avg(networkDuration), avg(processingDuration), avg(totalDuration) by name

Para descobrir a popularidade de navegadores diferentes:

pageViews
| summarize count() by client_Browser

Para associar exibições de página a chamadas AJAX, conecte com dependências:

pageViews
| join (dependencies) on operation_Id

TrackRequest

O SDK do servidor usa TrackRequest para logar requisições HTTP.

Você também pode chamá-lo por conta própria se quiser simular solicitações em um contexto em que não tenha o módulo de serviço Web em execução.

A maneira recomendada de enviar telemetria de solicitação é onde a solicitação atua como um contexto de operação.

Contexto da operação

Você pode correlacionar itens de telemetria ao associá-los ao contexto da operação. O módulo de acompanhamento de solicitações padrão faz isso para exceções e outros eventos que são enviados enquanto uma solicitação HTTP está sendo processada. Em Pesquisa e Análise, você pode encontrar facilmente todos os eventos associados à solicitação usando sua ID de operação.

Os itens de telemetria relatados dentro de um escopo de operação passam a ser considerados como parte dessa operação. Contextos de operação podem ser aninhados.

Na Pesquisa, o contexto da operação é usado para criar a lista Itens Relacionados .

Captura de tela que mostra a lista Itens Relacionados.

Solicitações no Log Analytics

No Application Insights Analytics, as solicitações aparecem na requests tabela.

Se a amostragem estiver em operação, a itemCount propriedade mostrará um valor maior que 1. Por exemplo, itemCount==10 significa que, de 10 chamadas para trackRequest(), o processo de amostragem transmitiu apenas uma delas. Para obter uma contagem correta de solicitações e duração média segmentada por nomes de solicitação, use código como:

requests
| summarize count = sum(itemCount), avgduration = avg(duration) by name

TrackException

Enviar exceções ao Application Insights:

Os relatórios incluem os rastreamentos de pilha.

try {
    ...
} catch (Exception ex) {
    telemetry.trackException(ex);
}

As exceções são capturadas automaticamente, portanto, nem sempre é necessário chamar TrackException explicitamente.

Exceções no Log Analytics

No Application Insights Analytics, as exceções aparecem na exceptions tabela.

Se a amostragem estiver em operação, a itemCount propriedade mostrará um valor maior que 1. Por exemplo, itemCount==10 significa que, de 10 chamadas para trackException(), o processo de amostragem transmitiu apenas uma delas. Para obter uma contagem correta de exceções segmentada por tipo de exceção, use código como:

exceptions
| summarize sum(itemCount) by type

A maioria das informações de pilha importantes já é extraída em variáveis separadas, mas você pode separar a details estrutura para obter mais. Como essa estrutura é dinâmica, você deve converter o resultado para o tipo esperado. Por exemplo:

exceptions
| extend method2 = tostring(details[0].parsedStack[1].method)

Para associar exceções às solicitações relacionadas, use uma junção:

exceptions
| join (requests) on operation_Id

TrackTrace

Use TrackTrace para ajudar a diagnosticar problemas enviando uma "trilha de navegação" para Application Insights. Você pode enviar partes de dados de diagnóstico e inspecioná-los na Pesquisa de Diagnóstico.

Observação

Em Java, o agente Java do Application Insights se conecta automaticamente e envia logs para o portal.

telemetry.trackTrace(message, SeverityLevel.Warning, properties);

Registre um evento de diagnóstico, como entrar ou sair de um método.

Parâmetro Description
message Dados de diagnóstico. Pode ser muito mais longo do que um nome.
properties Mapa de string para string. Mais dados são usados para filtrar exceções no portal. O padrão é vazio.
severityLevel Valores com suporte: SeverityLevel.ts.

Você pode pesquisar no conteúdo da mensagem, mas ao contrário dos valores de propriedade, não é possível filtrar nele.

O limite de tamanho para message é muito maior do que o limite de propriedades. Uma vantagem de TrackTrace é que você pode colocar dados relativamente longos na mensagem. Por exemplo, você pode codificar dados POST lá.

Você também pode adicionar um nível de severidade à sua mensagem. E, assim como outra telemetria, você pode adicionar valores de propriedade para ajudá-lo a filtrar ou pesquisar diferentes conjuntos de traços. Por exemplo:

Map<String, Integer> properties = new HashMap<>();
properties.put("Database", db.ID);
telemetry.trackTrace("Slow Database response", SeverityLevel.Warning, properties);

Na Pesquisa, você pode filtrar facilmente todas as mensagens de um nível de severidade específico relacionado a um banco de dados específico.

Rastreamentos no Log Analytics

No Application Insights Analytics, as chamadas para TrackTrace aparecem na tabela traces.

Se a amostragem estiver em operação, a itemCount propriedade mostrará um valor maior que 1. Por exemplo, itemCount==10 significa que, de 10 chamadas para trackTrace(), o processo de amostragem transmitiu apenas uma delas. Para obter uma contagem correta de chamadas de rastreamento, use código como traces | summarize sum(itemCount).

TrackDependency

Use a TrackDependency chamada para acompanhar os tempos de resposta e as taxas de êxito das chamadas para uma parte externa do código. Os resultados aparecem nos gráficos de dependência no portal. O snippet de código a seguir deve ser adicionado sempre que houver uma chamada de dependência.

boolean success = false;
Instant startTime = Instant.now();
try {
    success = dependency.call();
}
finally {
    Instant endTime = Instant.now();
    Duration delta = Duration.between(startTime, endTime);
    RemoteDependencyTelemetry dependencyTelemetry = new RemoteDependencyTelemetry("My Dependency", "myCall", delta, success);
    dependencyTelemetry.setTimeStamp(startTime);
    telemetry.trackDependency(dependencyTelemetry);
}

Observação

No Java, muitas chamadas de dependência podem ser rastreadas automaticamente usando o Java agent do Application Insights.

Você usará essa chamada se quiser acompanhar as chamadas que o acompanhamento automatizado não captura.

Dependências no Log Analytics

No Application Insights Analytics, chamadas aparecem na tabela .

Se a amostragem estiver em operação, a itemCount propriedade mostrará um valor maior que 1. Por exemplo, itemCount==10 significa que, de 10 chamadas para trackDependency(), o processo de amostragem transmitiu apenas uma delas. Para obter uma contagem correta de dependências segmentadas pelo componente de destino, use código como:

dependencies
| summarize sum(itemCount) by target

Para associar dependências às solicitações relacionadas, use uma junção:

dependencies
| join (requests) on operation_Id

Liberando dados

Normalmente, o SDK envia dados em intervalos fixos, normalmente 30 segundos ou sempre que o buffer está cheio, que normalmente é de 500 itens. Em alguns casos, talvez você queira liberar o buffer. Um exemplo é se você está usando o SDK em um aplicativo que é desligado.

telemetry.flush();
//Allow some time for flushing before shutting down
Thread.sleep(5000);

Observação

O SDK do Java realiza uma limpeza automaticamente ao encerramento do aplicativo.

Usuários autenticados

Por padrão, em um aplicativo web, os usuários são identificados com cookies. Um usuário poderá ser contado mais de uma vez se acessar seu aplicativo de um computador ou navegador diferente ou se excluir cookies.

Se os usuários entrarem em seu aplicativo, você poderá obter uma contagem mais precisa definindo a ID de usuário autenticada no código do navegador. Não é necessário usar o nome de entrada real do usuário. Ele só precisa ser um ID exclusivo para esse usuário. Ele não deve incluir espaços nem nenhum dos caracteres ,;=|.

A ID do usuário também é definida em um cookie de sessão e enviada para o servidor. Se o SDK do servidor estiver instalado, a ID de usuário autenticada será enviada como parte das propriedades de contexto da telemetria do cliente e do servidor. Em seguida, você pode filtrar e pesquisar nele.

Se o aplicativo agrupar usuários em contas, você também poderá passar um identificador para a conta. As mesmas restrições de caractere se aplicam.

No Metrics Explorer, você pode criar um gráfico que conta Usuários Autenticados e Contas de Usuários.

Você também pode pesquisar pontos de dados do cliente com nomes de usuário e contas específicas.

Filtrar, pesquisar e segmentar seus dados usando propriedades

Você pode anexar propriedades e medidas a seus eventos, métricas, exibições de página, exceções e outros dados de telemetria.

As propriedades são valores de cadeia de caracteres que você pode usar para filtrar sua telemetria nos relatórios de uso. Por exemplo, se seu aplicativo fornecer vários jogos, você poderá anexar o nome do jogo a cada evento para que você possa ver quais jogos são mais populares.

Há um limite de 8.192 no comprimento da cadeia de caracteres. Se você quiser enviar grandes partes de dados, use o parâmetro de mensagem de TrackTrace.

As métricas são valores numéricos que podem ser apresentados graficamente. Por exemplo, talvez você queira ver se há um aumento gradual nas pontuações que seus jogadores alcançam. Os grafos podem ser segmentados pelas propriedades enviadas com o evento para que você possa obter grafos separados ou empilhados para jogos diferentes.

Os valores de métrica devem ser maiores ou iguais a 0 para serem exibidos corretamente.

Há alguns limites no número de propriedades, valores de propriedade e métricas que você pode usar.

Map<String, String> properties = new HashMap<String, String>();
properties.put("game", currentGame.getName());
properties.put("difficulty", currentGame.getDifficulty());

Map<String, Double> metrics = new HashMap<String, Double>();
metrics.put("Score", currentGame.getScore());
metrics.put("Opponents", currentGame.getOpponentCount());

telemetry.trackEvent("WinGame", properties, metrics);

Importante

Verifique se você não registra informações de identificação pessoal nas propriedades.

Aviso

Não reutilize a mesma instância de item de telemetria (event neste exemplo) para chamar Track*() várias vezes. Essa prática pode fazer com que a telemetria seja enviada com configuração incorreta.

Medidas e propriedades personalizadas no Log Analytics

No Log Analytics, as métricas e propriedades personalizadas aparecem nos atributos customMeasurements e customDimensions de cada registro de telemetria.

Por exemplo, se você adicionar uma propriedade chamada "game" à telemetria de requisição, essa consulta conta as ocorrências de diferentes valores de "game" e mostra a média da métrica personalizada "score".

requests
| summarize sum(itemCount), avg(todouble(customMeasurements.score)) by tostring(customDimensions.game)

Observe que:

  • Quando você extrai um valor do customDimensions ou customMeasurements JSON, ele tem um tipo dinâmico, portanto, você deve convertê-lo ou fazer casting para tostring ou todouble.
  • Para levar em conta a possibilidade de amostragem, use sum(itemCount) não count().

Eventos de temporização

Às vezes, você deseja mapear quanto tempo leva para executar uma ação. Por exemplo, talvez você queira saber quanto tempo os usuários levam para considerar as opções em um jogo. Para obter essas informações, use o parâmetro de medida.

long startTime = System.currentTimeMillis();

// Perform timed action

long endTime = System.currentTimeMillis();
Map<String, Double> metrics = new HashMap<>();
metrics.put("ProcessingTime", (double)endTime-startTime);

// Setup some properties
Map<String, String> properties = new HashMap<>();
properties.put("signalSource", currentSignalSource.getName());

// Send the event
telemetry.trackEvent("SignalProcessed", properties, metrics);

Propriedades padrão para telemetria personalizada

Se você quiser definir valores de propriedade padrão para alguns dos eventos personalizados que você escreve, defina-os em uma TelemetryClient instância. Eles são anexados a todos os itens de telemetria enviados desse cliente.

import com.microsoft.applicationinsights.TelemetryClient;
import com.microsoft.applicationinsights.TelemetryContext;
...

TelemetryClient gameTelemetry = new TelemetryClient();
TelemetryContext context = gameTelemetry.getContext();
context.getProperties().put("Game", currentGame.Name);

gameTelemetry.TrackEvent("WinGame");

Chamadas de telemetria individuais podem substituir os valores padrão em seus dicionários de propriedades.

Desabilitar telemetria

Para interromper e iniciar dinamicamente a coleção e a transmissão da telemetria:

telemetry.getConfiguration().setTrackingDisabled(true);

Cadeia de conexão dinâmica

Para evitar misturar a telemetria de ambientes de desenvolvimento, teste e produção, você pode criar recursos separados do Application Insights e alterar suas cadeias de conexão, dependendo do ambiente.

Em vez de obter a cadeia de conexão do arquivo de configuração, você pode defini-la no método de inicialização do código:

// Initialize once, e.g., at startup
TelemetryClient telemetry = new TelemetryClient();

// Prefer env var; falls back to hard-coded for illustration
String cs = System.getenv("APPLICATIONINSIGHTS_CONNECTION_STRING");
if (cs != null && !cs.isEmpty()) {
    telemetry.getContext().setConnectionString(cs);
}

TelemetryContext

TelemetryClient tem uma propriedade Context, que contém valores que são enviados junto com todos os dados de telemetria. Eles normalmente são definidos pelos módulos de telemetria padrão, mas você também pode defini-los por conta própria. Por exemplo:

telemetry.Context.Operation.Name = "MyOperationName";

Se você definir qualquer um desses valores por conta própria, considere remover a linha relevante de ApplicationInsights.config para que seus valores e os valores padrão não fiquem confusos.

  • Componente: o aplicativo e sua versão.
  • Dispositivo: dados sobre o dispositivo em que o aplicativo está sendo executado. Em aplicativos Web, é o servidor ou o dispositivo cliente que envia telemetria.
  • InstrumentationKey: o recurso Application Insights no Azure em que a telemetria é exibida.
  • Local: a localização geográfica do dispositivo.
  • Operação: em aplicativos Web, a solicitação HTTP atual. Em outros tipos de aplicativo, você pode definir esse valor para agrupar eventos.
    • ID: um valor gerado que correlaciona eventos diferentes para que, ao inspecionar qualquer evento na Pesquisa de Diagnóstico, você possa encontrar itens relacionados.
    • Nome: um identificador, geralmente a URL da solicitação HTTP.
    • SyntheticSource: se não for nulo ou vazio, uma cadeia de caracteres que indica que a origem da solicitação foi identificada como um teste de robô ou web. Por padrão, ele é excluído dos cálculos no Metrics Explorer.
  • Sessão: a sessão do usuário. A ID é definida como um valor gerado, que é alterado quando o usuário não está ativo há algum tempo.
  • Usuário: Informações do usuário.

Limits

Há alguns limites quanto ao número de métricas e eventos por aplicativo, ou seja, por chave de instrumentação. Os limites dependem do plano de preços que você escolher.

Resource Limite padrão Limite máximo Anotações
Total de dados por dia 100 GB Fale com o suporte. Você pode definir um limite para reduzir os dados. Caso precise de mais dados, você pode aumentar o limite no portal, até 1.000 GB. Para capacidades maiores que 1.000 GB, envie um email para AIDataCap@microsoft.com.
Throttling 32.000 eventos por segundo Fale com o suporte. O limite é medido em um minuto.
Logs de retenção de dados De 30 a 730 dias 730 dias Este recurso é para Logs.
Métricas de retenção de dados 90 dias 90 dias Este recurso é para Metrics Explorer.
Retenção de resultados detalhados do Teste de disponibilidade em várias etapas 90 dias 90 dias Esse recurso fornece resultados detalhados de cada etapa.
Tamanho máximo do item de telemetria 64 KB 64 KB
Máximo de itens de telemetria por lote 64.000 64.000
Tamanho dos nomes de propriedade e métrica 150 150 Veja esquemas de tipo.
Tamanho da cadeia de caracteres do valor da propriedade 8,192 8,192 Veja esquemas de tipo.
Comprimento da mensagem de rastreamento e de exceção 32,768 32,768 Veja esquemas de tipo.
Contagem de testes de disponibilidade por recurso do Application Insights 100 100
Contagem de testes de disponibilidade por grupo de recursos 800 800 Consulte Azure Resource Manager
Máximo de redirecionamentos por teste de testes de disponibilidade 10 10
Testes de disponibilidade frequência mínima de teste 300 segundos Frequências de teste personalizadas ou inferiores a cinco minutos requerem implementações TrackAvailability personalizadas.
Retenção de dados do .NET Profiler e do Depurador de Instantâneos Duas semanas Entre em contato com o suporte. O limite máximo de retenção é de seis meses.
Dados do .NET Profiler enviados por dia Sem limite Não há limite.
Dados do Depurador de Instantâneos enviados por dia 30 instantâneos por dia por aplicativo monitorado Não há limite. O número de instantâneos coletados por aplicativo pode ser modificado por meio da configuração.

Para obter mais informações sobre preços e cotas, confira Cobrança do Application Insights.

Para evitar atingir o limite de taxa de dados, use amostragem.

Para determinar por quanto tempo os dados são mantidos, consulte Retenção de dados e privacidade.

Próximas etapas