Integração de monitoramento JMX

Nossa integração JMX permite ao usuário monitor qualquer aplicativo que exponha métrica com JMX. A integração inclui um arquivo de coleta padrão que coleta automaticamente as principais métricas da JVM.

Compatibilidade e requisitos

Antes de instalar a integração, certifique-se de atender aos seguintes requisitos:

Uma conta New Relic . Não tem um? Cadastre-se gratuitamente! Não é necessário cartão de crédito.
Java versão 8 ou superior.
Se você precisar usar uma versão Java diferente daquela configurada em PATH, siga a documentação de configuração da New Relic no GitHub.
Esta integração não suporta o protocolo IIOP.

Começo rápido

Se você não estiver executando o JMX em ambientes Kubernetes ou ECS, recomendamos nossa instalação guiada. Nossa instalação guiada usa nosso agente de infraestrutura e nossa CLI para configurar a integração JMX e descobre outros aplicativos e fontes de log em execução em seu ambiente e, em seguida, recomenda quais deles você deve usar.

A instalação guiada funciona com a maioria das configurações. Mas se não atender às suas necessidades, existem outras opções de instalação abaixo.

Pronto para começar? Clique no botão relevante, dependendo da região do data center que você usa. Quando terminar a instalação, retorne a esta documentação para revisar as opções de configuração.

Instalação guiada, região dos EUA

Instalação guiada, região da UE

Instalar

Se você não estiver usando a instalação guiada, siga as instruções para seu ambiente:

' '

Instale o agente de infraestrutura e substitua a variável INTEGRATION_FILE_NAME por nri-jmx.
Mude o diretório para a pasta integração:
```
cd /etc/newrelic-infra/integrations.d
```
Copie o arquivo de configuração de amostra:
```
sudo cp jmx-config.yml.sample jmx-config.yml
```
Copie o arquivo de configuração da JVM:
```
sudo cp jvm-metrics.yml.sample jvm-metrics.yml
```
Optional: Se você estiver interessado em monitoramento Tomcat, use este exemplo de arquivo métrico:
```
sudo cp tomcat-metrics.yml.sample tomcat-metrics.yml
```
Edite o arquivo jmx-config.yml conforme descrito nas definições de configuração.
Reinicie o agente de infraestrutura.
Importante
Se os arquivos de amostra não estiverem presentes em sua instalação, você poderá baixá-los diretamente do repositório GitHub.

Baixe a imagem do instalador nri-jmx .MSI em:
https://download.newrelic.com/infrastructure_agent/windows/integrations/nri-jmx/nri-jmx-amd64-installer.exe
Para instalar a partir do prompt de comando do Windows, execute:
```
PATH\TO\nri-jmx-amd64-installer.exe
```
No diretório integração, C:\Program Files\New Relic\newrelic-infra\integrations.d\, crie uma cópia do arquivo de configuração de amostra executando:
```
cp jmx-config.yml.sample jmx-config.yml
```
Edite o arquivo de configuração jmx-config.yml usando as definições de configuração.
Reinicie o agente de infraestrutura.

Atualize sua integração

Essa integração não é atualizada automaticamente. Para obter melhores resultados, atualize regularmente o pacote de integração e o agente de infraestrutura.

Tarefas pós-instalação

Quando terminar a instalação, você poderá definir opções de configuração. Algumas configurações são necessárias para que a integração funcione, enquanto outras são opcionais.

Configurar a integração

A configuração no formato YAML de uma integração é onde você pode colocar as credenciais de login necessárias e configurar como os dados são coletados. Quais opções você altera dependem de sua configuração e preferência.

Existem diversas formas de configurar a integração, dependendo de como ela foi instalada:

Se habilitado via Kubernetes: consulte Monitorar serviços em execução no Kubernetes.
Se habilitado via Amazon ECS: consulte Monitorar serviços em execução no ECS.
Se instalado no host: edite a configuração no arquivo de configuração YAML da integração, jmx-config.yml.

Arquivos de configuração de integração

O arquivo de configuração possui configurações comuns aplicáveis a toda integração, como interval, timeout ou inventory_source. Para ler tudo sobre essas configurações comuns, consulte nosso documento de formato de configuração .

