Lo script di startup utilizzato è stato testato in un sistema operativo Linux Centos 5.x per la versione Mule ESB 3.2 standalone. Potete eseguire il download dello script al link seguente: Mule ESB service startup script (15)

Ci sono alcune configurazioni da modificare nello script che dipendono dalle installazioni di Mule e della JDK necessaria per il suo avvio. Nel mio caso, infatti, l’installazione di java non è da repository ma direttamente dal pacchetto fornito da Oracle. Quindi:

• JAVA_HOME=/path/to/java/home – modificate questo valore in base al path di installazione della JVM; se invece questa variabile si trova già fra le variabili d’ambiente del server, potete commentare la riga;
• MULE_HOME=/path/to/mule/home – modificate questo valore in base al path di installazione di Mule ESB standalone;
• MULE_OWNER=mule – modificate questo valore con il nome dell’utente con cui volete avviare il processo; è sempre buona norma evitare di dare permessi eccessivi al servizio.

A questo punto per eseguire lo start di Mule ESB come servizio si deve eseguire il comando

/etc/init.d/mule_service.sh start

mentre per fermarlo

/etc/init.d/mule_service.sh stop

Sono previsti inoltre altri due comandi:

/etc/init.d/mule_service.sh restart

per riavviare il servizio e

/etc/init.d/mule_service.sh status

per verificare lo stato del servizio, confrontando il valore del file pid generato all’avvio con i processi attivi sul server.

Per impostare l’avvio di Mule ESB come demone, lo script deve essere copiato nel path /etc/init.d, assegnando come utente e gruppo proprietari root

chown root:root mule_service.sh

e come permessi 755

chmod 775 mule_service

Poi si deve configurare lo script per l’avvio come servizio, ad esempio utilizzando il comando chkconfig:

chkconfig  –add mule_service.sh

chkconfig  –level 345 mule_service.sh on

A questo punto siamo sicuri che il servizio partirà con un eventuale riavvio del server.

Come visto nel precedente articolo, nella versione 6 del Tomcat due delle tre porte necessarie per il monitoraggio remoto tramite strumenti come JVisualVM vengono esposte randomicamente ad ogni avvio del servizio, rendendo di fatto necessaria una loro ricerca tra i socket in ascolto sul server remoto. Con Tomcat 7 è stata introdotta la possibilità di impostare tutte e tre le porte a cui collegarsi, consentendo quindi anche di richiedere eventuali aperture mirate sul firewall.

La procedura per attivare la possibilità di monitoraggio remoto tramite JMX prevede innanzitutto la copia del JMX Remote Jar nella directory lib dell’installazione di Tomcat. Trovate questo file nella stessa pagina del download del servizio. Successivamente, non resta che effettuare due semplici configurazioni:

• aggiungere alla variabile d’ambiente CATALINA_OPTS nello script di startup del servizio le direttive per attivare la porta jmx, che sono (ipotizzando di bypassare l’autenticazione):
  
  CATALINA_OPTS=”-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.ssl=false
  -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=HOSTNAME”;

  in cui la porta 12345 è la prima delle tre che verrà utilizzata a questo scopo;

• aggiungere la configurazione del Listener JMX nel file server.xml che si trova nella directory conf/ del path di installazione di Tomcat 7:
  
  <!– REMOTE JMX –>
  <Listener className=”org.apache.catalina.mbeans.JmxRemoteLifecycleListener” rmiRegistryPortPlatform=”10001″ rmiServerPortPlatform=”10002″ />

  impostando di fatto i valori delle altre due porte a cui ci si dovrà collegare (10001 e 10002 nel nostro caso).

Non resta che riavviare il servizio e collegarsi tramite uno strumento come JVisualVM alla porta 12345 del server remoto. Nel caso in cui l’accesso alle tre porte fosse bloccato dal firewall, sarà necessario eseguire un tunnel ssh con cui renderle disponibili localmente.

Ottenere un heap dump della memoria

