Opções de configuração: Azure Monitor Application Insights para Java

Este artigo mostra como configurar o Azure Monitor Application Insights para Java.

Cadeia de conexão e nome da função

Para começar, as configurações necessárias mais comuns são a cadeia de conexão e o nome da função:

{
  "connectionString": "...",
  "role": {
    "name": "my cloud role name"
  }
}

A Cadeia de Conexão é necessária. O nome da função é sempre importante ao enviar dados de aplicativos diferentes para o mesmo recurso do Application Insights.

Mais informações e opções de configuração são fornecidas nas seções a seguir.

Caminho do arquivo de configuração

Por padrão, o Application Insights Java 3.x espera que o arquivo de configuração seja nomeado applicationinsights.json e esteja localizado no mesmo diretório que applicationinsights-agent-3.5.2.jar.

É possível especificar seu próprio caminho de arquivo de configuração usando uma destas duas opções:

• A variável de ambiente APPLICATIONINSIGHTS_CONFIGURATION_FILE
• applicationinsights.configuration.filePropriedade do sistema Java

Se você especificar um caminho relativo, ele será resolvido em relação ao diretório em que applicationinsights-agent-3.5.2.jar está localizado.

Como alternativa, em vez de usar um arquivo de configuração, é possível especificar todo o conteúdo da configuração JSON por meio da variável de ambiente APPLICATIONINSIGHTS_CONFIGURATION_CONTENT.

Cadeia de conexão

A Cadeia de Conexão é necessária. É possível encontrar a cadeia de conexão no recurso do Application Insights.

{
  "connectionString": "..."
}

Também é possível defini-la usando a variável de ambiente APPLICATIONINSIGHTS_CONNECTION_STRING. Em seguida, ela terá precedência sobre a cadeia de conexão especificada na configuração JSON.

Ou você pode definir a cadeia de conexão usando a propriedade do sistema Java applicationinsights.connection.string. Em seguida, ela terá precedência sobre a cadeia de conexão especificada na configuração JSON.

Você também pode definir a cadeia de conexão especificando um arquivo do qual carregar a cadeia de conexão.

Se você especificar um caminho relativo, ele será resolvido em relação ao diretório em que applicationinsights-agent-3.5.2.jar está localizado.

{
  "connectionString": "${file:connection-string-file.txt}"
}

O arquivo deve conter apenas a cadeia de conexão e mais nada.

Não configurar a cadeia de conexão desabilita o agente Java.

Se você tiver vários aplicativos implantados na mesma JVM (Máquina Virtual Java) e quiser que eles enviem telemetria para diferentes cadeias de conexão, confira Substituições de cadeia de conexão (versão prévia).

Nome da função de nuvem

O nome da função de nuvem é usado para rotular o componente no mapa do aplicativo.

Se você quiser definir o nome da função de nuvem:

{
  "role": {   
    "name": "my cloud role name"
  }
}

Se o nome da função de nuvem não estiver definido, o nome do recurso do Application Insights será usado para rotular o componente no mapa do aplicativo.

Você também pode definir o nome da função de nuvem usando a variável de ambiente APPLICATIONINSIGHTS_ROLE_NAME. Em seguida, ele terá precedência sobre o nome da função de nuvem especificado na configuração JSON.

Também é possível definir o nome da função de nuvem usando a propriedade do sistema Java applicationinsights.role.name. Ele também terá precedência sobre o nome da função de nuvem especificado na configuração JSON.

Se você tiver vários aplicativos implantados na mesma JVM e quiser que eles enviem telemetria para diferentes nomes de função de nuvem, confira Substituições de nome de função de nuvem (versão prévia).

Instância de função de nuvem

A instância da função de nuvem assume como padrão o nome do computador.

Se você quiser definir a instância de função de nuvem para algo diferente, em vez do nome da máquina:

{
  "role": {
    "name": "my cloud role name",
    "instance": "my cloud role instance"
  }
}

Também é possível definir a instância da função de nuvem usando a variável de ambiente APPLICATIONINSIGHTS_ROLE_INSTANCE. Em seguida, ela terá precedência sobre a instância da função de nuvem especificada na configuração JSON.