Configurações específicas relacionadas ao JMX são definidas usando a seção env do arquivo de configuração. Essas configurações controlam a conexão com sua instância JMX, bem como outras configurações e recursos de segurança. A lista de configurações válidas é descrita na próxima seção deste documento.

As opções de configuração estão abaixo. Para obter um exemplo de configuração, consulte o arquivo de configuração de exemplo.

A integração JMX coleta informações métricas e de inventário. Esta tabela mostra a que cada opção de configuração se aplica.

' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' '

Contexto	Descrição	Padrão	Aplica-se a
JMX_HOST	O host em que o JMX está sendo executado.	`localhost`	MI
JMX_PORT	A porta em que o JMX está sendo executado.	9999	MI
JMX_URI_PATH	A parte do caminho do URI do serviço JMX. Isto é útil para uris de serviço fora do padrão.	N/A	MI
JMX_USER	O nome de usuário da conexão JMX.	N/A	MI
JMX_PASS	A senha para a conexão JMX.	N/A	MI
JMX_REMOTE	(Específico do JBoss) Se deve ou não usar o formato de conexão de URL remota JMX. O padrão de conexão é o modo de domínio JBoss se `true`.	`false`	MI
JMX_REMOTE_JBOSS_STANDLONE	(Específico do JBoss) Se deve ou não usar o formato de conexão independente do JBoss. Relevante apenas se `jmx_remote` estiver definido.	`false`	MI
CONNECTION_URL	URL completo endpoint JMX. Isto substitui todos os argumentos de conexão (acima) fornecendo todos os parâmetros em uma linha. Exemplo: `"service:jmx:rmi:///jndi/rmi://localhost:7199/jmxrmi"`	N/A	MI
COLLECTION_FILES	Uma lista separada por vírgula de caminhos completos para os arquivos de definição da coleção métrica. Para instalação no host, o arquivo de coleta de métricas JVM padrão está em `/etc/newrelic-infra/integrations.d/jvm-metrics.yml`.	N/A	MI
COLLECTION_CONFIG	Configuração da coleção métrica em JSON. Exemplo de JVM: COLLECTION_CONFIG='{"collect":[{"domain":"java.lang","event_type":"JVMSample","beans":[{"query":"type=GarbageCollector,name=*","attributes":["CollectionCount","CollectionTime"]},{"query":"type=Memory","attributes":["HeapMemoryUsage.Committed","HeapMemoryUsage.Init","HeapMemoryUsage.Max","HeapMemoryUsage.Used","NonHeapMemoryUsage.Committed","NonHeapMemoryUsage.Init","NonHeapMemoryUsage.Max","NonHeapMemoryUsage.Used"]},{"query":"type=Threading","attributes":["ThreadCount","TotalStartedThreadCount"]},{"query":"type=ClassLoading","attributes":["LoadedClassCount"]},{"query":"type=Compilation","attributes":["TotalCompilationTime"]}]}]}' Exemplo do Tomcat: `COLLECTION_CONFIG={"collect":[{"domain":"Catalina","event_type":"TomcatSample","beans":[{"query":"type=UtilityExecutor","attributes":["completedTaskCount"]}]}]}` `COLLECTION_CONFIG` é útil para configurar nri-jmx no Kubernetes usando anotações.	N/A	MI
KEY_STORE	O caminho do arquivo do keystore que contém o certificado SSL do cliente JMX.	N/A	MI
KEY_STORE_PASSWORD	A senha do armazenamento de chaves SSL.	N/A	MI
LOCAL_ENTITY	Coletar todas as métricas da entidade local. Utilize somente quando monitoramento localhost.	`false`	MI
TIMEOUT	O tempo limite para consulta JMX individual, em milissegundos.	10.000	MI
TRUST_STORE	O caminho do arquivo do keystore que contém o certificado SSL do servidor JMX.	N/A	MI
TRUST_STORE_PASSWORD	A senha do armazenamento confiável.	N/A	MI
METRIC_LIMIT	Número de métricas que podem ser recolhidas por entidade. Se este limite for ultrapassado a entidade não será reportada. Um limite de 0 não implica nenhum limite.	200	MI
METRICS	Defina como `true` para ativar a coleta somente de métricas.	`false`
INVENTORY	Defina como `true` para ativar a coleta somente de inventário.	`false`

