13 Monitoramento JMX

Visão geral

O monitoramento JMX pode ser usado para monitorar contadores JMX de uma aplicação Java.

O monitoramento JMX possui suporte nativo no Zabbix na forma de um daemon Zabbix chamado "Zabbix Java gateway".

Para recuperar o valor de um contador JMX específico em um host, o Zabbix server consulta o Zabbix Java gateway, que por sua vez utiliza a API de gerenciamento JMX para consultar remotamente a aplicação de interesse.

Para mais detalhes e configuração, consulte a seção Zabbix Java gateway.

Habilitando o monitoramento remoto JMX para aplicações Java

Uma aplicação Java não precisa de nenhum software adicional instalado, mas precisa ser iniciada com as opções de linha de comando especificadas abaixo para ter suporte ao monitoramento remoto via JMX.

No mínimo, se você deseja apenas começar monitorando uma aplicação Java simples em um host local sem segurança aplicada, inicie-a com estas opções:

java \
       -Dcom.sun.management.jmxremote \
       -Dcom.sun.management.jmxremote.port=12345 \
       -Dcom.sun.management.jmxremote.authenticate=false \
       -Dcom.sun.management.jmxremote.ssl=false \
       -Dcom.sun.management.jmxremote.registry.ssl=false \
       -jar /path/to/your/application.jar

Isso faz com que o Java escute conexões JMX na porta 12345, apenas do host local, e informa que não é necessário autenticação ou SSL.

Se você quiser permitir conexões em outra interface, defina o parâmetro -Djava.rmi.server.hostname para o IP dessa interface.

Se você deseja ser mais rigoroso quanto à segurança, há muitas outras opções Java disponíveis para você. Por exemplo, o próximo exemplo inicia a aplicação com um conjunto de opções mais versátil e a abre para uma rede mais ampla, não apenas para o host local.

java \
       -Djava.rmi.server.hostname=192.168.3.14 \
       -Dcom.sun.management.jmxremote \
       -Dcom.sun.management.jmxremote.port=12345 \
       -Dcom.sun.management.jmxremote.authenticate=true \
       -Dcom.sun.management.jmxremote.password.file=/etc/java-6-openjdk/management/jmxremote.password \
       -Dcom.sun.management.jmxremote.access.file=/etc/java-6-openjdk/management/jmxremote.access \
       -Dcom.sun.management.jmxremote.ssl=true \
       -Dcom.sun.management.jmxremote.registry.ssl=true \
       -Djavax.net.ssl.keyStore=$YOUR_KEY_STORE \
       -Djavax.net.ssl.keyStorePassword=$YOUR_KEY_STORE_PASSWORD \
       -Djavax.net.ssl.trustStore=$YOUR_TRUST_STORE \
       -Djavax.net.ssl.trustStorePassword=$YOUR_TRUST_STORE_PASSWORD \
       -Dcom.sun.management.jmxremote.ssl.need.client.auth=true \
       -jar /path/to/your/application.jar

A maioria (senão todas) dessas configurações pode ser especificada em $JRE/lib/management/management.properties (ou onde quer que esse arquivo esteja em seu sistema).

Observe que, se você deseja usar SSL, é necessário modificar o script startup.sh adicionando as opções -Djavax.net.ssl.* ao Java gateway, para que ele saiba onde encontrar os arquivos de chave e trust store.

Consulte Monitoring and Management Using JMX para uma descrição detalhada.

Configurando interfaces e items JMX no frontend do Zabbix

Com o Java gateway em execução, o server sabendo onde encontrá-lo e um aplicativo Java iniciado com suporte para monitoramento remoto JMX, é hora de configurar as interfaces e items na interface gráfica do Zabbix.

Configurando a interface JMX

Você começa criando uma interface do tipo JMX no host de interesse.

Todos os campos obrigatórios estão marcados com um asterisco vermelho.

Adicionando um item de agent JMX

Para cada contador JMX do seu interesse, adicione um item de agent JMX vinculado àquela interface.

A chave na captura de tela abaixo diz jmx["java.lang:type=Memory","HeapMemoryUsage.used"].

Todos os campos obrigatórios estão marcados com um asterisco vermelho.

Os campos que exigem informações específicas para itens JMX são:

Se você deseja monitorar um contador Booleano que seja "true" ou "false", então especifique o tipo de informação como "Numérico (sem sinal)" e selecione a etapa de pré-processamento "Booleano para decimal" na guia Pré-processamento. O server armazenará valores Booleanos como 1 ou 0, respectivamente.

Chaves de item JMX em mais detalhes

Atributos simples

Um nome de objeto MBean nada mais é do que uma string que você define em sua aplicação Java. Um nome de atributo, por outro lado, pode ser mais complexo. Caso um atributo retorne um tipo de dado primitivo (um inteiro, uma string, etc.), não há com o que se preocupar, a chave ficará assim:

jmx[com.example:Type=Hello,weight]

Neste exemplo, o nome do objeto é "com.example:Type=Hello", o nome do atributo é "weight", e o tipo de valor retornado provavelmente deve ser "Numérico (flutuante)".

Atributos que retornam dados compostos