Per iniziare l’analisi della memoria è necessario ottenere un heap dump dell’applicativo Java. Eclipse MAT consente di ottenerne uno dai processi attualmente eseguiti sul pc, che vengono presentati con un comodo elenco. Nel caso in cui l’applicativo risieda su un’altra macchina, sarà necessario procurarsi il dump della memoria in un altro modo (usando ad esempio i binari Jmap o Jconsole disponibili nel pacchetto di una JVM).

Overview dello consumo di memoria

Un primo grafico a torta ci presenta lo stato complessivo della memoria del processo. Si ha subito un’indicazione visiva degli oggetti che occupano più spazio.

Con il grafico di tipo “Dominator Tree”, invece, si ottiene una lista ordinata di tutti gli oggetti con relativo package, con l’indicazione dettagliata della percentuale di memoria heap occupata.

Class reference

Con lo strumento Inspector si ottiene il dettaglio della “Class Reference”, in cui vengono elencate tutte le classi con il tipo, il numero e la dimensione degli oggetti utilizzati al loro interno, oltre ad una serie di altri dati.

Leak suspects

Con i grafici relativi ai sospetti leak entriamo nella caratteristica a mio avviso più interessante di Eclipse MAT. C’è infatti l’indicazione precisa delle potenziali cause di un out of memory, descritte sia come grafico a torta sia con una breve descrizione lista degli oggetti relativi.

Top consumers

Infine, i Top Consumers sono gli oggetti che occupano la dimensione maggiore nella memoria heap.

Scarica Eclipse MAT dal sito ufficiale.

I requisiti per poter monitorare Tomcat su un server remoto protetto da firewall sono tre:

• avere accesso tramite ssh al server
• configurare la porta jmx sul servizio
• disporre di uno strumento di monitoraggio, come ad esempio Jvisualvm

Innanzitutto dobbiamo abilitare la porta jmx di Apache Tomcat. Per
farlo, è sufficiente aggiungere la riga seguente allo script di startup
del servizio:

Queste configurazioni servono per abilitare la porta jmx (specificata in
jmxremote.port) senza autenticazione e senza accesso ssl (da impostare
in questo modo solo nel caso in cui la porta jmx sia bloccata da
firewall, altrimenti tutti potrebbero averne accesso), con un host
uguale a HOSTNAME (verificate che tale hostname sia specificato nel file
di host del server). A questo punto riavviate il servizio per applicare
le nuove configurazioni. Ora dobbiamo fare in modo di accedere alla
porta jmx con il nostro client di monitoraggio Jvisualvm. Non solo.
Tomcat infatti abilita alcune porte in maniera randomica allo startup
che servono al client di monitoraggio. Dobbiamo quindi capire quali sono le porte a cui ci serve accedere. Per far questo ci viene in aiuto il comando netstat (nel mio caso eseguito su un server linux):

server:/# netstat -lntp | grep java

tcp6 0 0 :::44739 :::* LISTEN 11762/java

tcp6 0 0 127.0.0.1:8005 :::* LISTEN 11762/java

tcp6 0 0 :::12345 :::* LISTEN 11762/java

tcp6 0 0 :::8009 :::* LISTEN 11762/java

tcp6 0 0 :::8080 :::* LISTEN 11762/java

tcp6 0 0 :::48790 :::* LISTEN 11762/java

