Metodologie di monitoraggio in Java

Tesi di Luca Armani 
 
6 
Il capitolo 1 tratta in generale il tema del monitoring, quali obiettivi si 
ponga, quali tecniche utilizzi e su quali parametri si possa stabilirne la 
bontà. 
Il capitolo 2 tratta più dettagliatamente il problema del monitoring 
delle risorse, con particolare riferimento alle risorse fisiche di una macchina 
e a come queste vengano gestite dai sistemi operativi. 
Il capitolo 3 presenta una panoramica della tecnologia Java, cercando 
di approfondire la comprensione dei meccanismi e degli strumenti che 
possono essere di ausilio per il controllo delle risorse. 
Il capitolo 4 stabilisce le specifiche del monitor che si intende 
realizzare: viene spiegato il suo funzionamento ed è presentata l’interfaccia 
del prototipo. 
Il capitolo 5 documentata i dettagli tecnici che hanno permesso - ma 
anche vincolato - la reale implementazione del progetto. 
Il capitolo 6 applica il sistema di monitoraggio ad un caso reale, 
ovvero il sistema ad agenti SOMA sviluppato dall’Università di Bologna. 
Tesi di Luca Armani 
 
7 
Capitolo 1 
Monitoring 
 
 
1.1 Generalità 
Per monitor si intende un sistema, locale o distribuito, software o 
hardware, che raccolga informazioni su un sistema da osservare detto 
target. Tali informazioni sono rilevate da un apparato di sensori. Compito 
del monitor è quello di trasformare questi dati in una forma comprensibile, 
darne una visualizzazione significativa a seconda degli scopi proposti ed 
eventualmente intraprendere delle azioni (callback) per correggere o 
migliorare le prestazioni del sistema monitorato. 
In figura 1.1 è riportato lo schema di funzionamento di un monitor. Le 
misure condotte sul sistema target permettono al monitor di conoscerne lo 
stato; inoltre, fissate certe proprietà di funzionamento, il monitor può 
intraprendere delle azioni (sulla configurazione del sistema o sui suoi 
ingressi) atte ad ottenere il funzionamento voluto [Coc95]. 
Si analizzeranno dapprincipio gli scopi che un monitor si prefigge di 
raggiungere e le caratteristiche salienti da tenere in considerazione per 
realizzare le specifiche richieste. Parallelamente, si darà una classificazione 
dei sistemi di monitoraggio mettendo in luce vantaggi e svantaggi di 
Figura 1.1: schema di funzionamento di un monitor 
carico
configurazione
Sistema
da
monitorare
Monitor
azioni
Tesi di Luca Armani 
 
8 
ciascuna scelta di progetto. 
1.2 Obiettivi 
Gli scopi che spingono allo sviluppo di un monitor sono molteplici, e 
ciò giustifica il campo vastissimo in cui oggi sono impiegati i sistemi di 
monitoraggio. Per fare alcuni esempi basti citare il controllo di dispositivi 
industriali in previsione di guasti, la registrazione e verifica di transazioni 
commerciali, gli strumenti per amministrare intere reti informatiche, i 
sistemi che regolano il traffico di aerei e treni, e così via. 
In definitiva è possibile riassumere le funzioni di un monitor nelle 
seguenti, che saranno analizzate in dettaglio [Sch95]: 
• controllo della correttezza; 
• controllo delle prestazioni; 
• affidabilità; 
• sicurezza; 
• testing e debugging; 
1.2.1 Controllo della correttezza 
È importante verificare che un’applicazione risponda effettivamente 
alle specifiche formali secondo le quali è stata progettata. In questo senso 
un monitor che controlli periodicamente la correttezza e la consistenza dello 
stato dell’applicazione può risultare utilissimo, perché è in grado di trovare 
eventuali errori runtime o violazioni dei requisiti del programma dovute ad 
altre cause. Un esempio può essere costituito da applicazioni di ricerca 
scientifica, in cui è importante garantire l’attendibilità dei risultati. 
1.2.2 Controllo delle prestazioni 
In sistemi che richiedono alti livelli di performance, con utilizzo 
intensivo delle risorse fisiche, è spesso presente un monitor che controlla 
l’allocazione di tali risorse e provvede, all’insorgere di un calo delle 
Tesi di Luca Armani 
 
