Come promesso veniamo alla seconda parte del nostro articolo sul monitoraggio della memoria tramite centreon.

Nella prima parte abbiamo visto come monitorare la memoria globale del server e quella utilizzata da un processo, ora vedremo come entrare nel dettaglio del suo utilizzo da parte dell’applicativo Java.

Per far questo ci avvarremo dell’utilizzo di Jolokia, un tool molto interessante che espone gli MBean del connettore JMX in JSON permettendo un utilizzo semplificato delle risorse.

Jolokia is a JMX-HTTP bridge giving an alternative to JSR-160 connectors. It is an agent based approach with support for many platforms. In addition to basic JMX operations it enhances JMX remoting with unique features like bulk requests and fine grained security policies.

Uno dei punti di forza di Jolokia è sicuramente il fatto che essendo un War può essere deployato su qualsiasi application server Java ed esporre le medesime proprietà, uniformando così il monitoraggio degli applicativi.

L’altro grosso vantaggio è l’esposizione di oggetti complessi come quelli JMX, che normalmente necessitano di un client java per essere interpretati, su protocollo HTTP/JSON, permettendo sia un accesso più semplice e rapido sia una creazione di check e client ad hoc più rapida.

Il rovescio della medaglia è il fatto che comunque per ottenere questi vantaggi è necessario installare una webapp aggiuntiva sul nostro application server, fattore a volte trascurabile, ma che potrebbe essere oggetto di discussione in alcuni ambienti particolarmente attenti alla sicurezza.

Qualora la versione WAR non fosse la soluzione più indicata per il vostro applicativo, Jolokia mette a disposizione una nutrita schiera di Agent differenti: WAR, OSGi, JVM e Mule

Anche lato Client sono disponibili diverse soluzione out-of-the box: Java, Javascript e Perl

Nel nostro caso useremo l’agent standard in formato war e il client perl disponibile su CPAN  Jmx4perl.
Per questo ottimo client esiste direttamente un check nagios che fa esattamente al caso nostro : check_jmx4perl

Per l’installazione dell’agent vi basta deployare il war all’interno del vostro application server da monitorare, se tutto va per il verso giusto, chiamando l’indirizzo http://localhost:8080/jolokia/version dovreste ricevere come risposta un JSON di questo tipo:

Per quanto riguarda il client e il check, colleghiamoci alla macchina di centreon e scarichiamo l’ultima versione del pacchetto dal sito ufficiale (il link è in cima alla pagina).

wget http://search.cpan.org/CPAN/authors/id/R/RO/ROLAND/jmx4perl-1.07.tar.gz

estraiamo il tutto

$ mkdir /usr/local/src/jmx4perl
$ cd /usr/local/src/jmx4perl
$ tar zxvf /tmp/jmx4perl-1.07.tar.gz
$ ln -s -f jmx4perl-1.07 jmx4perl

installiamo i necessari moduli e dipendenze tramite cpan

$ cpan
cpan[1]> install Module::Build
cpan[1]> exit

$ cpan
cpan[1]> install Config::General
cpan[2]> install Crypt::Blowfish_PP
cpan[3]> install File::SearchPath
cpan[4]> install JSON
cpan[5]> install Module::Find
cpan[6]> install Nagios::Plugin
cpan[7]> install Term::Clui
cpan[8]> install Term::ReadKey
cpan[9]> install Term::ReadLine::Perl
cpan[10]> install Term::ShellUI
cpan[11]> install Term::Size
cpan[12]> exit

e concludiamo con la build vera e propria

# perl Build.PL
… ‘jmx4perl’ ? (y/n) [y ]y
… ‘check_jmx4perl’ ? (y/n) [y ]y
… ‘cacti_jmx4perl’ ? (y/n) [y ]y
… ‘j4psh’ ? (y/n) [y ]y
… Term::ReadLine::Gnu ? (y/n) [n ]n
… ‘jolokia’ ? (y/n) [y ]n

# ./Build install

Se tutto è andato per il verso giusto possiamo sperimentare subito il nostro check per controllare lo stato della memoria dell’applicativo che gira su http://192.168.1.10:8080

$ check_jmx4perl –url http://192.168.1.10:8080/jolokia –mbean java.lang:type=Memory –attribute HeapMemoryUsage –path used –base java.lang:type=Memory/HeapMemoryUsage/max –warning 80 –critical 90

OK – [java.lang:type=Memory,HeapMemoryUsage,used] : In range 3.51% (37221672 / 1060372480) | [java.lang:type#Mem

Non ci resta che riportare il tutto in centreon, creando un nuovo comando parametrizzato

e il check vero e proprio, passando tramite l’utilizzo di un service template in modo da poterlo riutilizzare agevolmente su più ambienti.

e con questo abbiamo concluso il nostro monitoraggio, come potete notare anche se l’application server monitorato varia da jboss a tomcat, il check utilizzato e l’output ottenuto sono assolutamente analoghi,

Nel prossimo articolo concluderemo anche la nostra sezione su Jolokia cercando di creare anche un mini-client in javascript che ci permetta di analizzare i vari MBean disponibili e creare check più agevolmente.