Também é possível definir a instância da função de nuvem usando a propriedade do sistema Java applicationinsights.role.instance. Ela também terá precedência sobre a instância da função de nuvem especificada na configuração JSON.

amostragem

Observação

A amostragem pode ser uma ótima maneira de reduzir o custo do Application Insights. Defina sua configuração de amostragem adequadamente para o caso de uso.

Como a amostragem é baseada em solicitação, se uma solicitação for capturada (amostrada), o mesmo ocorrerá com as respectivas dependências, logs e exceções.

Ela também é baseada na ID de rastreamento para ajudar a garantir decisões de amostragem consistentes em diferentes serviços.

A amostragem só se aplica aos logs dentro de uma solicitação. Os logs que não estão dentro de uma solicitação (por exemplo, logs de inicialização) são sempre coletados por padrão. Se você quiser amostrar esses logs, poderá usar substituições de amostragem.

Amostragem limitada por taxa

A partir da 3.4.0, a amostragem limitada por taxa está disponível e agora é o padrão.

Se não houver amostragem configurada, o padrão agora é a amostragem com taxa limitada, configurada para capturar no máximo (aproximadamente) cinco solicitações por segundo, juntamente com todas as dependências e registros dessas solicitações.

Essa configuração substitui o padrão anterior, que era capturar todas as solicitações. Paa capturar todas as solicitações, use a amostragem de porcentagem fixa e defina a porcentagem de amostragem como 100.

Observação

A amostragem limitada por taxa é aproximada porque, internamente, ela deve adaptar uma porcentagem de amostragem "fixa" ao longo do tempo para emitir contagens de itens precisas em cada registro de telemetria. Internamente, ela é ajustada para se adaptar rapidamente (0,1 segundos) a novas cargas de aplicativos. Por isso, ela não deve exceder a taxa configurada demasiadamente ou por muito tempo.

Este exemplo mostra como definir a amostragem para capturar no máximo (aproximadamente) uma solicitação por segundo:

{
  "sampling": {
    "requestsPerSecond": 1.0
  }
}

O requestsPerSecond pode ser um decimal, portanto, você pode configurá-lo para capturar menos de uma solicitação por segundo, se quiser. Por exemplo, um valor de 0.5 significa a captura de no máximo uma solicitação a cada dois segundos.

Também é possível definir a porcentagem de amostragem usando a variável de ambiente APPLICATIONINSIGHTS_SAMPLING_REQUESTS_PER_SECOND. Em seguida, ela terá precedência sobre a limitação de taxa especificada na configuração JSON.

Amostragem de porcentagem fixa

Este exemplo mostra como definir a amostragem para capturar aproximadamente um terço de todas as solicitações:

{
  "sampling": {
    "percentage": 33.333
  }
}

Também é possível definir a porcentagem de amostragem usando a variável de ambiente APPLICATIONINSIGHTS_SAMPLING_PERCENTAGE. Em seguida, ela terá precedência sobre a porcentagem de amostragem especificada na configuração JSON.

Observação

Para a porcentagem de amostragem, escolha uma porcentagem próxima de 100/N, em que N é um número inteiro. Atualmente, a amostragem não dá suporte a outros valores.

Substituições de amostragem

As substituições de amostragem permitem substituir a porcentagem de amostragem padrão. Por exemplo, você pode:

• Defina a porcentagem de amostragem como 0 (ou algum valor pequeno) para verificações de integridade com ruído.
• Defina a porcentagem de amostragem como 0 (ou algum valor pequeno) para chamadas de dependência com ruído.
• Defina a porcentagem de amostragem como 100 para um tipo de solicitação importante. Por exemplo, é possível usar /login mesmo com a amostragem padrão configurada para algo menor.

Para saber mais, confira a documentação Substituições de amostragem.

Métricas do Java Management Extensions

Se você quiser coletar algumas outras métricas do JMX (Java Management Extensions):

{
  "jmxMetrics": [
    {
      "name": "JVM uptime (millis)",
      "objectName": "java.lang:type=Runtime",
      "attribute": "Uptime"
    },
    {
      "name": "MetaSpace Used",
      "objectName": "java.lang:type=MemoryPool,name=Metaspace",
      "attribute": "Usage.used"
    }
  ]
}