9 
prestazioni, alla riconfigurazione dinamica dell’intero sistema. Un esempio 
è costituito da un monitor che garantisca del load-balancing in una 
sottorete, cioè un’ottimizzazione del carico di lavoro su ciascun nodo. 
Spesso più semplicemente sono presenti soltanto strumenti di 
visualizzazione, e il compito della riconfigurazione viene demandato ad un 
operatore umano. 
1.2.3 Affidabilità 
In numerosi sistemi è richiesto un alto grado di affidabilità, cioè deve 
essere assicurata la continuità di funzionamento della macchina a fronte di 
eventuali guasti. Un monitor può ben assolvere questo compito analizzando 
lo stato del sistema target: ogni malfunzionamento deve essere rilevato e 
notificato con un allarme, inoltre deve essere intrapresa un’azione che 
corregga o argini l’errore permettendo il proseguimento dell’esecuzione del 
programma in condizioni controllate. Ad esempio, nell’ambito delle 
applicazioni distribuite spesso esiste un controllore che assicura che la 
caduta di un nodo non pregiudichi il funzionamento del resto del sistema. 
1.2.4 Sicurezza 
Per sicurezza si intende il controllo delle autorizzazioni ad eseguire 
una data operazione. In numerosi sistemi infatti non tutti gli utenti hanno i 
diritti per eseguire determinate azioni. È quindi necessario un monitor che 
prevenga eventuali accessi illegali o altre violazioni della sicurezza, 
impedendo che il sistema risulti corrotto. Un esempio lampante sono le 
registrazioni delle transazioni commerciali. 
1.2.5 Testing e debugging 
Storicamente la funzione di testing e debugging è stato il motivo per 
cui sono nati i monitor. Il controllo in profondità di ogni singola azione del 
sistema target si rende necessario per trovare, tra le linee di codice, 
Tesi di Luca Armani 
 
10 
eventuali errori di programmazione. Ogni linguaggio che si rispetti è 
sempre corredato da un debugger che permette di analizzare il 
comportamento del programma istruzione per istruzione. 
1.3 Classificazione 
Un monitor può essere classificato sotto diversi aspetti, tra loro 
indipendenti. È utile adottare precisi criteri di classificazione per ogni 
sistema di monitoraggio perché ognuno di essi, oltre a tracciare le 
specifiche di quel particolare monitor, permette anche di delinearne 
l’architettura in relazione al tipo di misurazione che vogliamo ottenere. Nei 
prossimi paragrafi saranno trattati i seguenti aspetti del monitoring: 
• sensori; 
• raccolta delle informazioni; 
• livello di astrazione; 
• analisi dei dati; 
• sincronizzazione; 
• topologia. 
1.3.1 Sensori 
I sensori sono gli elementi che recuperano le informazioni all’interno 
del sistema, e per questo  sono anche detti sonde. Costituiscono la parte più 
a basso livello di un monitor, perché spesso sono a contatto con i dettagli 
fisici del sistema studiato. Possono essere di vario tipo, in particolare: 
• Sensori hardware. Sono dispositivi fisici aggiunti alla piattaforma del 
sistema target, ad esempio trasduttori o microchip elettronici 
direttamente cablati sul dispositivo che controllano. Sono modestamente 
intrusivi, ossia non interferiscono con la naturale esecuzione del sistema, 
tuttavia i dati forniti sono a bassissimo livello, spesso semplici stream di 
bit. Chiaramente questo tipo di soluzione non è portabile, in quanto tali 
sensori dipendono strettamente dalla piattaforma a cui sono connessi.  
Tesi di Luca Armani 
 