Os valores para estas configurações podem ser definidos de diversas maneiras:

Adicionando o valor diretamente no arquivo de configuração. Esta é a forma mais comum.
Substituindo os valores das variáveis de ambiente usando a notação {{}} . Isto requer o agente de infraestrutura v1.14.0 ou superior. Leia mais aqui ou veja o exemplo abaixo.
Usando gerenciamento de segredos. Use isto para proteger informações confidenciais (como senhas) de serem expostas em texto simples no arquivo de configuração. Para obter mais informações, consulte gerenciamento de segredos.

Você também pode personalizar suas etiquetas. Adicione valor principal pair atributo à sua métrica, que você poderá usar para consultar, filtrar ou agrupar sua métrica.

Nosso arquivo de configuração de amostra padrão contém exemplos de rótulos. Eles não são obrigatórios e você pode remover, modificar ou adicionar novos de sua escolha.

labels:
   env: production
   role: jmx

Arquivos de coleta métrica

Os arquivos de definição de coleção de métricas são arquivos YAML estruturados que informam à integração qual métrica coletar. Para um exemplo de configuração, veja o exemplo do arquivo de coleta de métricas.

Arquivo de coleta de métricas JVM padrão: /etc/newrelic-infra/integrations.d/jvm-metrics.yml

Dica

Você pode gravar diferentes arquivos de coleção para facilitar a organização e manutenção. Veja o arquivo de configuração para ver um exemplo.

A integração coleta e organiza métricas por domínio. Todas as métricas definidas por domínio serão enviadas para a New Relic e poderão ser encontradas no tipo de evento correspondente. Este tipo de evento é gerado automaticamente ou pode ser definido pelo usuário. Cada arquivo contém um único bloco collect: que contém uma matriz de domínio. Para cada domínio, são definidas as seguintes chaves:

domain: O domínio JMX; por exemplo, java.lang. Você pode usar curingas para corresponder a vários domínios; por exemplo, java.*. Se você usar um curinga, event_type será obrigatório e deverá ser exclusivo. Este campo é obrigatório.
event_type: o nome do tipo de evento para uma coleção deste domínio. Se o domínio for curinga, isso será obrigatório e deverá ser exclusivo. Se o domínio não for curinga e for indefinido pelo usuário, será gerado automaticamente. Por exemplo, o domínio java.lang terá o tipo de evento JavaLangSample. Para obter mais informações, consulte Dicas de nomenclatura.
beans: uma matriz de beans a serem coletados neste domínio.
Importante
Existe um limite de 200 métricas por instância no arquivo de configuração. Se você exceder o limite de uma instância específica, ela não será enviada para a New Relic. Se você não estiver vendo seus dados no New Relic, revise os procedimentos de resolução de problemas para identificar se você excedeu o limite.

Cada domínio contém uma matriz de beans a serem coletados. Para cada bean, as seguintes chaves são definidas:

query: O nome do bean a ser coletado; por exemplo,type=GarbageCollector,name=YoungGen. Você pode usar curingas; por exemplo, type=GarbageCollector,name=*. Este campo é obrigatório.
exclude_regex: uma lista opcional de padrões regex que correspondem aos beans a serem excluídos da coleção; por exemplo, type=GarbageCollector,name=.*.
attributes: Uma lista de atributos a serem coletados. Se não for especificado, coleta todos os atributos.
Importante
Os tipos de dados HashMap e ArrayList não são suportados.

Cada bean pode conter atributo, uma lista opcional de beans que podem ser excluídos da coleção. Para cada atributo, são definidas as seguintes chaves:

Importante

Para atributo de mapa, você deve definir uma chave attr ou attr_regex .

