Reaceso o mercado de servidores de aplicação pela RedHat, foi hora de dar um colorido extra à administração de ambientes JBoss. Utilizando-se de uma base de software já criada para monitoração e controle de sistemas (hyperic), a RedHat criou o JBoss Operations Network, vulgo JON (não John), que rapidamente se tornou na menina dos olhos para potenciais assinantes de subscrição JBoss.

O JON é uma ferramenta de administração, monitoração e controle de servidores JBoss.

Figura 1 - JON

Mitos

Existem alguns mitos em torno do JON que precisam ser desfeitos antes que se desenvolvam.

1. O JON é proprietário?

NÃO! Já foi, mas não é mais. Hoje o JON é apenas a versão "enterprise" de um projeto open source chamado Jopr, que é construído sobre outro projeto open source chamado RHQ. Ou seja, assim como o RHEL está para o Fedora e o JBoss EAP está para o JBoss.ORG, o JON está para o Jopr. Este é o modelo da RedHat.

Figura 1 - RHQ Project Homepage

Figura 2 - RHQ Project

Figura 3 - Jopr (apesar da logo ser do RHQ, a tela é do Jopr).

A propósito, vale a pena dar uma lida nesta entrevista com Chris Morgan, um dos líderes do projeto Jopr.

 

2. O JON resolve todos os meus problemas de monitoração?

NÃO! Não é responsabilidade do JON a monitoração e controle de ativos de rede, máquinas, sistemas operacionais, bancos de dados etc. Ele até realiza parte deste trabalho, mas não é o seu foco. Seu foco é no servidor de aplicação JBoss (que roda sobre um SO, que roda sobre um hardware, que roda sobre uma rede….) e em seus sub-elementos. Para o acompanhamento de outros níveis, acima ou abaixo do app server, existem outras ferramentas (livres) que, se devidamente utilizadas junto ao JON, formam uma suite imbatível para administração pró-ativa de toda infra. Outro dia eu falo dessas outras ferramentas (os quadrinhos cinzas da figura 4 abaixo).

Figura 4 - Monitoração, cada um no seu quadrado

Basicamente, o JON possui 3 focos distintos:

(a) monitoração e controle
(b) distribuição de software
(c) disponibilização do conhecimento

De longe, o primeiro item, (a), é o que está mais maduro na ferramenta. Por ele, é possível realizar a coleta de métricas dos recursos inventariados pela ferramenta, analisá-las visualmente, configurar alertas com base nas mais diversas condições e estabelecer políticas preventivas de administração.

Figura 5 - JON, Monitoração

Figura 6 - JON, Controle

Os demais itens (b) e (c), apesar de atrasados quanto ao primeiro, já tiveram seu desenvolvimento inicalizado e demonstram-se em grandes promessas para um futuro próximo. Por distribuição de software, entende-se a capacidade do administrador do JON controlar e comandar, remotamente, a distribuição de novas releases e patches das ferramentas homologadas para as demais áreas de sua instituição. Já o item (c), disponibilização de conhecimento, tem o propósito de agregar num ponto único todas as informações relevantes para usuários de ferramentas específicas da JBoss. Pelo discurso oficial, não faz sentido que um profissional que paga por um contrato de subscrição de JBoss tenha que garimpar na Rede a solução para seus problemas. Todos os problemas conhecidos deve ser catalogados e suas respectivas soluções devem estar disponíveis através da ferramenta.

Figura 7 - JON, Distribuição de Software

 

3. O JON faz monitoramento em tempo real?

NÃO! Não é do propósito do JON a monitoração em tempo real dos servidores. Sua proposta principal é de viabilizar a consolidação de uma base histórica de dados a partir da qual pode-se extrair informações úteis para a tomada de decisões pró-ativas para adequação do ambiente a tendências de acesso. Para monitoramento em real time, é melhor buscar uma ferramenta de profiling, como o JBoss Profiler que, by the way, foi concebida e é hoje mantida por brasileiros.

Figura 8 - JBoss Profiler

Esta imagem é do JBoss Profiler 1.0. A versão 2.0 já tem o beta disponível e o Edgar está trabalhando na transformação do Profiler num plugin do JON.

Figura 9 - Plugin do JBoss Profiler para o JON

 Conceitos

O principal conceito do JON (e seus familiares Jopr e RHQ) é recurso. Por recurso, entende-se plataformas, servidores e serviços. Plataformas são máquinas fisicas ou virtuais (e.g. Windows, Linux…). Servidores são coisas que rodam dentro das plataformas (e.g. JBoss App Server, Tomcat, Apache, Postgres, IIS…). Serviços são coisas que rodam geralmente dentro de servidores (ou também dentro de plataformas) (e.g. Stateless Session Bean, Datasource, Connection, Web Application, Virtual Host…). Cada servidor possui um conjunto de serviços próprios. Nos exemplos dados, Stateless Session Beans é um serviço do servidor JBoss App Server, mas Virtual Host já é um serviço do servidor Apache HTTP Server.