11 
• Sensori software. Sono realizzati mediante linee di codice aggiunte al 
programma monitorato; in ultima analisi le misurazioni sono fatte dal 
sistema operativo che risiede sulla macchina ospite. Questa soluzione 
offre il vantaggio di presentare i dati ad un più alto livello di astrazione, 
aumentando così la flessibilità. Per contro si deve far fronte ad un 
overhead, ossia parte del tempo di esecuzione è dedicata al 
monitoraggio e l’applicazione risulta così rallentata.  
1.3.2 Raccolta delle informazioni 
Fra le varie strategie per raccogliere le informazioni si possono 
distinguere due tipi di approccio, comunemente definiti orientato agli eventi 
e orientato ai tempi. 
• Event driven. L’approccio orientato agli eventi consiste nel rilevare la 
misura a fronte di un evento interno al sistema. Per evento si può 
intendere un messaggio, un segnale, un fault, o qualunque altra cosa  che 
dia una visione più legata al funzionamento “logico” del sistema target. 
• Time driven. La raccolta delle informazioni avviene in corrispondenza 
di determinati istanti di tempo, ad esempio ad intervalli regolari. Una 
frequenza di campionamento molto alta può garantire una migliore 
definizione dei dati raccolti, tuttavia sarà anche maggiore l’intrusione 
del monitor stesso,  in quanto la misurazione interromperà più 
frequentemente l’applicazione misurata. Questo tipo di approccio si 
presta più per una visione statistica del sistema target, in quanto ne 
raccoglie lo stato a prescindere dal modello di funzionamento. 
1.3.3 Livello di astrazione 
È importante stabilire il livello di astrazione a cui si devono presentare 
i dati, perché ciò definisce l’interfaccia che deve avere il monitor verso 
l’esterno e il dettaglio con cui le informazioni sono fornite. Un sistema di 
monitoraggio può dunque collocarsi su uno dei seguenti livelli [Sch95]: 
Tesi di Luca Armani 
 
12 
• Livello fisico. Il monitor osserva attività di basso livello, cioè 
strettamente legate ai dettagli tecnici o ai dispositivi fisici del sistema 
monitorato. Ad esempio può essere interessante monitorare su un 
computer il numero di page fault, o la coda di accesso al disco, e così 
via: queste informazioni sono generalmente destinate ad un operatore 
umano esperto del sistema, e sono utili per una corretta configurazione 
delle risorse. 
• Livello di supporto. Il monitor osserva quelle attività che riguardano 
l’ambiente in cui esegue l’applicazione monitorata. Ad esempio si 
possono misurare il numero di chiamate di sistema o di altri servizi 
messi a disposizione dal sistema operativo. Questo serve per mantenere 
un’attività di management sul sistema: si assicura che tutte le 
applicazioni interagiscano nel modo corretto con il supporto, e che 
questo gestisca in modo controllato le comunicazioni inter-applicazione 
e fra applicazione e risorse. 
• Livello di applicazione. Il monitor osserva l’esecuzione interna di una 
applicazione, verifica che il funzionamento sia corretto e che lo stato 
rimanga comunque consistente. Ad esempio si può tenere traccia del 
valore di una variabile. Questo tipo di monitoraggio è volto ad assistere 
l’applicazione in operazioni considerate critiche. 
Quasi sempre questi tre aspetti convivono, e viene messo in evidenza 
l’uno o l’altro a seconda della visibilità desiderata dall’utilizzatore finale 
del sistema di monitoraggio. 
1.3.4 Analisi dei dati 
Nel progetto di un sistema di monitoraggio è importante definire il 
momento in cui i dati raccolti verranno effettivamente visualizzati e/o 
analizzati, perché ciò si ripercuote sul tipo di utilizzo che si intende fare del 
monitor. In generale si possono realizzare due tipi di strategia: on-line o off-
line. 
Tesi di Luca Armani 
 
