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.
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