Con il comando netstat -lntp possiamo visualizzare tutte le
porte TCP su cui sono in ascolto i servizi della macchina. Con l’opzione
-p visualizziamo qual’è l’applicativo che sta usando tale porta. Quindi
ci basta aggiungere un grep java per capire quali sono le
porte utilizzate da una JVM. Nel mio caso non c’erano altri applicativi
java sul server. Escludendo dalla lista le porte classiche utilizzate da
Tomcat (8080, 8009, 8005), rimangono la 12345 (porta jmx impostata da
configurazioni) e le 48790 e 44739. Quindi sono queste tre le porte a
cui serve accedere. Come possiamo raggiungerle se il firewall le blocca?
Disponendo di un accesso ssh, possiamo utilizzare la possibilità
fornita dal tunnel verso un server remoto, con il quale
poter accedere in locale a porte non accessibili direttamente. Se il
client risiede su un pc Windows potete utilizzare le impostazioni
presenti su Putty, per un Linux ci sono le opzioni del comando ssh. Una
volta configurato il tunnel per portare in locale le tre porte,
aggiungiamo sul file di host del nostro pc il valore impostato in
HOSTNAME sulle configurazioni del tomcat, con IP di riferimento locale
(127.0.0.1). Fatto questo, abbiamo Jvisualvm, e sulla colonna Applications facciamo doppio click su Remote. Si aprirà la finestra di inserimento dei dati di accesso al Remote Host. In Host Name inserite il nome dato a HOSTNAME più la porta jmx impostata sulle
configurazioni di Tomcat separati da : (HOSTNAME:12345). Salvete, e dopo
poco sulla colonna delle Applications vedrete apparire la voce del nuovo host remoto inserito. Apritelo e monitorate!

Per utilizzare Jvisualvm avete due possibilità: scaricare ed installare una jdk
( trovate l’eseguibile jvisualvm nella directory bin/
dell’installazione) oppure scaricare l’applicativo in modalità
standalone dal sito ufficiale. L’interfaccia di Jvisualvm risulta essere sicuramente più interessante di quella di Jconsole,
ma di certo non è questo il motivo per cui sceglierlo. Questo strumento
offre la possibilità di controllare sia aspetti inerenti il
comportamento di un applicativo (con la possibilità di verificare ad
esempio l’andamento del Heap Space o di scaricare i dump della memoria
di un particolare thread per poi analizzarlo) che lo stato del processo
(consumo istantaneo di memoria e di cpu, parametri di avvio del
processo, …).

Jvisualvm – elenco applicazioni

La schermata iniziale propone sulla sinistra una colonna con
l’elenco dei processi attivi sulla macchina locale. Da questa lista
potrete visualizzare anche processi remoti a cui collegarvi. Entrando
nel dettaglio di un processo vi apparirà una schermata con quattro tab:

• overview
• monitor
• threads
• profiler

Jvisualvm – overview

In overview potete
visualizzare alcuni dettagli sistemistici relativi all’applicativo (nel
mio caso si tratta del IDE Aptana Studio, basato su Eclipse):

• pid del processo
• host di riferimento
• gli argomenti associati all’eseguibile
• la JVM utilizzata
• gli argomenti della JVM

Jvisualvm – monitor

In monitor sono
presentati tramite grafici gli andamenti dell’utilizzo di CPU, del
consumo di memoria (heap e permgen), del numero totale di classi
caricate e di thread attivi.

Jvisualvm – thread timeline

Jvisualvm – dettaglio di un thread

In threads è
possibile verificare il timeline dei thread, con lo stato (running,
sleeping, wait) di ogni singolo processo figlio nel tempo, oppure il
dettaglio di un singolo processo figlio, con la possibilità di scaricare
il dump della memoria in locale per poi analizzarlo separatamente.

Jvisualvm – profiler

Infine, c’è il profiler,
con il quale è possibile analizzare in un intervallo di tempo
l’esecuzione dell’applicativo con l’indicazione dei metodi invocati e
del consumo specifico di CPU o di memoria.

Una interessante caratteristica di Jvisualvm è la possibilità di ampliarne le funzionalità tramite plugin, che trovate sul sito ufficiale del prodotto.

Ho
letto un paio di articoli molto interessanti su IBM Developerworks, che
è una fonte davvero inesauribile di notizie ed esempi pratici per il
settore IT. Gli articoli si intitolano 5 things you didn’t know about … Java performance monitoring (parte 1 e parte 2).
Vengono descritti alcuni strumenti che possono risultare molto utili
per verificare l’impatto sulle performance del hardware di un server
causato da uno specifico applicativo java. Vediamo di seguito alcuni
degli strumenti che sono descritti in questi articoli.

JCONSOLE