13 
• Monitor on-line. Le informazioni sono rese disponibili durante 
l’esecuzione dell’applicazione stessa, dimodochè è possibile 
un’interazione dinamica tra monitor e sistema monitorato. È ovviamente 
il caso più interessante perché offre la possibilità di sfruttare 
immediatamente le azioni automatiche del monitor. Spesso in questi casi 
il monitoraggio è parte integrante del sistema, cosicché risulta difficile 
quantificare il reale overhead introdotto in termini di tempo di 
esecuzione. 
• Monitor off-line. La raccolta delle statistiche dell’applicazione è fatta 
post-mortem, cioè al termine di una sessione del sistema target. 
Tipicamente questo tipo di soluzione ha una funzione di logging, cioè 
tutti gli eventi vengono registrati in modo che successivamente sia 
possibile ripercorrere la storia del funzionamento del sistema. 
1.3.5 Sincronizzazione 
Il monitoraggio può essere sincrono o asincrono, a seconda del tipo di 
coordinazione che si vuole ottenere tra il sistema target e il monitor stesso. 
• Controllo sincrono. Le linee di codice del monitor vengono inserite 
direttamente nel codice dell’applicazione: esse rappresentano dei forti 
vincoli che il programma deve soddisfare per poter proseguire 
l’esecuzione. Il monitor è dunque parte integrante dell’applicazione e ne 
controlla il corretto funzionamento man mano che questa procede, 
impedendole di eseguire operazioni non concesse. 
• Controllo asincrono. Il monitor è tipicamente un processo esterno che 
ispeziona l’applicazione da monitorare in corrispondenza di determinati 
istanti di tempo o eventi. Questo meccanismo realizza dei vincoli molto 
meno stringenti, in quanto l’applicazione è indipendente dal monitor e 
può proseguire la sua esecuzione prima che il monitor stesso abbia il 
tempo di lanciare un eventuale allarme. In generale questo tipo di 
controllo è più flessibile e trasparente, perché lascia più autonomia al 
Tesi di Luca Armani 
 
14 
sistema monitorato e consente al monitor di essere facilmente 
aggiornato. 
1.3.6 Topologia 
La struttura dell’entità da monitorare decide quale dovrà essere la 
topologia del monitor che compie le osservazioni. La maggiore distinzione 
si ha certamente fra monitor locali e distribuiti. 
• Monitor locale. Per monitor locale intendiamo un monitor che raccoglie 
informazioni su una applicazione che esegue sulla stessa macchina. Un 
esempio è rappresentato da un programma che misura l’utilizzo della 
CPU. 
• Monitor distribuito. Un monitor distribuito raccoglie informazioni su un 
insieme di nodi collegati in rete, e presenta informazioni aggregate che 
descrivono in sintesi lo stato dell’intero sistema. Un tipico esempio è un 
sistema software che permette l’amministrazione remota di una 
sottorete. 
1.4 Caratteristiche 
Finora si è parlato delle specifiche di un monitor in funzione degli 
scopi che si prefigge di raggiungere; tali specifiche decidono in larga parte 
la natura del monitor. Tuttavia esiste una serie di caratteristiche che un 
monitor realizza in minore o maggiore misura a seconda di alcune sue 
grandezze e parametri tipici.  Questo concetto è più facilmente 
comprensibile dal punto di vista pratico: infatti, prima di realizzare un 
prototipo che effettivamente implementi le specifiche desiderate, bisogna 
quantificare il grado di completezza, osservabilità, intrusione e correttezza 
che tale monitor deve avere nei confronti del sistema monitorato. Questi 
problemi di dimensionamento, tipicamente ingegneristici, ed altre 
considerazioni, verranno trattati nel seguito. 
Tesi di Luca Armani 
 
15 
1.4.1 Completezza 
Per completezza si intende la capacità di esprimere, da parte di un 
insieme di eventi, la totalità degli stati di una applicazione. Appare non 
impossibile, ma particolarmente oneroso, cercare di rappresentare tutti gli 
stati in cui un’applicazione si può trovare. Ciò si tradurrebbe in una mole di 
informazioni molto grande e difficile da trattare, la cui elaborazione 
graverebbe troppo sul tempo di esecuzione del sistema. Generalmente un 
monitor cercherà di ridurre lo spazio degli stati alle sole situazioni 
interessanti, in modo da raggiungere un giusto compromesso tra 
significatività delle informazioni e loro dimensione. 
1.4.2 Osservabilità 
Una delle peculiarità di un monitor è quella di riuscire ad osservare 
interamente tutti gli eventi di interesse del sistema monitorato  senza 
perderne alcuno; in tal caso si dice che il sistema è completamente 
osservabile. Questo aspetto evidentemente dipende dalle prestazioni del 
monitor stesso, cioè dai suoi tempi caratteristici. Con riferimento alla figura 
1.2 si definiscono: 
• Delay Time (DT). È il ritardo con cui il monitor notifica un evento, 
ossia il tempo che intercorre tra il verificarsi di un evento e il suo 
riconoscimento.  
• Reaction Time (RT). È il tempo che il monitor impiega per dare il via ad 
Figura 1.2: tempi caratteristici di un monitor 
eventevent
time
DT                    RT                             AT
CT
Tesi di Luca Armani 
 