attr: uma correspondência exata do nome do atributo. Os atributos compostos podem ser coletados anexando o nome do membro composto ao nome do atributo com um ponto; por exemplo, HeapMemoryUsage.Max.
attr_regex: Um padrão regex que corresponde ao atributo a ser coletado.
metric_type: o tipo de métrica New Relic para coletar esse atributo. As opções são:
- gauge: os dados serão coletados como uma medição numérica instantânea.
- rate: os dados serão coletados como a mudança nessa métrica por segundo.
- delta: os dados serão coletados como a mudança nessa métrica desde a última medição.
- attribute: os dados serão coletados como uma string literal.
Se não for especificado, a integração JMX tentará inferir o tipo de métrica com base no valor retornado. Por exemplo, se a métrica for um número, ela o coletará como gauge. Se a métrica for uma string, ela será coletada como attribute.
Se as métricas forem coletadas com um tipo de métrica incorreto, você poderá especificar manualmente o tipo de métrica correto no arquivo de coleta.
metric_name: o nome sob o qual a métrica aparecerá no New Relic. Se não for especificado, o padrão será o nome do atributo.
Para obter mais informações sobre a consulta JMX, consulte a documentação do Oracle ObjectName .

Configuração de coleção usando anotações do Kubernetes

Você pode usar anotações do Kubernetes para fornecer configuração de coleção. Para conseguir isso, você precisa implantar um configMap no cluster do Kubernetes que criará o arquivo de configuração para a aplicação nri-jmx .

Neste arquivo de configuração você precisa especificar o comando para auto-discovery do contêiner, que permitirá utilizar o espaço reservado na configuração da integração, incluindo anotações do Kubernetes.

Exemplo de configMap para monitor JVM em um aplicativo Tomcat:

nri-bundle:
  newrelic-infrastructure:
    integrations_config:
      - name: jmx-config.yml
        data:
          discovery:
            command:
              # Use the following optional arguments:
              # --namespaces: Comma separated list of namespaces to discover pods on
              # --tls: Use secure (TLS) connection
              # --port: Port used to connect to the kubelet. Default is 10255
              exec: /var/db/newrelic-infra/nri-discovery-kubernetes
              match:
                label.app: java
          integrations:
            - name: nri-jmx
              env:
                # Using the discovered IP as the host address
                JMX_HOST: ${discovery.ip}
                JMX_PORT: ${discovery.port}
                COLLECTION_CONFIG: ${discovery.annotation.newrelic.config}

Saiba mais sobre como monitorar integração no host aqui

apiVersion: v1
kind: ConfigMap
metadata:
  name: nri-integration-cfg
data:
  jmx-config.yml: |
    ---
    # Run auto discovery to find pods with label "app=java"
    discovery:
      command:
        # Use the following optional arguments:
        # --namespaces: Comma separated list of namespaces to discover pods on
        # --tls: Use secure (TLS) connection
        # --port: Port used to connect to the kubelet. Default is 10255
        exec: /var/db/newrelic-infra/nri-discovery-kubernetes
        match:
          label.app: java
    integrations:
      - name: nri-jmx
        env:
          # Using the discovered IP as the host address
          JMX_HOST: ${discovery.ip}
          JMX_PORT: ${discovery.port}
          COLLECTION_CONFIG: ${discovery.annotation.newrelic.config}

A seguir, use anotações para definir a configuração da coleção. Por exemplo, aqui está uma implantação do Tomcat com anotações:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tomcat-deployment
  labels:
    app: java
spec:
  replicas: 1
  selector:
    matchLabels:
      app: java
  template:
    metadata:
      annotations:
        newrelic.config: >-
          {
            "collect": [
              {
                "domain": "java.lang",
                "event_type": "JVMSample",
                "beans": [
                  {
                    "query": "type=GarbageCollector,name=*",
                    "attributes": [
                      "CollectionCount",
                      "CollectionTime"
                    ]
                  },
                  {
                    "query": "type=Memory",
                    "attributes": [
                      "HeapMemoryUsage.Committed",
                      "HeapMemoryUsage.Init",
                      "HeapMemoryUsage.Max",
                      "HeapMemoryUsage.Used",
                      "NonHeapMemoryUsage.Committed",
                      "NonHeapMemoryUsage.Init",
                      "NonHeapMemoryUsage.Max",
                      "NonHeapMemoryUsage.Used"
                    ]
                  },
                  {
                    "query": "type=Threading",
                    "attributes": [
                      "ThreadCount",
                      "TotalStartedThreadCount"
                    ]
                  },
                  {
                    "query": "type=ClassLoading",
                    "attributes": [
                      "LoadedClassCount"
                    ]
                  },
                  {
                    "query": "type=Compilation",
                    "attributes": [
                      "TotalCompilationTime"
                    ]
                  }
                ]
              }
            ]
          }
      labels:
        app: java
    spec:
      containers:
        - name: tomcat
          image: tomcat:10.0.12
          ports:
            - containerPort: 9999
          env:
            - name: CATALINA_OPTS
              value: '-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false'