Jconsole è un applicativo visuale il cui binario
è presente nella directory bin/ di una JVM. Consente di visualizzare
graficamente l’andamento di un processo java (locale o remoto)
relativamente a :

• utilizzo di memoria
• percentuale di CPU
• numero thread
• numero classi caricate

Fornisce inoltre informazioni su variabili d’ambiente e MBean.

JVISUALVM

JVISUALVM

Jvisualvm è un applicativo visuale il cui binario è
presente nella direcotry bin/ di una JVM ma può anche essere scaricato
in modalità standalone dal sito ufficiale.
Si nota subito la differenza grafica rispetto alla Jconsole, di cui
ricalca gran parte delle funzionalità, aggiungendo anche la possibilità
di profilare il processo. Consente inoltre di inglobare plugin di terze
parti dal repository ufficiale, che aggiungono funzionalità tra le più
disparate.

JPS

JPS

Jps è un applicativo eseguibile da riga di comando
che consente di visualizzare tutti i processi java attivi su una
macchina (locale o remota) comprensivo di lvmid (cioè un
identificativo del processo relativo alla JVM) e di variabili di avvio.
E’ un sistema veloce e cross-platform per risalire velocemente ai
processi che necessitano di verifiche.

JSTAT

JSTAT

Jstat è un applicativo
eseguibile da riga di comando  che fornisce informazioni
statistiche relativo a vari aspetti di un processo java:

• comportamento del class loader
• comportamento della compilazione
• andamento del processo garbage collector

Vi spiego di seguito la procedura per integrare Javamelody in una web application java. La prima cosa da fare è scaricare dal sito ufficiale
l’ultima versione disponibile del pacchetto. Fra le varie versioni
cercate quella compressa con zip. Apritelo e tenetevi da parte i file
javamelody.jar e jrobin-x.jar. Aggiungete i 2 jar alla directory lib
della vostra webapp. Poi modificate il vostro web.xml inserendo le
seguenti righe:

<filter>
  <filter-name>monitoring</filter-name>
  <filter-class>net.bull.javamelody.MonitoringFilter</filter-class>
</filter>
<filter-mapping>
   <filter-name>monitoring</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
<listener>
   <listener-class>net.bull.javamelody.SessionListener</listener-class>
</listener>

A questo punto rideploiate la vostra webapp ed accedete con un
browser alla pagina relativa alle statistiche di monitoraggio,
accessibile tramite l’indirizzo che ha questo schema generale:

http://<server_host>:<server_port>/<context>/monitoring

Ad esempio, nel mio caso ho provato il monitoring su una webapp chiamata ( in modo molto originale
) test_javamelody, deploiata su un tomcat in locale sulla classica
porta 8080. Quindi l’indirizzo web per il monitoraggio nel mio caso è
http://localhost:8080/test_javamelody/monitoring. La pagina che si
ottiene come risultato fornisce informazioni specifiche della web
application o generiche del sistema su cui il servizio è attivo, grazie
alle quali si può valutare l’andamento istantaneo e nel tempo di vari
parametri critici. Vi riporto di seguito una lista delle informazioni
fornite e le stesse relative alla web application di test:

• grafici dell’utilizzo di memoria e CPU, numero di sessioni HTTP
  attive, thread attivi, connessioni JDBC attive ed utilizzate, numero di
  richieste http (con indicazione di quelle andate in errore), il numero
  di query SQL eseguite (con indicazione di quelle andate in errore),
  tempo di utilizzo del gargabe collector, numero di file aperti
• i valori istantanei dell’utilizzo di memoria;
• le statistiche relative alle richieste HTTP, SQL, agli errori HTTP e di sistema;
• informazioni sul sistema operativo, sulla Java Virtual Machine in uso, sul server utilizzato.

Nel complesso Javamelody si è rivelato uno strumento molto utile e semplice da utilizzare, anche per effettuare verifiche in ambienti di produzione.

Grafici generali

Grafici avanzati

Consumo di memoria

Statistiche

Informazioni sul sistema