Fica mais complicado quando seu atributo retorna dados compostos. Por exemplo: o nome do seu atributo é "apple" e ele retorna um hash representando seus parâmetros, como "weight", "color" etc. Sua chave pode ser assim:

jmx[com.example:Type=Hello,apple.weight]

É assim que um nome de atributo e uma chave de hash são separados, usando um ponto. Da mesma forma, se um atributo retornar dados compostos aninhados, as partes são separadas por um ponto:

jmx[com.example:Type=Hello,fruits.apple.weight]

Atributos que retornam dados tabulares

Atributos de dados tabulares consistem em um ou vários atributos compostos. Se tal atributo for especificado no parâmetro de nome do atributo, então este valor de item retornará a estrutura completa do atributo no formato JSON. Os valores dos elementos individuais dentro do atributo de dados tabulares podem ser recuperados usando pré-processamento.

Exemplo de atributo de dados tabulares:

 jmx[com.example:type=Hello,foodinfo]

Valor do item:

[
         {
           "a": "apple",
           "b": "banana",
           "c": "cherry"
         },
         {
           "a": "potato",
           "b": "lettuce",
           "c": "onion"
         }
       ]

Problema com pontos

Até agora tudo bem. Mas e se um nome de atributo ou uma chave de hash contiver um ponto? Aqui está um exemplo:

jmx[com.example:Type=Hello,all.fruits.apple.weight]

Isso é um problema. Como dizer ao Zabbix que o nome do atributo é "all.fruits", não apenas "all"? Como distinguir um ponto que faz parte do nome do ponto que separa um nome de atributo e as chaves de hash?

Isso é possível, tudo o que você precisa fazer é escapar os pontos que fazem parte do nome com uma barra invertida:

jmx[com.example:Type=Hello,all\.fruits.apple.weight]

Da mesma forma, se sua chave de hash contiver um ponto, você deve escapá-lo:

jmx[com.example:Type=Hello,all\.fruits.apple.total\.weight]

Outros problemas

Um caractere de barra invertida em um nome de atributo deve ser escapado:

jmx[com.example:type=Hello,c:\\documents]

Para lidar com quaisquer outros caracteres especiais na chave do item JMX, consulte a seção de formato de chave de item section.

Isso é tudo o que há para fazer. Feliz monitoramento JMX!

Tipos de dados não primitivos

É possível trabalhar com MBeans personalizados retornando tipos de dados não primitivos, que substituem o método toString().

Usando endpoint personalizado com JBoss EAP 6.4

Endpoints personalizados permitem trabalhar com diferentes protocolos de transporte além do RMI padrão.

Para ilustrar essa possibilidade, vamos tentar configurar o monitoramento do JBoss EAP 6.4 como exemplo. Primeiro, vamos fazer algumas suposições:

• Você já instalou o Zabbix Java gateway. Caso não tenha feito isso, siga a documentação.
• O Zabbix server e o Java gateway estão instalados com o prefixo /usr/local/
• O JBoss já está instalado em /opt/jboss-eap-6.4/ e está rodando em modo standalone
• Vamos assumir que todos esses componentes estão funcionando no mesmo host
• O firewall e o SELinux estão desabilitados (ou configurados adequadamente)

Vamos fazer algumas configurações simples no zabbix_server.conf:

JavaGateway=127.0.0.1
       StartJavaPollers=5

E no arquivo de configuração zabbix_java/settings.sh (ou zabbix_java_gateway.conf):

START_POLLERS=5

Verifique se o JBoss está ouvindo em sua porta de gerenciamento padrão:

$ netstat -natp | grep 9999
       tcp        0      0 127.0.0.1:9999          0.0.0.0:*               LISTEN      10148/java

Agora vamos criar um host com a interface JMX 127.0.0.1:9999 no Zabbix.

Como sabemos que esta versão do JBoss usa o protocolo JBoss Remoting em vez do RMI, podemos atualizar em massa o parâmetro de endpoint JMX para os items em nosso template JMX da seguinte forma:

service:jmx:remoting-jmx://{HOST.CONN}:{HOST.PORT}

Vamos atualizar o cache de configuração:

/usr/local/sbin/zabbix_server -R config_cache_reload

Observe que você pode encontrar um erro inicialmente.

"Unsupported protocol: remoting-jmx" significa que o Java gateway não sabe como trabalhar com o protocolo especificado. Isso pode ser corrigido criando um arquivo ~/needed_modules.txt com o seguinte conteúdo:

jboss-as-remoting
       jboss-logging
       jboss-logmanager
       jboss-marshalling
       jboss-remoting
       jboss-sasl
       jcl-over-slf4j
       jul-to-slf4j-stub
       log4j-jboss-logmanager
       remoting-jmx
       slf4j-api
       xnio-api
       xnio-nio

e então executando o comando:

for i in $(cat ~/needed_modules.txt); do find /opt/jboss-eap-6.4 -iname "${i}*.jar" -exec cp '{}' /usr/local/sbin/zabbix_java/lib/ \; ; done

Assim, o Java gateway terá todos os módulos necessários para trabalhar com jmx-remoting. O que resta é reiniciar o Java gateway, aguardar um pouco e, se você fez tudo certo, verá que os dados de monitoramento JMX começam a chegar no Zabbix (veja também: Últimos dados).