Conectores personalizados

JMX permite o uso de conectores customizados para comunicação com o aplicativo. Para usar um conector personalizado, você deve incluir os conectores personalizados no caminho de classe nrjmx.

Por padrão, a subpasta connectors está no classpath. Se esta pasta não existir, crie-a na pasta onde o nrjmx está instalado.

Por exemplo, para adicionar suporte ao JBoss, crie uma pasta chamada connectors no caminho da biblioteca padrão (Linux) /usr/lib/nrjmx/ (/usr/lib/nrjmx/connectors/) e copie o jar do conector personalizado ($JBOSS_HOME/bin/client/jboss-cli-client.jar) nela. Agora você pode executar a consulta JMX no JBoss.

Exemplo de configuração

Exemplo de configuração de arquivo para uma instalação no host:

integrations:
- name: nri-jmx
  env:
    COLLECTION_FILES: "/etc/newrelic-infra/integrations.d/jvm-metrics.yml,/etc/newrelic-infra/integrations.d/tomcat-metrics.yml"
    JMX_HOST: jmx-host.localnet
    JMX_PASS: admin
    JMX_PORT: 9999
    JMX_USER: admin
  interval: 15s
  labels:
    env: production

collect:
            # The event type for this domain will be JavaLangSample
          - domain: java.lang
            beans:
                # Collect all beans of type Threading
              - query: type=Threading
                # Attributes can be either a string or a map
                attribute:
                      # When unspecified, the metric_type is inferred
                      # and the metric name is just the attribute name
                    - ThreadCount
                      # If using a map attribute, a custom metric name can be set
                    - attr: TotalStartedThreadCount
                      metric_name: ThreadsStarted
                      # Attributes can be collected with regex matches and
                      # the metric type can be overridden if the integration
                      # can not correctly infer the type
                    - attr_regex: "ThreadCpu.*Enabled"
                      metric_type: attribute
              - query: type=Memory
                attributes:
                      # Composite attributes can be collected with this syntax
                    - HeapMemoryUsage.Max
                    - NonHeapMemoryUsage.Max
                # Queries can be wildcarded where
              - query: type=GarbageCollector,name=*
                # If a specific bean is unwanted, it can be excluded
                # with a regex match pattern. Useful if using a wildcard query
                exclude_regex:
                      # This will match any bean where the name is YoungGen
                    - name=YoungGen
                attributes:
                    - attr: LastGcInfo.GcThreadCount
                      metric_type: gauge
                      metric_name: GCThreadCount
            # Domains can be wildcarded
          - domain: java.util.*
            # If the domain is wildcarded, a custom event must be defined
            event_type: JavaUtilSample
            beans:
                  # If no attributes are defined, all are collected by default
                - query: type=Logging

Para obter mais informações sobre a estrutura geral da configuração de integração no host, consulte Configuração.

Nomeando seus dados

Métricas são enviadas e armazenadas na forma de amostras. Esta é uma lista de pares de valores principais que incluem dados métricos e metadados. Cada amostra é armazenada como um evento em nosso banco de dados.

Você é responsável por criar e nomear os dados JMX relatados à New Relic. Por esse motivo, a New Relic recomenda fortemente seguir estas convenções ao nomear seus tipos de eventos. Para garantir que você tenha um esquema de nomenclatura consistente:

Use estojo de camelo.
Use um nome que identifique claramente quais dados ele contém.

Exemplo: MyorgApplicationSample

Recommendation: Use o mesmo esquema de nomenclatura para métricas semelhantes em aplicativos diferentes.

Encontre e use dados

Os dados deste serviço são reportados para um dashboard de integração.

Os dados JMX são anexados ao tipo de evento definido pelo usuário especificado no arquivo de configuração. Por exemplo, se você tem interesse em monitorar o Tomcat utilizando a integração JMX, defina um event_type chamado TomcatSample, e consulte esse tipo de evento.

Você pode consultar esses dados para fins de resolução de problemas ou para criar gráficos e dashboards personalizados.

Para saber mais sobre como encontrar e usar seus dados, consulte Compreender os dados de integração.