16 
un’azione. Questo tempo è tanto maggiore quanto più è complesso 
l’algoritmo che calcola il nuovo stato e decide quale azione eseguire.  
• Action execution Time (AT). È il tempo di durata dell’azione, che 
dipende strettamente dalla natura del problema. 
• Cycle Time (CT). È la somma dei precedenti. 
Il cycle time indica il “potere risolutivo” del monitor, cioè la minima 
distanza che due eventi possono avere affinché il monitor riesca a 
distinguerli. Se infatti un evento si manifesta dopo un tempo t<CT rispetto 
al precedente il monitor non è in grado di rilevarlo: l’evento è perso e il 
sistema non è più completamente osservabile. Cercare di minimizzare 
questi tempi caratteristici significa trovare un’implementazione quanto più 
efficiente per le sonde e il codice del monitor. 
1.4.3 Intrusione 
Un sistema di monitoring presuppone sempre una intrusione nel 
sistema monitorato. Per il principio di Heisenberg, secondo il quale 
qualsiasi misurazione influenza l’entità misurata, il programma osservato 
subisce un overhead da parte dello stesso monitoraggio. Quanto contino 
queste perturbazioni dipende dal tipo di sonde del monitor (risorse dedicate 
possono limitare l’intrusione), dal grado di precisione delle misurazioni e 
dall’efficienza degli algoritmi. In particolare non si può più prescindere da 
quest’ultimo punto, tanto che la bontà di un progetto si misura spesso 
dall’efficienza e correttezza dell’implementazione. Da questo punto di vista 
la scelta del linguaggio e delle risorse da utilizzare risulta fondamentale. 
Di diverso tipo ovviamente risulta l’intrusione delle azioni (callback) 
a fronte di particolari condizioni: tale intrusione è infatti volontaria ed è uno 
degli scopi del monitor, ciononostante va detto che è comunque 
un’alterazione - controllata - del naturale svolgimento del programma 
monitorato.  
Tesi di Luca Armani 
 
17 
1.4.4 Correttezza 
Per correttezza intendiamo una caratteristica generale del monitor, che 
in definitiva dipende da una buona caratterizzazione dei tre punti 
precedenti. 
Paradossalmente gli stessi problemi che affliggono l’applicazione 
monitorata possono verificarsi sul monitor: come qualsiasi sistema software 
esso può essere non corretto, e in taluni casi quindi può succedere che non 
venga riportata una condizione d’allarme vera, o che invece si riporti come 
errato un funzionamento corretto. Ciò può succedere perché: 
• un evento è stato perso per scarsa osservabilità del sistema; 
• uno stato del sistema monitorato è stato interpretato in modo sbagliato, 
per scarsa espressività o per un errore nell’algoritmo; 
• non si sono valutate attentamente possibili condizioni di errore. 
Si deve fare particolarmente attenzione a questi tipi di errore perché 
spesso, per alcune esecuzioni “fortunate”, non lasciano traccia, facendo 
credere che il sistema sia robusto: è il caso di alcuni fenomeni di deadlock 
che si verificano solo in concomitanza di particolari circostanze, che 
devono però essere assolutamente evitate. 
1.5 Considerazioni 
In questo capitolo si è definito che cosa sia un monitor e quali 
funzioni svolga. Si sono delineate le sue caratteristiche e gli aspetti che le 
possono influenzare. 
Progettare un buon monitor significa definire le specifiche del 
problema, trovare delle tecniche di soluzione adeguate e sviluppare delle 
implementazioni corrette ed efficienti. Una giusta regolazione dei parametri 
caratteristici del monitor consente infine di ottenere i massimi benefici sul 
sistema monitorato.