No exemplo de configuração anterior:

• name é o nome da métrica que é atribuída a essa métrica JMX (pode ser qualquer coisa).
• objectName é o Nome do objeto do JMX MBean que você quer coletar. Há suporte para o asterisco de caractere curinga (*).
• attribute é o nome do atributo no JMX MBean que você quer coletar.

Os valores de métrica JMX numéricos e boolianos são compatíveis. As métricas JMX boolianas são mapeadas para 0 no caso de false e para 1 no caso de true.

Para obter mais informações, consulte a documentação de métricas da JMX.

Dimensões Personalizadas

Para adicionar dimensões personalizadas a toda a sua telemetria:

{
  "customDimensions": {
    "mytag": "my value",
    "anothertag": "${ANOTHER_VALUE}"
  }
}

É possível usar ${...} para ler o valor da variável de ambiente especificada na inicialização.

Observação

A partir da 3.0.2, se você adicionar uma dimensão personalizada service.version, o valor será armazenado na coluna application_Version da tabela “Logs” do Application Insights em vez de em uma dimensão personalizada.

Atributo herdado (versão prévia)

Começando com a versão 3.2.0, você pode definir uma dimensão personalizada de forma programática na sua telemetria de solicitação. Ele garante a herança por dependência e telemetria de log. Todos são capturados no contexto dessa solicitação.

{
  "preview": {
    "inheritedAttributes": [
      {
        "key": "mycustomer",
        "type": "string"
      }
    ]
  }
}

Em seguida, no início de cada solicitação, ligue para:

Span.current().setAttribute("mycustomer", "xyz");

Consulte também: Adicionar uma propriedade personalizada a um Span.

Substituições de cadeia de conexão (versão prévia)

Esse recurso está em versão prévia, começando na 3.4.0.

As substituições de cadeia de conexão permitem substituir a cadeia de conexão padrão. Por exemplo, você pode:

• Defina uma cadeia de conexão para um prefixo de caminho HTTP /myapp1.
• Defina outra cadeia de conexão para outro prefixo de caminho HTTP /myapp2/.

{
  "preview": {
    "connectionStringOverrides": [
      {
        "httpPathPrefix": "/myapp1",
        "connectionString": "..."
      },
      {
        "httpPathPrefix": "/myapp2",
        "connectionString": "..."
      }
    ]
  }
}

Substituições de nome de função de nuvem (versão prévia)

Esse recurso está em versão prévia, começando da 3.3.0.

As substituições de nome de função de nuvem permitem substituir o nome de função de nuvem padrão. Por exemplo, você pode:

• Defina um nome de função de nuvem para um prefixo de caminho HTTP /myapp1.
• Defina outro nome de função de nuvem para outro prefixo de caminho HTTP /myapp2/.

{
  "preview": {
    "roleNameOverrides": [
      {
        "httpPathPrefix": "/myapp1",
        "roleName": "Role A"
      },
      {
        "httpPathPrefix": "/myapp2",
        "roleName": "Role B"
      }
    ]
  }
}

Cadeia de conexão configurada no runtime

A partir da versão 3.4.8, se você precisar da capacidade de configurar a cadeia de conexão no runtime, adicione essa propriedade à configuração JSON:

{
  "connectionStringConfiguredAtRuntime": true
}

Adicione o applicationinsights-core ao seu aplicativo:

<dependency>
  <groupId>com.microsoft.azure</groupId>
  <artifactId>applicationinsights-core</artifactId>
  <version>3.5.2</version>
</dependency>

Use o método estático configure(String) na classe com.microsoft.applicationinsights.connectionstring.ConnectionString.

Observação

Qualquer telemetria capturada antes de configurar a cadeia de conexão será removida, portanto, é melhor configurá-la o mais cedo possível na inicialização do aplicativo.

Coletar automaticamente as dependências do InProc (versão prévia)

A partir da 3.2.0, para capturar as dependências "InProc" do controlador, use a seguinte configuração:

{
  "preview": {
    "captureControllerSpans": true
  }
}

Carregador do SDK do Navegador (versão prévia)