Por este mesmo raciocínio, cada tipo de recurso possui métricas e controles próprios. Assim, as métricas disponíveis para uma plataforma Linux, por exemplo, não são as métricas disponíveis para uma plataforma Windows ou um servidor JBoss. Veja os exemplos abaixo:

Métricas de uma Plataforma Linux

• Free Memory
• Used Memory
• Total Memory
• Free Swap Space
• Used Swap Space
• Total Swap Space
• Idle
• System Load
• User Load
• Wait Load
• … 

Métricas de um Servidor JBoss

• Active Thread Count
• Active Thread Group Count
• JVM Free Memory
• JVM Max Memory
• JVM Total Memory
• Transactions Active
• Transactions Committed
• Transactions Committed per Minute
• …
•  

Métricas de um Serviço Datasource

• Total Connections
• Available Connections
• Active Connections
• Connections Created
• Connections Created per Minute
• Connections Destroyed
• Connections Destroyed per Minute

Arquitetura

O JON segue uma arquitetura Servidor/Agentes (como o Nagios). Normalmente, instala-se 1 JON Server e N JON Agents. Para cada plataforma a ser monitorada, um JON Agent deve ser instalado. O agente do JON é o responsável por realizar a descoberta dos servidores e serviços da plataforma onde está instalado, coletar localmente suas informações e enviá-las periodicamente ao servidor do JON para serem consolidadas e apresentadas visualmente. É também responsabilidade do agente receber instruções enviadas pelo servidor e processá-las localmente, como, por exemplo, a reinicialização de um JBoss.

Cada agente, por sua vez, é composto por um conjunto de plugins. Cada plugin define um escopo de funcionalidades do agente. Então, no fundo, no fundo, o conjunto de métricas coletadas pelo agente e o conjunto de operações que podem ser comandadas remotamente em qualquer recurso dependem essencialmente do conjunto de plugins disponíveis dentro do agente.

Na prática, o que distingue o RHQ do Jopr é basicamente o conjunto de plugins embutidos em seus agentes. A grosso modo, o RHQ não possui os plugins de JBoss, Hibernate e Tomcat que o Jopr tem. Isso quer dizer que no Jopr é possível monitorar JBoss, Hibernate e Tomcat e no RHQ, não. Simples assim.

Mas, o melhor de tudo, é que a partir do momento em que o JON passou a compartilhar o codebase do projeto RHQ, na versão JON 2.0, a arquitetura de plugins dos agentes foi aberta. Com isso, tornou-se possível a nós, desenvolvedores ordinários, criar plugins para o JON. Isso quer dizer que, desde então, é possível monitorar qualquer software pelo JON, desde que um respectivo plugin seja desenvolvido.

Por isso que, recentemente, uma penca de plugins apareceram na net. Dentre eles, plugin pro Oracle, Hudson, Continuum, Jira, MySQL etc. Isso só enriquece o JON/JOPR/RHQ e todos nós só temos a ganhar.

BAM

A última moda do JON, entretanto, é seu uso como instrumento de Business Activity Monitoring.

Utilizando-se de sua infra-estrutura de criação, distribuição e gerenciamento de plugins, tem-se extendido o JON para monitoração e controle de aplicações corporativas. Neste sentido, define-se a coleta e computação de métricas com significado de negócio e beneficia-se de toda estrutura do JON para análise dessas informações e definição de alertas quando da extrapolação superior ou inferior de baselines pré-definidos. Por exemplo, num sistema do Ministério da Educação, pode-se criar um plugin para o sistema do ENEM que aponte o número de inscrições por minuto, ou a taxa de variação das vendas de uma empresa privada ou ainda o ainda a carga horária média de trabalho de minha equipe de consultoria. Aqui, a imaginação é o limite.

Legal, né?

Futuro

 Muito tem sido investido na plataforma RHQ/Jopr/JON. Aparentemente, a RedHat tem pretensões de fazê-la pivô de administração de seus projetos.

Se você é administrador JBoss, faça o teste. Se você é desenvolvedor Java, aproveite a oportunidade para a construção de coisas interessantes. Se quiser uma ajuda, utilize o gerador de plugins do Heiko que, durante a construção deste post, foi lançado e atualizado.

Se não for tirar férias em Janeiro, aproveite e assista o Webinar sobre Jopr que será realizado no dia 13.

 

[]s e boas festas!