Dados métricos

As métricas geradas pela integração incluem metadados associados ao MBean do qual estão coletando. Você pode usar esses metadados em consultas NRQL para filtrar e facetar os dados para que a consulta retorne apenas os dados dos beans desejados. Também pode ser utilizado para identificar unicamente as métricas, uma vez que o nome da métrica não é necessariamente único entre todos os beans.

Cada evento contém os seguintes metadados:

Nome	Descrição
`displayName`	O nome de domínio JMX para essas métricas.
`entityName`	O nome de domínio JMX para essas métricas com o tipo de entidade “domínio:” anexado.
`host`	O host JMX do qual a métrica está sendo coletada.
`query`	A consulta usada para coletar essas métricas.
`bean`	O feijão cujo atributo essas métricas foram coletadas.
`key:<mbean_key>`	Para cada chave no nome do bean, um atributo é adicionado ao conjunto de métricas denominado `“key:<mbean_key>` com o valor da chave do bean.

Exemplo de consulta NRQL

Aqui está um exemplo de consulta NRQL aproveitando o monitor de metadados de todo o coletor de lixo JVM coletado:

SELECT latest(CollectionTime)
FROM JVMSample
FACET `key:name`
WHERE `key:type` = 'GarbageCollector'

Atributo de dados métricos

A integração JMX coleta os seguintes atributos de dados métricos:

Nome	Descrição
`HeapMemoryUsage.Used`	A memória heap Java total usada.
`HeapMemoryUsage.Committed`	A memória heap Java total comprometida para ser usada.
`HeapMemoryUsage.Init`	A memória heap Java inicial alocada.
`HeapMemoryUsage.Max`	A memória heap Java máxima disponível.
`NonHeapMemoryUsage.Used`	O total de memória não heap Java usada.
`NonHeapMemoryUsage.Committed`	O total de memória não heap Java comprometida para ser usada.
`NonHeapMemoryUsage.Init`	A memória não heap Java inicial alocada.
`NonHeapMemoryUsage.Max`	O máximo de memória Java não heap disponível.
`ThreadCount`	O número de threads ativos.
`CollectionCount`	O número total de coletas de lixo que ocorreram.
`CollectionTime`	O tempo aproximado de coleta de lixo acumulado decorreu.

Dados de inventário

A integração JMX captura o parâmetro de configuração da integração JMX. Os dados estão disponíveis na página Inventário, na origem config/jmx . Para obter mais informações sobre dados de inventário, consulte Compreender os dados de integração.

Resolução de problemas

Dicas de resolução de problemas:

Se você suspeita que existe um domínio enviando mais de 200 métricas, verifique o arquivo de log para esta mensagem:

"Domain x has n metrics, the current limit is 200. This domain will not be reported."

Se você vir esta mensagem de erro, diminua o número de métricas enviadas para o domínio reportado.

' '

Verifique o código-fonte

Esta integração é um software de código aberto. Isso significa que você pode navegar pelo código-fonte e enviar melhorias, ou criar seu próprio fork e construí-lo.

Esta tradução de máquina é fornecida para sua comodidade.

Compatibilidade e requisitos .css-21sua1{background:none;border:none;width:0;padding:0;}

Começo rápido

Instalar

Kubernetes

Linux

Windows

Atualize sua integração

Tarefas pós-instalação

Configurar a integração

Arquivos de configuração de integração

Configurações da instância JMX

Etiquetas e atributo personalizado

Arquivos de coleta métrica

Dica

Domínio domínio

Feijões

Atributo

Configuração de coleção usando anotações do Kubernetes

Exemplo de configMap usando gráficos de leme (recomendado)

Exemplo de configMap usando manifesto simples

Conectores personalizados

Exemplo de configuração

Exemplo de arquivo de conexão de host

Exemplo de arquivo de coleta métrica

Nomeando seus dados

Encontre e use dados

Dados métricos

Exemplo de consulta NRQL

Atributo de dados métricos

Dados de inventário

Resolução de problemas

Registro de pesquisa em busca de erros

Limite métrico excedido

Métrica ausente

Dashboard não aparece na IU de infraestrutura

Resolução de problemas via JMXTerm

Verifique o código-fonte

Compatibilidade e requisitos