Esse recurso injeta automaticamente o Carregador do SDK do Navegador nas páginas HTML do aplicativo, incluindo a configuração da cadeia de conexão apropriada.

Por exemplo, quando seu aplicativo java retorna uma resposta como:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Title</title>
  </head>
  <body>
  </body>
</html>

Ele modifica automaticamente para retornar:

<!DOCTYPE html>
<html lang="en">
  <head>
    <script type="text/javascript">
    !function(v,y,T){var S=v.location,k="script"
    <!-- Removed for brevity -->
    connectionString: "YOUR_CONNECTION_STRING"
    <!-- Removed for brevity --> }});
    </script>
    <title>Title</title>
  </head>
  <body>
  </body>
</html>

O script tem como objetivo ajudar os clientes a rastrear os dados do usuário da Web e enviar dados telemétricos do lado do servidor de coleta de volta ao portal do Azure dos usuários. Os detalhes podem ser encontrados em ApplicationInsights-JS.

Se você quiser habilitar esse recurso, adicione a opção de configuração abaixo:

{
  "preview": {
    "browserSdkLoader": {
      "enabled": true
    }
  }
}

Processadores de Telemetria (pré-visualização)

Você pode usar processadores de telemetria para configurar regras que são aplicadas à telemetria de solicitação, dependência e rastreamento. Por exemplo, você pode:

• Mascare dados confidenciais.
• Adicione dimensões personalizadas condicionalmente.
• Atualize o nome do span, que é usado para agregar telemetria semelhante no portal do Azure.
• Descartar atributos de span específicos para controlar os custos de ingestão.

Para saber mais, confira a documentação Processador de telemetria.

Observação

Para remover períodos específicos (inteiros) a fim de controlar o custo de ingestão, confira Substituições de amostragem.

Instrumentação personalizada (versão prévia)

A partir da versão 3.3.1, você pode capturar intervalos para um método em seu aplicativo:

{
  "preview": {
    "customInstrumentation": [
      {
        "className": "my.package.MyClass",
        "methodName": "myMethod"
      }
    ]
  }
}

Registro em log coletado automaticamente

O Log4j, o Logback, o JBoss Logging e o java.util.logging são instrumentados automaticamente. O registro em log realizado por meio dessas estruturas de registro em log é coletado automaticamente.

O registro em log só será capturado se:

• Atende ao nível configurado da estrutura de log.
• Também atende ao nível configurado do Application Insights.

Por exemplo, se sua estrutura de registros estiver configurada para registrar WARN (e você a configurou conforme descrito anteriormente) do pacote com.example, e o Application Insights estiver configurado para capturar INFO (e você o configurou conforme descrito), o Application Insights captura apenas WARN (e mais grave) do pacote com.example.

O nível padrão configurado para Application Insights é INFO. Se você quiser alterar este nível:

{
  "instrumentation": {
    "logging": {
      "level": "WARN"
    }
  }
}

Também é possível definir o nível usando a variável de ambiente APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL. Em seguida, ele terá precedência sobre o nível especificado na configuração JSON.

É possível usar esses valores level válidos para a especificação no arquivo applicationinsights.json. A tabela mostra como eles correspondem aos níveis de registros em log em diferentes estruturas de registro em log.

Nível	Log4j	Logback	JBoss	JUL
OFF	OFF	OFF	OFF	OFF
FATAL	FATAL	ERROR	FATAL	SEVERE
ERRO (ou grave)	ERROR	ERROR	ERROR	SEVERE
AVISAR (ou AVISO)	AVISO	AVISO	AVISO	WARNING
INFO	INFO	INFO	INFO	INFO
CONFIG	DEBUG	DEBUG	DEBUG	CONFIG
DEPURAR (ou BEM)	DEBUG	DEBUG	DEBUG	FINE
FINER	DEBUG	DEBUG	DEBUG	FINER
RASTREAMENTO (ou REFINADO):	RASTREAMENTO	RASTREAMENTO	RASTREAMENTO	FINEST
ALL	ALL	ALL	ALL	ALL

Observação

Se um objeto de exceção for transmitido ao agente, a mensagem de log (e os detalhes do objeto de exceção) será exibida no portal do Azure na tabela exceptions em vez de na tabela traces. Para ver as mensagens de log nas tabelas traces e exceptions, escreva uma consulta Logs (Kusto) para união entre elas. Por exemplo:

union traces, (exceptions | extend message = outerMessage)
| project timestamp, message, itemType

Marcadores de log (versão prévia)

A partir da versão 3.4.2, você pode capturar os marcadores de log para Logback e Log4j 2:

{
  "preview": {
    "captureLogbackMarker":  true,
    "captureLog4jMarker":  true
  }
}

Outros atributos de log para Logback (versão prévia)

Da versão 3.4.3 em diante, você pode capturar FileName, ClassName, MethodName e LineNumber para Logback:

{
  "preview": {
    "captureLogbackCodeAttributes": true
  }
}

Aviso

Capturar atributos de código pode adicionar uma sobrecarga de desempenho.

Nível de registro em log como dimensão personalizada

A partir da 3.3.0, LoggingLevel não é capturado por padrão como parte da dimensão personalizada Traces porque esses dados já foram capturados no campo SeverityLevel.

Se necessário, reabilite temporariamente o comportamento anterior:

{
  "preview": {
    "captureLoggingLevelAsCustomDimension": true
  }
}

Métricas do Micrometer coletadas automaticamente (incluindo as métricas do acionador do Spring Boot)

Se o aplicativo usar o Micrômetro, as métricas enviadas ao registro global do Micrômetro serão coletadas automaticamente.

Além disso, se o aplicativo usar o Atuador do Spring Boot, as métricas configuradas por ele também serão coletadas automaticamente.

Para enviar métricas personalizadas usando o micrômetro:

1. Adicione o Micrometer ao seu aplicativo, conforme mostrado no exemplo a seguir.

   <dependency>
     <groupId>io.micrometer</groupId>
     <artifactId>micrometer-core</artifactId>
     <version>1.6.1</version>
   </dependency>
   

2. Use o registro global do Micrometer para criar um medidor, conforme mostrado no exemplo a seguir.

   static final Counter counter = Metrics.counter("test.counter");
   

3. Use o contador para registrar métricas usando o comando a seguir.

   counter.increment();
   

4. As métricas são ingeridas na tabela customMetrics, com marcas capturadas na coluna customDimensions. Você também pode exibir as métricas no Metrics Explorer no namespace de métrica Log-based metrics.

   Observação

   O Java do Application Insights substitui todos os caracteres não alfanuméricos (exceto traços) no nome da métrica do Micrometer por sublinhados. Como resultado, a métrica anterior test.counter aparecerá como test_counter.

Para desabilitar a coleta automática de métricas do Micrômetro e do Spring Boot Actuator, faça o seguinte:

Observação

As métricas personalizadas são cobradas separadamente e podem gerar custos extras. Verifique as Informações de preços. Para desabilitar as métricas do Micrômetro e do Spring Boot Actuator, adicione a seguinte configuração ao arquivo de configuração.

{
  "instrumentation": {
    "micrometer": {
      "enabled": false
    }
  }
}

Mascaramento de consulta do Java Database Connectivity

Os valores literais nas consultas do JDBC (Java Database Connectivity) são mascarados por padrão para evitar a captura acidental de dados confidenciais.

A partir da versão 3.4.0, esse comportamento pode ser desabilitado. Por exemplo:

{
  "instrumentation": {
    "jdbc": {
      "masking": {
        "enabled": false
      }
    }
  }
}

Mascaramento de consulta do Mongo

Os valores literais nas consultas Mongo são mascarados por padrão para evitar a captura acidental de dados confidenciais.

A partir da versão 3.4.0, esse comportamento pode ser desabilitado. Por exemplo:

{
  "instrumentation": {
    "mongo": {
      "masking": {
        "enabled": false
      }
    }
  }
}

Cabeçalhos HTTP

Da versão 3.3.0 em diante, você pode capturar cabeçalhos de solicitação e resposta na telemetria de servidor (solicitação):

{
  "preview": {
    "captureHttpServerHeaders": {
      "requestHeaders": [
        "My-Header-A"
      ],
      "responseHeaders": [
        "My-Header-B"
      ]
    }
  }
}

Os nomes de cabeçalho não diferenciam maiúsculas de minúsculas.

Os exemplos anteriores são capturados nos nomes de propriedade http.request.header.my_header_a e http.response.header.my_header_b.

Da mesma forma, é possível capturar dos cabeçalhos de solicitação e resposta em sua telemetria de cliente (dependência):

{
  "preview": {
    "captureHttpClientHeaders": {
      "requestHeaders": [
        "My-Header-C"
      ],
      "responseHeaders": [
        "My-Header-D"
      ]
    }
  }
}

Novamente, os nomes de cabeçalho não diferenciam maiúsculas de minúsculas. Os exemplos anteriores são capturados nos nomes de propriedade http.request.header.my_header_c e http.response.header.my_header_d.

Códigos de resposta do servidor HTTP 4xx

Por padrão, as solicitações do servidor HTTP que resultam em códigos de resposta 4xx são capturadas como erros.

A partir da 3.3.0, é possível alterar esse comportamento para capturá-las como bem-sucedidas:

{
  "preview": {
    "captureHttpServer4xxAsError": false
  }
}

Suprimir telemetria específica coletada automaticamente

A partir da 3.0.3, uma telemetria específica coletada automaticamente pode ser suprimida usando estas opções de configuração:

{
  "instrumentation": {
    "azureSdk": {
      "enabled": false
    },
    "cassandra": {
      "enabled": false
    },
    "jdbc": {
      "enabled": false
    },
    "jms": {
      "enabled": false
    },
    "kafka": {
      "enabled": false
    },
    "logging": {
      "enabled": false
    },
    "micrometer": {
      "enabled": false
    },
    "mongo": {
      "enabled": false
    },
    "quartz": {
      "enabled": false
    },
    "rabbitmq": {
      "enabled": false
    },
    "redis": {
      "enabled": false
    },
    "springScheduling": {
      "enabled": false
    }
  }
}

Você também pode suprimir essas instrumentações definindo essas variáveis de ambiente como false:

• APPLICATIONINSIGHTS_INSTRUMENTATION_AZURE_SDK_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_CASSANDRA_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_JDBC_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_JMS_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_KAFKA_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_MICROMETER_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_MONGO_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_RABBITMQ_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_REDIS_ENABLED
• APPLICATIONINSIGHTS_INSTRUMENTATION_SPRING_SCHEDULING_ENABLED

Essas variáveis terão precedência sobre as habilitadas que foram especificadas na configuração JSON.

Observação

Para obter um controle mais refinado, por exemplo, para suprimir algumas chamadas do Redis, mas nem todas, confira Substituições de amostragem.

Instrumentações de pré-visualização

A partir da 3.2.0, é possível habilitar as seguintes instrumentações de versão prévia:

{
  "preview": {
    "instrumentation": {
      "akka": {
        "enabled": true
      },
      "apacheCamel": {
        "enabled": true
      },
      "grizzly": {
        "enabled": true
      },
      "ktor": {
        "enabled": true
      },
      "play": {
        "enabled": true
      },
      "r2dbc": {
        "enabled": true
      },
      "springIntegration": {
        "enabled": true
      },
      "vertx": {
        "enabled": true
      }
    }
  }
}

Observação

A instrumentação Akka está disponível a partir da versão 3.2.2. A instrumentação da biblioteca HTTP Vertx está disponível a partir da 3.3.0.

Intervalo de métrica

Por padrão, as métricas são capturadas a cada 60 segundos.

A partir da versão 3.0.3, você pode alterar esse intervalo:

{
  "metricIntervalSeconds": 300
}

Começando no 3.4.9 GA, você também pode definir o metricIntervalSeconds usando a variável de ambiente APPLICATIONINSIGHTS_METRIC_INTERVAL_SECONDS. Em seguida, ele terá precedência sobre o metricIntervalSeconds especificado na configuração JSON.

A configuração se aplica às seguintes métricas:

• Contadores de desempenho padrão: por exemplo, CPU e memória
• Métricas personalizadas padrão: por exemplo, tempo de coleta de lixo
• Métricas JMX configuradas: confira a seção de métricas JMX
• Métricas do Micrômetro: Confira a seção de métricas do Micrômetro coletadas automaticamente

Pulsação

Por padrão, Application Insights Java 3.x envia uma métrica de pulsação uma vez a cada 15 minutos. Ao usar a métrica de pulsação para acionar alertas, é possível aumentar a frequência da pulsação:

{
  "heartbeat": {
    "intervalSeconds": 60
  }
}

Observação

Não é possível aumentar o intervalo para mais de 15 minutos porque os dados de pulsação também são usados para rastrear o uso do Application Insights.

Autenticação

Observação

O recurso de autenticação é GA desde a versão 3.4.17.

Você pode usar a autenticação para configurar o agente para gerar credenciais token necessárias para a autenticação do Microsoft Entra. Para saber mais, confira a documentação Autenticação.

Proxy HTTP

Se o seu aplicativo estiver protegido por um firewall e não puder se conectar diretamente ao Application Insights, consulte os endereços IP usados pelo Application Insights.

Para contornar esse problema, você pode configurar o Application Insights Java 3.x para usar um proxy HTTP.

{
  "proxy": {
    "host": "myproxy",
    "port": 8080
  }
}

Você também pode definir o proxy HTTP usando a variável de ambiente APPLICATIONINSIGHTS_PROXY, que usa o formato https://<host>:<port>. Em seguida, ele terá precedência sobre o proxy especificado na configuração JSON.

O Java 3.x do Application Insights também respeita as propriedades do sistema globais https.proxyHost e https.proxyPort quando elas estão definidas, além de http.nonProxyHosts, quando necessário.

Recuperação de falhas de ingestão

Quando o envio da telemetria para o serviço do Application Insights falha, o Java 3.x do Application Insights armazena a telemetria em disco e continua tentando realizar a operação novamente nele.

O limite padrão para persistência de disco é de 50 Mb. Se você tiver um alto volume de telemetria ou precisar se recuperar de interrupções mais longas da rede ou do serviço de ingestão, aumente o limite a partir da 3.3.0:

{
  "preview": {
    "diskPersistenceMaxSizeMb": 50
  }
}

Autodiagnóstico

"Autodiagnostics" refere-se ao log interno de Application Insights Java 3.x. Essa funcionalidade pode ser útil para descobrir e diagnosticar problemas com Application Insights si mesmo.

Por padrão, Application Insights logs do Java 3.x em nível INFO tanto para o arquivo applicationinsights.log quanto para o console, correspondendo a essa configuração:

{
  "selfDiagnostics": {
    "destination": "file+console",
    "level": "INFO",
    "file": {
      "path": "applicationinsights.log",
      "maxSizeMb": 5,
      "maxHistory": 1
    }
  }
}

No exemplo de configuração anterior:

• Pode ser level, OFF, ERROR, WARN, INFO, DEBUG ou TRACE.
• path pode ser um caminho absoluto ou relativo. Os caminhos relativos são resolvidos em relação ao diretório onde applicationinsights-agent-3.5.2.jar está localizado.

A partir da 3.0.2, também é possível definir o autodiagnóstico level usando a variável de ambiente APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL. Em seguida, ele terá precedência sobre o nível de autodiagnóstico especificado na configuração JSON.

A partir da 3.0.3, também é possível definir o local do arquivo de autodiagnóstico com a variável de ambiente APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_FILE_PATH. Em seguida, ele terá precedência sobre o caminho do arquivo de autodiagnóstico especificado na configuração JSON.

Um exemplo

Este exemplo mostra a aparência de um arquivo de configuração com diversos componentes. Configure opções específicas com base em suas necessidades.

{
  "connectionString": "...",
  "role": {
    "name": "my cloud role name"
  },
  "sampling": {
    "percentage": 100
  },
  "jmxMetrics": [
  ],
  "customDimensions": {
  },
  "instrumentation": {
    "logging": {
      "level": "INFO"
    },
    "micrometer": {
      "enabled": true
    }
  },
  "proxy": {
  },
  "preview": {
    "processors": [
    ]
  },
  "selfDiagnostics": {
    "destination": "file+console",
    "level": "INFO",
    "file": {
      "path": "applicationinsights.log",
      "maxSizeMb": 5,
      "maxHistory": 1
    }
  }
}