- Progress in Training

MASTER UNIVERSITARIO DI II LIVELLO IN
“METODOLOGIE E TECNOLOGIE PER LO SVILUPPO DI
INFRASTRUTTURE DIGITALI”
_________________________________________________________________
TESI DI MASTER
Monitoraggio di una infrastruttura IT
mediante il software Zabbix
Relatore:
Prof. Gennaro BOGGIA
Formando:
Francesco UNGOLO
_________________________________________________________________
ANNO ACCADEMICO 2013 – 2014
Ai miei genitori
2
Indice
Introduzione ............................................................................................................................ 5
Capitolo 1: Principi di funzionamento dei server monitorati ……….. 6
1.1
1.2
Virtualizzazione …………………………………………………………. 6
1.1.1
Virtual Machine Monitor ………………………………………..... 6
1.1.2
Tecniche di virtualizzazione ……………………………………… 8
Xen hypervisor …………………………………………………………. 10
1.2.1
Princìpi ispiratori ……………………………………………....... 10
1.2.2
Architettura …………………………………………………….. 11
1.3
Vantaggi offerti dalla virtualizzazione …………………………………... 14
1.4
Software Zabbix ………………………………………………………... 15
1.4.1
Zabbix appliance ………………………………….……………. 15
1.4.2
Funzionamento …………………………………………….….... 16
Capitolo 2: Descrizione dell’infrastruttura IT da monitorare .............. 19
2.1
Struttura della rete da monitorare ………………………………………. 19
2.2
Server LAN …………………………………………………………….. 21
2.3
Server DMZ ……………………………………………………………. 23
3
Capitolo 3: Messa a punto del sistema di monitoring basato sul
software Zabbix ………………………………………………...………………… 25
3.1
Zabbix front-end ……………………………………………………….. 25
3.1.1
Dashboard …………………………………………………….... 25
3.2
Installazione Zabbix agent ……………………………………………… 27
3.3
Configurazione delle azioni ……………………………………………... 28
3.4
3.5
3.6
3.3.1
Auto-discovery …………………………………………………. 28
3.3.2
Notifica degli eventi …………………………………………….. 30
Administration …………………………………………………………. 31
3.4.1
User & User groups ……………………………………………... 31
3.4.2
Media Types ……………………………………………………. 33
Configurazione degli host da monitorare ……………………………….. 34
3.5.1
Host & host groups …………………………………………….. 34
3.5.2
Items …………………………………………………………… 37
3.5.3
Triggers ………………………………………………………… 43
3.5.4
Grafici ………………………………………………………….. 45
Risultati ottenuti ………………………………………………………... 50
3.6.1
Schermate ………………………………………………………. 50
3.6.2
Mappe ………………………………………………………….. 54
3.6.3
Provvedimenti attuati ………………………………………….... 61
Conclusioni e sviluppi futuri ............................................................................................ 63
Bibliografia ................................................................................................................................. 64
Appendice ................................................................................................................................... 65
4
Introduzione
Il monitoraggio è un servizio fondamentale per ottenere un feedback sul funzionamento di
una infrastruttura IT. Attualmente esistono vari software in grado di fare ciò, alcuni
effettuano un puro monitoraggio indicando semplicemente lo stato di una risorsa ed altri si
limitano a fornire esclusivamente misure di performance.
Zabbix è un software open-source che permette il monitoraggio di tutte le risorse di una
infrastruttura IT e della loro integrità, disponibilità e performance. Inoltre Zabbix usa un
meccanismo di notifica flessibile, permettendo agli utenti di configurare segnalazioni tramite
e-mail per qualsiasi evento.
Tutte le informazioni (configurazione, dati) sono memorizzate in un database relazionale che
costituisce un prezioso storico. Zabbix ha potenti funzioni di visualizzazione (mappe,
overview, grafici e dashboard) grazie a cui è possibile valutare quantitativamente le
performance di sistema. Nonostante sia un sistema di monitoraggio centralizzato, è
progettato per scalare fino a reti grandi e complesse grazie alle funzionalità di Distributed
Monitoring. Tutti i report e le statistiche sono accessibili mediante un front-end basato sul
web, questo garantisce che lo stato dell’infrastruttura possa essere valutata da qualsiasi luogo.
Il lavoro di tesi è stato effettuato al Telematics Lab presso il Politecnico di Bari, in
collaborazione con il Dr. Giacomo Demarinis per la configurazione di rete e di sistema, ed
il Dr. Ruggiero Santoro per quanto riguarda il firewalling della rete.
Il monitoraggio da software Zabbix è stato applicato ad una infrastruttura IT consistente in
una rete di server che offre servizi sia ad utenti esterni che interni alla rete stessa. Tutto ciò,
allo scopo di fornire uno strumento potente e flessibile che consenta di tenere costantemente
sotto controllo l’infrastruttura e soprattutto di segnalare in tempo reale guasti o anomalie nel
funzionamento.
Il lavoro di tesi è strutturato in tre capitoli. Nel primo viene illustrato il principio di
funzionamento del software Zabbix e della virtualizzazione. Nel secondo, viene illustrata la
composizione dell’infrastruttura IT indagata e nel terzo si mostra la messa a punto del sistema
di monitoraggio ed i grafici ottenuti.
5
Capitolo 1: Principi di funzionamento dei server
monitorati
1.1
Virtualizzazione
Per virtualizzazione si intende l'astrazione di una risorsa fisica attraverso un'interfaccia logica
che ne nasconda i dettagli implementativi. Nel caso specifico della virtualizzazione di sistemi
informatici, consiste nella predisposizione ed utilizzo di intere macchine virtuali, differenti
per sistema operativo ed applicazioni installate, sul medesimo sistema hardware. La
predisposizione di un tale sistema viene realizzata mediante utilizzo di uno strato software
intermedio detto VMM (Virtual Machine Monitor) che ha l'effetto di controllare e
regolamentare l'accesso delle macchine virtuali alle risorse fisiche della macchina.
Per spiegare al meglio come si svolge tale processo, si è deciso di introdurre alcuni concetti
di macchina virtuale VM e VMM. La prima definizione di VM risale al 1974 quando Gerald
J. Popek e Robert P. Goldberg scrissero un articolo in cui gettarono le basi teoriche della
virtualizzazione. Benché si riferissero a sistemi di terza generazione, costruiti con i primi
circuiti integrati, l'analisi che fecero può essere considerata valida anche per i moderni sistemi
di quarta generazione, dotati di microprocessori. La definizione che fu data di macchina
virtuale è la seguente:
“Un duplicato software di un computer reale nel quale un sottoinsieme statisticamente dominante di istruzioni
del processore virtuale viene eseguito nativamente sul processore fisico” [1].
1.1.1
Virtual Machine Monitor
Virtual Machine Monitor è un software che risiede e viene eseguito su una macchina reale e
che ha il completo controllo delle risorse hardware. Esso definisce, regola e controlla degli
ambienti di esecuzione virtuali (VM) che forniscono agli utenti un accesso diretto ed
esclusivo alle risorse della macchina fisica [2].
6
Popek e Goldberg definiscono un set di condizioni tali che l’architettura di un processore
supporti la virtualizzazione e le generalizzano per il VMM, che deve quindi soddisfare per
provvedere alla corretta astrazione delle macchine virtuali. Queste condizioni, o proprietà,
sono:
1. Equivalenza: un programma in esecuzione su un VMM deve avere lo stesso
comportamento dimostrato durante l’esecuzione diretta sullo strato hardware
sottostante. Tale proprietà a volte è anche chiamata fedeltà;
2. Controllo delle risorse: il VMM deve avere il completo controllo delle risorse
hardware virtualizzate, usate dai sistemi operativi ospiti;
3. Efficienza: tale proprietà permette l’esecuzione della maggior parte delle istruzioni
senza l’intervento del VMM [1].
Si possono individuare due tipologie di VMM, in base alla collocazione nell'ambiente della
macchina fisica:
• Il VMM di tipo 1 è posto immediatamente sopra l'hardware ed dispone di tutti i
meccanismi di un normale kernel o sistema operativo in quanto a gestione delle
memoria, delle periferiche e del processore; in più implementa i meccanismi di
gestione delle macchine virtuali. Le macchine virtuali eseguite al di sopra del VMM
dispongono di un proprio sistema operativo e sono dette macchine “guest".
Fig. 1.1.1.1: rappresentazione a blocchi di un VMM di tipo 1
• Il VMM di tipo 2 è un normale processo in esecuzione nell'ambito di un sistema
operativo detto “host". Gestisce direttamente le macchine virtuali, che sono suoi
sottoprocessi, mentre la gestione dell'hardware è demandata al sistema ospitante.
7
Fig. 1.1.1.2: rappresentazione a blocchi di un VMM di tipo 2
1.1.2 Tecniche di virtualizzazione
Esistono molteplici tipologie di virtualizzazione di sistemi quali:

La virtualizzazione completa (Full-virtualization) consiste nella completa simulazione
software delle risorse hardware. Per far questo, ogni istruzione eseguita dalle VM
deve essere intercettata e, se è sensibile (istruzione che modifica lo stato delle risorse
del sistema), tradotta a runtime per mezzo di meccanismi software detti “binarytranslation". Il VMM è tipicamente di tipo 2, ovvero un processo eseguito all'interno
dell'ambiente del sistema operativo host. Il SO non sa di essere virtualizzato, per tale
motivo vi è dell’overhead, soprattutto se vi è un largo uso di I/O.

La Paravirtualizzazione (Para-virtualization) offre prestazioni decisamente migliori
rispetto alla virtualizzazione completa (0.5% - 3.0% overhead range [3]), appena al di
sotto degli stessi sistemi non virtualizzati, grazie all'utilizzo di un VMM di tipo 1. Il
VMM utilizzato, detto hypervisor, gestisce direttamente le risorse hardware e fornisce
alle VM un'interfaccia software simile a quella di un normale sistema operativo; la
comunicazione tra VM e hypervisor avviene tramite le hypercalls che sostituiscono
le supercalls utilizzate nei sistemi operativi dalle applicazioni che richiedono l'accesso
all'hardware. Con questo meccanismo è possibile implementare questa tecnologia
anche sulle architetture x86, in quanto le hypercalls consentono di intercettare
qualunque istruzione sensibile eseguita dalle VM, permettendo contemporaneamente
8
alle stesse l'esecuzione di istruzioni non sensibili (user) direttamente sul processore
senza l'intervento del VMM. L'unico svantaggio di questa tecnologia è che i sistemi
guest devono essere opportunamente modificati per poter utilizzare le hypercalls, il
che riduce il numero e il tipo di sistemi operativi effettivamente utilizzabili (i software
proprietari non sono utilizzabili in quanto è necessario avere accesso al codice
sorgente per effettuare le modiche) [4].

Virtualizzazione a livello kernel: in questa tipologia le funzionalità per la
virtualizzazione sono offerte direttamente dal normale kernel del sistema operativo.
Le macchine virtuali così create possono avere ognuna il proprio file-system, ma
condividono il kernel del sistema operativo host. Lo svantaggio di questo approccio
è che possono essere avviate macchine virtuali con un solo tipo di sistema operativo
e che un eventuale falla di sicurezza nel kernel si ripercuoterebbe su tutte le VM.

Virtualizzazione hardware: dal 2005 Intel e AMD hanno cominciato a dotare alcuni
dei processori da loro prodotti di estensioni specifiche per gestire alcuni aspetti della
virtualizzazione direttamente a livello hardware. Queste tecnologie, la VT di Intel e
la Pacifica di AMD, implementano parzialmente nel processore complessi
meccanismi per la gestione delle istruzioni sensibili non privilegiate o per la
traduzione degli indirizzi di memoria delle VM in indirizzi fisici, funzioni che
solitamente spettano al VMM. Piuttosto che essere considerato una tipologia a sè
stante, si può dire che il supporto hardware alla virtualizzazione estende le tecnologie
già esistenti; in particolare, su macchine dotate di questi processori, si possono
teoricamente, para-virtualizzare anche sistemi operativi non modicati. Questo offre
possibilità di virtualizzare con buone performance anche sistemi a codice sorgente
chiuso e quindi non modificabili, come quelli della famiglia Windows [5].

Emulazione: in realtà non è una tipologia di virtualizzazione, ma poiché i due termini
a volte vengono usati indifferentemente in quanto anche l'emulazione permette di
eseguire diverse macchine virtuali su un sistema operativo host, fornendo
un'interfaccia software verso le risorse fisiche. A differenza della virtualizzazione,
l'emulazione non ha lo scopo di eseguire piu operazioni possibili nativamente sul
processore fisico; al contrario è certo che tutte le istruzioni saranno controllate ed
eventualmente tradotte prima di essere eseguite. Questo permette di eseguire anche
ambienti compilati per architetture diverse da quelle della macchina host; in pratica
un'istruzione di un architettura può essere convertita in una o più istruzioni
9
equivalenti di un'altra architettura e poi eseguita. La virtualizzazione invece non
prevede questa eventualità, ma i sistemi operativi guest devono essere compilati per
la stessa architettura della macchina fisica ospitante. Tra i prodotti per l'emulazione
più noti si possono ricordare QEMU, in ambiente Linux, e Microsoft Virtual PC, in
ambiente Windows.
1.2
Xen hypervisor
Grazie alle sue origini nell’open source ed alla folta comunità che ancora oggi contribuisce
in maniera molto attiva allo sviluppo del software, Xen si pone ad essere uno dei più popolari
ed usati monitor di macchine virtuali (VMM). Tuttavia Xen è molto di più che un altro
semplice free VMM, infatti grazie a XenSource oggi Xen è utilizzato anche per le soluzioni
business dei data center. Xen hypervisor offre un potente, sicuro ed efficiente mezzo per la
virtualizzazione di x86, x86_64, IA64, ARM, ed altre architetture di CPU. Supporta una vasta
gamma di Sistemi Operativi tra cui: Windows, Linux, Solaris, e varie versione di BSD.
1.2.1 Princìpi ispiratori
Una delle idee chiave della filosofia di Xen è la separazione tra politiche e meccanismi.
L’hypervisor di Xen implementa i meccanismi, mentre lascia le politiche al Domain-0. Un
meccanismo determina come fare qualcosa, una politica come deve essere fatto [6].
Un esempio concreto di tale separazione è dato dal meccanismo di gestione dei device, infatti
Xen non supporta nessun device nativamente, ma prevede un meccanismo con il quale il
Sistema Operativo ospite può avere accesso diretto al device fisico usando il driver già
esistente.
Anche quando il driver già esistente non è l’ideale per gestire la risorsa, in quanto non è stato
creato con la virtualizzazione in mente e quindi non può gestire più richieste
contemporaneamente da parte di più sistemi, Xen anche in questo caso prevede solo un
meccanismo.
10
In questo modo i Sistemi Operativi guest devono provvedere alla gestione degli accessi,
quindi cooperare tra loro e l’hypervisor.
In contrasto con lo sviluppo degli altri software, ogni nuova release di Xen tenta di fare di
meno delle precedenti (“Less is more”). La ragione di ciò è che Xen gira al più alto livello di
privilegi e per questo un bug nel kernel può compromettere tutto il sistema, comprese le
macchine virtuali [7].
La community di Xen che sviluppa il software è relativamente piccola, perciò lo sviluppo è
concentrato sugli aspetti unici dell’hypervisor piuttosto che su funzionalità già implementate
in altri progetti. Ecco perché i device vengono gestiti dai Sistemi Operativi guest, poiché se
vi è già un driver per Linux per tale hardware, svilupparlo anche per Xen vorrebbe dire sono
un’inutile spreco di tempo. Per mantenere la flessibilità, Xen non forza meccanismi
particolari per le comunicazioni fra domini, ma mette a disposizione dei Sistemi Operativi
ospiti un semplice meccanismo, come la memoria condivisa, e permette ai vari sistemi di
accedervi per scambiarsi informazioni.
1.2.2 Architettura
L’architettura della versione di Xen 4.4 utilizzata, può essere vista come una suddivisione in
tre livelli fondamentali: Hardware, Virtual Machine Monitor (VMM) ed i Domini. La figura
sottostante mostra l’architettura di Xen che ospita quattro VM (Dominio 0, VM1, VM2,
VM3) ed il Virtual Machine Monitor (VMM), responsabile dell’astrazione dell’hardware
sottostante e della gestione dell’accesso per le differenti macchine virtuali. La tecnica di
virtualizzazione utilizzata da Xen è la paravirtualizzazione [7].
11
Fig. 1.2.2.1: Overview dell’approccio paravirtualizzato di Xen
La figura mostra il ruolo speciale della VM chiamata Domain-0 (DOM0), la quale ha accesso
all’interfaccia di controllo della VMM ed è responsabile della creazione, distruzione e della
gestione delle altre VM presenti (chiamate anche Domain-U o DOMU). I software di
gestione e di controllo girano nella Domain-0. L’amministratore può creare una macchina
virtuale con privilegi speciali, nella figura VM 1, la quale può accedere direttamente
all’hardware fisico attraverso una speciale API fornita da Xen. Le altre VM possono accedere
all’hardware sottostante solo grazie alla mediazione che effettua il Domain-0 tramite una sua
API. In questo esempio il Sistema Operativo della VM 1 e VM 2 è modificato per girare su
Xen ed è anche “Xen-aware driver“, nel senso che è a conoscenza delle API da usare per
comunicare con la Domain-0 . Grazie a questo approccio si raggiungono risultati molto vicini
all’esecuzione nativa dei Sistemi Operativi.
Alla partenza, il sistema inizializza un dominio speciale che permette l’uso dell’interfaccia di
controllo, conosciuto come Domain-0 (dom0). Questo dominio iniziale ospita la gestione
software dello user mode, che è responsabile dell’amministrazione dell’ambiente Xen
attraverso i tools della command-line oppure tramite la console XenSource Administration.
Il Domain-0 è anche responsabile della partenza e dell’interruzione dei domini meno
privilegiati, domini ospiti (guest domain), chiamati anche Domain-U (domU). Gestisce
tramite l’interfaccia di controllo, lo scheduling della CPU delle domU, l’allocazione della
12
memoria, e l’accesso ai device fisici come per esempio l’accesso al disco dati o all’interfaccia
di rete, come mostrato in figura 1.2.2.2.
Il dominio di controllo, dom0, funziona come un normale Sistema Operativo Linux.
Possiamo eseguire applicazioni in user mode e gestire il sistema Xen, come anche installare
dei driver per il supporto all’hardware. In questo modo, qualsiasi driver già scritto e
sviluppato per Linux può essere usato anche nell’ambiente di esecuzione Xen, e dà alle
aziende IT un grossa flessibilità nella scelta dell’hardware da usare nelle proprie infrastrutture
computazionali.
Fig. 1.2.2.2: Esempio di uso dei domini da parte di Xen
In definitiva, l’hypervisor è responsabile dell’astrazione del livello hardware e contiene sia
API di Gestione che di virtualizzazione hardware. Al suo interno vi è anche una interfaccia
di controllo che permette alle macchine ospiti di comunicare direttamente o indirettamente
con lo strato hardware sottostante.
Ad interagire con l’API di gestione (Management API) è la regione di controllo che accede
all’hardware e contiene del codice per la gestione dell’user mode [7].
13
1.3
Vantaggi offerti dalla virtualizzazione
Sui server di cui si compone l’infrastruttura di rete monitorata, è presente l’hypervisor Xen
4.4, su cui sono state in seguito installate delle VM con sistema operativo ospite “Ubuntu
Server”. Ad ognuna di esse è demandato il compito di fornire determinati servizi di rete.
Risulta quindi chiaro che ogni server fisico sarà composto da una serie di “host virtuali” (in
seguito chiamati più semplicemente “host”) corrispondenti ad ognuna delle VM installate.
I vantaggi dell'utilizzo di una piattaforma di virtualizzazione sono molteplici, considerando
innanzitutto la riduzione dei costi di
• Acquisto di elaboratori: potendo virtualizzare le macchine fisiche, il numero
effettivo di elaboratori necessari all'attività di un'azienda si riduce enormemente;
• Consumi: riducendo il numero di elaboratori viene ridotto notevolmente il
quantitativo di energia elettrica utilizzata per il loro funzionamento e per l'impianto
di raffreddamento, senza contare inoltre il recupero di volume (spazio rack);
• Manutenzione: vi è una effettiva riduzione del tempo necessario per svolgere le
operazioni sistemistiche più comuni, quali installazione, configurazione, replica e
backup, in quanto il fatto di utilizzare un sistema di virtualizzazione implica che
quello che le VM identificano come il proprio dispositivo di massa, altro non è che
un file di una certa dimensione (alcuni Gigabyte) cui è associato un file di
configurazione proprio della macchina virtuale stessa; quindi interagendo con questo
file, che funge da hard disk virtuale, è possibile svolgere le funzioni sopracitate con
sforzo e tempi ridotti al minimo.
Un ulteriore vantaggio è l'aumento della disponibilità dei servizi erogati, in quanto si ottiene:
• Maggiore tolleranza ai guasti: riducendo il numero di elaboratori la probabilità di
guasti viene automaticamente ridotta;
• Riduzione dei tempi di downtime;
• Semplificazione del ruolo dell’amministratore di sistema grazie alla centralizzazione
ed al monitoraggio dei vari sistemi operativi su una singola macchina fisica;
• Failover e disaster recovery: In questo caso la virtualizzazione può aiutare in
maniera significativa il lavoro dell’amministratore, poichè i server virtuali possono
14
essere agevolmente migrati da una macchina fisica ad un'altra e quindi in caso di
guasto di un server, i suoi servizi possono essere tranquillamente trasferiti su un'altra
macchina senza l’interruzione del servizio;
• Debugging dei Sistemi Operativi e delle applicazioni a run-time, incrementando i
livelli di sicurezza e di isolamento tra i vari sistemi [8].
1.4
Software Zabbix
1.4.1 Zabbix appliance
Una volta creati gli host virtuali, non resta che installare il software Zabbix. A causa del
controllo centralizzato che esercita, ci sono due alternative per installarlo:
a) sul server fisico attraverso l’installazione diretta sul sistema operativo privilegiato;
b) creare una nuova VM a cui è demandato esclusivamente il monitoraggio di tutte le
altre.
Come già detto in precedenza, durante il monitoraggio tutte le informazioni acquisite in
tempo reale vengono memorizzate in un DB relazionale basato su MySQL. Ogni processo
demone Zabbix richiede diverse connessioni al proprio database e la quantità di memoria
allocata per la connessione dipende dalla configurazione del database. Zabbix e soprattutto
il suo database possono richiedere risorse CPU significative a seconda dei parametri
monitorati e del motore del Database scelto. Poiché le operazioni di I/O disco di Zabbix si
limitano alla lettura/scrittura di dati sul server MySQL, a seconda del numero di host e del
numero e della frequenza dei check, le query verso il database possono diventare numerose
a tal punto da degradare le performances del sistema [9]. Risulta quindi conveniente creare
una nuova VM per Zabbix.
Sul sito http://www.zabbix.com/download.php, è possibile scaricare direttamente lo xen
guest adatto. Questa VM prende il nome di Zabbix appliance e fin da subito, ci si rende conto
che tale scelta ha degli ulteriori vantaggi:
15

Centralizzazione del controllo: accedendo via browser all’IP del front-end
dell’appliance, si può avere il controllo dell’intera infrastruttura di rete. A causa del
suo ruolo, l’appliance verrà in seguito chiamata “Zabbix server”;

Fault tolerance: grazie alla delocalizzazione di Zabbix rispetto agli altri host virtuali e
soprattutto rispetto al sistema, un malfunzionamento o interruzione del servizio di
monitoraggio lascia inalterata la disponibilità dei server e dei servizi erogati.
E’ stata utilizzata la Zabbix appliance versione 2.4.1, basata sul sistema operativo OpenSuse
13.1 [10].
1.4.2 Funzionamento
Il funzionamento di Zabbix si basa su tre basilari elementi:
1. Agent: software installato su ogni host da monitorare e che ha il compito di
trasmettere allo Zabbix server i dati richiesti;
2. Item: singolo controllo o una singola performance che viene monitorata dallo Zabbix
server;
3. Trigger: espressione logica applicata al valore di un item, che rappresenta lo stato del
sistema. Può avere due stati: OK quando il valore dell’item monitorato è nella norma
stabilita, altrimenti va in PROBLEM.
Zabbix supporta due tipologie di interrogazioni degli host: polling e trapping. Quando lo
Zabbix server è in polling, interroga costantemente il database, chiedendo cosa gli item
devono controllare, passa alla lista di host e agent a cui appartengono e chiede i dati, li scrive
nel database, li elabora e infine processa tutti i trigger. Lo stato del trigger è ricalcolato ogni
volta che il server riceve un nuovo valore e quest'ultimo è parte dell'espressione del trigger.
Quando il server è trapping, si trova in gran parte inattivo aspettando che l'host o l'agent
inviano i dati. Quando riceverà i dati, riceverà anche la chiave item che il dato rappresenta. Il
server scrive i dati nel Database, li processa, processa anche eventuali trigger. Questa
modalità tende a richiedere meno potenza di calcolo del polling. L'agent si collega al server
periodicamente (di default 2 min), richiedendo una lista di item da controllare e la loro
periodicità.
16
Zabbix supporta anche un altro tipo di dato: l'internal data. Ci sono due distinte categorie di
internal data: i dati che il server mantiene sulle statistiche del database, il numero di item, il
numero di voci history calcolate solo quando vengono chiamati item o trigger e poi le
funzioni aggregate. Le voci history sono dei valori che si trovano nella tabella History del
database Zabbix, questi dati vengono mantenuti per un determinato tempo nella tabella e
sono utili per calcolare la storia di ogni item e di ogni trigger.
Le funzioni aggregate sono pseudo-item che uniscono o aggregano valori da item come in
un gruppo di host. Per esempio si può ottenere il carico medio di CPU per un intero gruppo
di server o il numero totale di utenti loggati in un gruppo di server. Gli Item calcolati vengono
aggiornati con il meccanismo con cui sono stati aggregati (possono essere aggregati con un
meccanismo di polling o con meccanismo di trapping), ad esempio ci siano 5 host in un
gruppo che interroga per il numero totale di utenti, l'item è ricalcolato ogni volta che riceverà
i dati da un host. Questi dati vengono poi scritti nel database, processati e attivati. Se usate
correttamente, queste funzioni possono migliorare la visibilità della salute della rete, tuttavia
grazie al modo di calcolare i dati questi possono aggiungere caricamenti extra al server. È
raccomandato un uso di oggetti aggregati minimo a meno che non si usi la modalità di
trapping.
Ai fini del lavoro svolto, è stato sufficiente servirsi dei controlli tramite polling, il cui
meccanismo può essere così riassunto:
1. Il server esegue una query sul Database chiedendo per ogni item il cui tempo di
controllo vicino è passato (di default 30 s);
2. Il server invia questa richiesta usando la porta configurata per l'host o l'agent. Di
solito Zabbix agent usa la porta 10050;
3. L'agent risponderà alla richiesta con il valore dell'item o con “NOT
SUPPORTED” (l'agent non si preoccupa del tipo di dato di ritorno);
4. Il server scriverà i dati nella tabella item del Database nella colonna Lastvalue.
Inoltre si sposterà il valore precendente nel campo Prevvalue muovendo il Prevvalue
precedente nella tabella History, come da fig. 1.4.2.1;
5. In questa fase il server processa i dati per farli entrare nella tabella trends e qualsiasi
funzione aggregata che include questi dati;
17
6. Zabbix comparerà il valore di ritorno con qualsiasi trigger che deve essere correlato
con questo item, inoltre durante questa fase il server processa i trigger correlati alle
funzioni di aggregazione.
Fig. 1.4.2.1: Meccanismo di data - storage nel database di Zabbix Server
Nei capitoli successivi, verranno illustrate più dettagliatamente le caratteristiche e le
funzionalità di Zabbix, chiarendo i motivi della sua scelta per il monitoraggio
dell’infrastruttura IT assegnata.
18
Capitolo 2: Descrizione dell’infrastruttura IT da
monitorare
In questo capitolo verrà illustrata la struttura della rete da monitorare e la composizione dei
server nei propri singoli host virtuali, evidenziandone anche le connessioni.
2.1
Struttura della rete da monitorare
Lo schema dell’infrastruttura IT da monitorare è riportato in fig. 2.1.1.
Fig. 2.1.1: Mappa dell’infrastruttura IT monitorata
I server presenti sono due: server DMZ e server LAN (Local Network, in figura). Dalla figura
si nota che il primo router (Edge Router) è un dispositivo fisico, mentre il secondo (Main
Router) è costituito da un host virtuale residente sul server LAN.
Configurato in questo modo, Main Router funge da bastion host. Un bastion host è un
sistema fortificato, questo significa che si tratta di un normale sistema operativo e di un
normale hardware a cui sono state assegnate funzioni di controllo o di filtraggio. Ma
soprattutto sul bastion host è stata fatta una configurazione particolare [11]. Ad esempio, è
19
stato installato esclusivamente il software indispensabile per le funzionalità di sicurezza e
solamente i servizi indispensabili. Inoltre Main Router ospita un “application gateway”.
Se si desiderano dei controlli più raffinati, che non siano solo a livello 3 o a livello 4, bisogna
salire fino a livello 7. Al livello 7 si può disporre come sistemi di sicurezza, dei cosiddetti
application gateway. Un application gateway è un punto di controllo dotato anch'esso di una
ACL (Access Control List), che è però in grado di andare ad effettuare i controlli in base ai
dati, o ai comandi applicativi, contenuti nel payload di livello 7. Una ACL è una lista ordinata
di regole che stabilisce quali utenti o processi di sistema possono accedere a degli oggetti, e
quali operazioni sono possibili su questi oggetti [11]. Facendo l'esempio di una rete, ci si
troverebbe a dover decidere se far passare o meno un pacchetto o se permettere o meno ad
un certo utente l'accesso ad un determinato file.
La rete è quindi configurata in modo che l’Edge Router consenta di vedere dall’esterno solo
la sottorete protetta 192.168.20.0/24 e la rete interna non è visibile da internet. Il router
interno, analogamente, segnala alla rete interna 192.168.10.0/24 solo la presenza della
sottorete protetta. I sistemi nella rete interna non possono così stabilire connessioni dirette
a internet.
Questa configurazione è nota anche come “screened subnet” o “architettura a due livelli”
[11], con cui si intendono i livelli di sicurezza delle due sottoreti protetta (in cui è presente la
DMZ) ed interna (LAN). Il principio vuole che gli utenti esterni possano accedere alla DMZ
(limitatamente ai servizi disponibili) e che le risorse interne restino nella zona privata e non
siano accessibili.
Nella DMZ si ospitano i server pubblici (sito Web, server FTP, DNS, mailserver in
ingresso...) che non erogano applicazioni critiche per il laboratorio. Siccome la DMZ è
considerata una zona ad alto rischio, le nuove comunicazioni in arrivo (NEW) dalla DMZ
alla LAN vanno considerate inaffidabili quanto quelle esterne, e per questo bloccate.
La divisione tra le due zone di sicurezza viene operata dai firewall presenti sui due Router.
20
2.2
Server LAN
Questo server eroga i servizi interni per la intranet di Telematics Lab, per questo motivo si
trova nella zona più sicura. Possiede due interfacce fisiche di rete, Eth0 collegata ad uno
switch cui possono collegarsi tutti gli host della intranet ed Eth1 collegata all’Edge Router.
Il server ospita i seguenti host virtuali (DomU) che erogano i relativi servizi:
1. Main Router: Firewall (iptables), VPN (openVPN);
2. Netservices: DHCP (isc DHCP server), DNS (bind), Proxy (Squid);
3. Servers: LAMP, SVN;
4. Trust: Certification Authority (tinyCA);
5. Zabbix Server: monitoraggio.
Ogni host è dotato di un indirizzo IP statico sulla rete interna ed ha una sola interfaccia
virtuale di rete Eth0 che gli permette di comunicare sull’intera intranet. Main Router
naturalmente ne ha anche una seconda Eth1 che, grazie al bridge presente in DOM0 per le
macchine virtuali, riesce a collegarsi all’Edge Router e da qui, ad internet. La fig. 2.2.1
chiarisce come si compone il server LAN e le connessioni tra i suoi host.
21
Fig. 2.2.1: mappa interna del server LAN
Le linee blu indicano connessioni esistenti tra i vari host sulla intranet, le linee verdi invece
indicano le connessioni tra gli host e lo Zabbix server, stabilite sulla intranet dagli agent
installati su ognuno di essi.
Dalla fig. 2.2.1, si nota che è stata aggiunta un’altra interfaccia virtuale di rete al Zabbix Server.
Infatti è proprio da qui che partono le notifiche via mail quando si verifica un evento che lo
richieda. Inizialmente tutto il traffico verso l’esterno passava per Main Router, comprese le
notifiche, ma un guasto proprio su questa macchina impediva la notifica in tempo reale di
questo problema. Per cui si è reso necessario aggirare il Main Router dotando Zabbix Server
di una interfaccia di rete Eth1 da cui spedire autonomamente tutte le notifiche, rendendola
indipendente da Main Router. Ovviamente per mantenere intatta la sicurezza della LAN, è
stato autorizzato solamente il traffico in uscita da Zabbix Server sulle porte 80 (HTTP) e 443
(HTTPS).
Per fare questo, ci si è loggati all’appliance di Zabbix da utente root, e da comando Yast si è
acceduto all’interfaccia di OpenSuse da cui è stato possibile:
22
1. Creare la nuova interfaccia di rete “Virtual Ethernet Card 1” di nome Eth1, con IP
172.17.200.253/24;
2. Assegnare il default gateway su Eth1 all’indirizzo 172.17.200.1/24 (Edge Router);
3. Implementare le regole stabilite per il firewall di OpenSuse su Eth1.
La sicurezza è garantita oltre che dalle regole molto stringenti imposte, dal fatto che Zabbix
server costituisce un application gateway.
2.3
Server DMZ
Questo server eroga i servizi web, come ad esempio il sito di Telematics Lab, per questo
motivo si trova nella zona meno sicura. Possiede una sola interfaccia fisica di rete, Eth0
collegata all’Edge Router.
Il server ospita i seguenti host virtuali (DomU):
1. WWW: LAMP
2. PublicSVN: LAMP
3. Publication: LAMP (attivo solo il server Apache)
Ogni host è dotato di un indirizzo IP statico sulla sottorete protetta ed ha una sola interfaccia
virtuale di rete Eth0 che gli permette di comunicare solo con l’Edge Router, cui è collegato
fisicamente il server.
I singoli host nonostante siano presenti sulla stessa sottorete, sono stati configurati in modo
da rimanere isolati l’uno dall’altro, in modo da massimizzare la sicurezza degli altri due in
caso di attacco di uno. La fig. 2.3.1 mostra tutto ciò.
23
Fig. 2.3.1: Mappa interna del server DMZ
Dalla mappa appena mostrata si vede che l’unica connessione possibile (oltre a quella con
Edge Router) è con Zabbix Server per mezzo dell’agent installato sui singoli host.
Nonostante Zabbix sia presente in un’altra sottorete, la comunicazione via agent per polling
è consentita. Infatti la rete è configurata per rifiutare i nuovi pacchetti (NEW) in arrivo dalla
DMZ alla LAN, ma i nuovi dati che viaggiano nel verso opposto e i pacchetti di risposta
(ESTABILISHED) dalla DMZ alla LAN sono consentiti, dato che quest’ultima è una
sottorete più sicura.
Bisogna solamente aggiornare il file /etc/sysconfig/network/routes su Zabbix Server, con
la seguente riga:
192.168.20.0 192.168.10.1 24 eth0
alla già presente:
default 172.17.200.1 - eth1
creata in precedenza. Ciò funge da configurazione di failover nel caso in cui l’interfaccia Eth1
di Zabbix Server si disattivi, dirottandone le richieste su Main Router che provvederà per
conto suo a farlo recapitare all’host destinatario sulla DMZ. Infine utilizzando Yast da
terminale, si apre la porta 10050 anche su interfaccia Eth1 per consentire il dialogo Zabbix
Server-Agent anche sugli host DMZ.
24
Capitolo 3: Messa a punto del sistema di monitoring
basato sul software Zabbix
In questo capitolo conclusivo verrà mostrato il lavoro svolto, dando risalto alle
configurazioni attuate ed ai risultati ottenuti in forma di grafici e mappe dall’immediata
comprensione, che permettono di raccogliere e monitorare i dati sulla disponibilità e le
performance degli host e dei relativi servizi erogati citati in §2.2, §2.3.
3.1
Zabbix front-end
Lo Zabbix front-end è l’interfaccia web con cui si può consultare lo stato del sistema o anche
modificare le impostazioni di monitoraggio. Risulta locato nella cartella /usr/share/zabbix
dell’utente root sulla Zabbix appliance. Per accedere, basta digitare sul browser di qualsiasi
host presente in intranet, l’indirizzo IP statico assegnato “192.168.10.253”, oppure
configurare il DNS interno associando a tale ip l’alias “zabbix”. In tal modo è sufficiente
digitare: “zabbix/zabbix” e poi effettuare il login con le credenziali da amministratore per
poter iniziare a configurare il tutto.
3.1.1 Dashboard
Appena effettuato il login, la prima cosa che appare è la Dashboard di Zabbix, che offre una
panoramica dello stato dell’infrastruttura, attraverso dettagli di alto livello circa l'ambiente
monitorato. Questa è una delle parti centrali del front-end di Zabbix.
25
Fig. 3.1.1.1: Dashboard di Zabbix
Nella parte superiore della Dashboard c'è una finestra “Server status”. Questa finestra
riassume brevemente lo stato del Server:
• Zabbix server is running: indica che il processo Zabbix_Server è in esecuzione, nel
caso specifico il Servizio è attivo;
• Number of Host: indica il numero di Host monitorati, in totale compresi i Template
che possono essere associati a ciascuno sono 47, nello specifico in totale 8 Host (di
cui 5 nel server LAN e 3 nella DMZ);
• Number of Items: indica il numero di totale Item monitorati, in totale 501 di cui
427 sono attivi;
• Number of triggers: indica il numero di trigger monitorati dal server, in totale 229
di cui 203 abilitati e 26 disabilitati. Nel dettaglio non è stato riscontrato alcun
problema e tutti i 203 trigger funzionano correttamente;
26
• Number of user online: indica il numero di utenti online, nello specifico è possibile
entrare in tre modalità: Admin, Guest e Monitoring. Ci sono due utenti online, Admin
e Monitoring mentre il guest è in modalità off-line;
Subito più in basso c'è la finestra “System status” che specifica lo stato del sistema. Questa
finestra mostra i vari gruppi di Host monitorati dal Server con eventuali tipi di problemi.
Nello specifico ci sono 4 gruppi monitorati, tutti senza alcun problema.
Più in basso, si presenta la finestra “Host status” che fornisce delle specifiche sullo stato degli
Host. In particolare specifica il numero di host con problemi di ogni gruppo e il numero di
host senza problemi di ogni gruppo.
Nella finestra sottostante “Last 20 issues” vengono mostrati meglio i tipi di problemi
riscontrati: Questa finestra indica i problemi rilevati da ogni host con la data dell'ultima
modifica e eventuali messaggi inviati ad altri Server.
3.2
Installazione Zabbix agent
Zabbix agent è un componente installato su ogni host e che consente il monitoraggio delle
sue risorse e dei servizi erogati.
Interrogato periodicamente, l’agent acquisisce i dati dall’host e li riporta allo Zabbix server
per ulteriori elaborazioni. Esistono Zabbix agent per molti dei sistemi operativi esistenti:
Linux, IBM AIX, FreeBSD, NetBSD, OpenBSD, HP-UX, Mac OS X, Solaris: 9, 10, 11 e
Windows: 2000, Server 2003, XP, Vista, Server 2008, 7 [10]. Ognuno di essi è estremamente
efficiente grazie all’uso delle chiamate di sistema native per l’acquisizione dei dati d’interesse.
Su ognuno degli host da monitorare, è stato installato l’agent per Linux, con una procedura
molto semplice data dai seguenti comandi:
user@host:~$ sudo aptitude install zabbix-agent
user@host:~$ sudo nano /etc/zabbix/zabbix_agentd.conf
Server=192.168.10.253
user@host:~$ sudo service zabbix-agent restart
27
Nel secondo comando si edita il file di configurazione dell’agent, inserendo l’indirizzo IP
dello Zabbix Server da cui partiranno le richieste di dati verso l’agent. E’ sufficiente a questo
punto riavviare l’agent per attivare le modifiche e renderlo operativo.
3.3
Configurazione delle azioni
In questo paragrafo verranno descritte sia le funzionalità di scoperta automatica degli host in
rete (auto-discovery), che i meccanismi di notifica attuati dallo Zabbix Server.
3.3.1 Auto-discovery
Si è cominciato andando a configurare la funzionalità di Auto-Discovery sugli host del server
LAN.
Fig. 3.3.1.1: Configurazione della discovery rule su server LAN
Come indicato in fig. 3.3.1.1, i campi da compilare indicano rispettivamente:

Name: nome della regola, in questo caso “Local Network”;
28

Discover by proxy: indica se la ricerca vada effettuata o meno da proxy, nel caso
specifico viene direttamente effettuata da Zabbix Server;

IP range: indica l’intervallo di indirizzi IP su cui indirizzare la ricerca;

Delay: indica l’intervallo di tempo dopo cui Zabbix esegue nuovamente la ricerca, in
questo caso ogni ora;

Checks: indica quale protocollo seguire per intraprendere della ricerca. Sono
disponibili: SSH, LDAP, SMTP, FTP, HTTP, HTTPS, POP, NNTP, IMAP, TCP,
Telnet, Zabbix agent, SNMPv1 agent, SNMPv2 agent, SNMPv3 agent, ICMP ping.
In questo caso si è optato per lo Zabbix agent, è più precisamente per il valore ivi
contenuto nel campo “system.uname”, che riporta il tipo di sistema operativo virtuale
sull’host rilevato [10];

Device uniqueness criteria: definisce i criteri di unicità per la ricerca, che possono
essere “Type of discovery check” consistenti nel controllo SNMP oppure da Zabbix
agent, e “IP Address” come in questo caso, ove se viene rilevato un altro dispositivo
con un IP esistente, si ritiene già rilevato e non viene quindi aggiunto [10].
Infine, come per le successive operazioni di configurazione, si attiva la spunta su “Enabled”
e si clicca su “Update” per attivare il funzionamento della discovery-rule.
E’ necessario adesso configurare l’azione da intraprendere in caso di scoperta di un host. Per
fare questo, si va sul tab Configuration → Actions → Create action e si impostano gli
attributi desiderati. In fig. 3.3.1.2 è riportata la configurazione dell’azione di discovery
intrapresa ogni qualvolta la regola precedentemente impostata rilevi un host.
Fig. 3.3.1.2: Configurazione della Discovery Action attuata ogni qualvolta venga rilevato un server Linux
29
L’azione mostrata in figura si applica a tutti i Linux Server rilevati da tutte le regole di autodiscovery impostate. Gli attributi di ogni azione sono così definiti:

Name: nome dell’azione, in questo caso “Auto discovery. Linux Servers”;

Conditions: condizioni che hanno come risultato 1 (verificate) o 0 (non verificate), e
possono quindi essere combinate secondo le operazioni booleane di AND/OR. Nel
caso considerato, le condizioni riportate in fig. 3.3.1.2 sono tutte poste in AND;

Operations: Se il risultato dell’espressione booleana impostata per le condizioni
risulta 1, vengono intraprese le operazioni descritte in lista. In questo caso, l’host
viene aggiunto al gruppo dei server Linux e gli viene assegnato il relativo template (§
3.5.1).
L’attuazione di tutto ciò, porta al rilevamento dei quattro host presenti sul server LAN. Ciò
viene subito segnalato sulla Dashboard come riportato in figura 3.3.1.3.
Fig. 3.3.1.3: Indicazione del Discovery status sulla Dashboard
Nel caso indicato, “Up” indica il numero di server rilevati ed attivi, mentre “Down” indica il
numero di server rilevati in precedenza, ma attualmente inattivi o assenti. Il numero 2
indicato, è dovuto a degli host cui è stato cambiato l’IP.
3.3.2 Notifica degli eventi
Il secondo tipo di azione utilizzato è il “Trigger Action”, ed è sicuramente il più importante
per il monitoraggio visto che consente la conoscenza in tempo reale degli eventi che
avvengono sui server. Tale azione di notifica è resa possibile configurando la relativa azione
mostrata in fig. 3.3.2.1.
30
Fig. 3.3.2.1: Configurazione della Trigger Action attuata ogni qualvolta un trigger vada nello stato di
PROBLEM
Andando a guardare gli attributi dell’azione riportata in figura, si nota che vengono mandati
messaggi di posta elettronica agli utenti specificati quando qualunque dei trigger attivi
(Enabled) va nello stato di PROBLEM.
3.4
Administration
Il tab “Administration” contiene funzionalità importanti come la gestione degli utenti
ammessi ad utilizzare il front-end e dei relativi permessi, oppure la configurazione dei media
per il recapito delle notifiche.
3.4.1 User & User groups
Tutti gli utenti che possono accedere al front-end di Zabbix, possono farlo con un unico
username e password. Tutte le password vengono criptate e conservate nel database di
Zabbix.
Lo schema dei permessi in base all’utente è così determinato:
1. Zabbix User: l'utente ha accesso al menu “Monitoring”. L'utente non ha accesso a
tutte le risorse di default. Eventuali permessi a gruppi di host (host groups, § 3.5.1)
devono essere esplicitamente assegnati;
2. Zabbix Admin: L'utente ha accesso ai menu “Monitoring” e “Configuration”.
L'utente non ha accesso ad alcun gruppo di host per impostazione predefinita.
Eventuali permessi a gruppi di host devono essere esplicitamente indicati [10];
31
3. Zabbix Super Admin: L'utente ha accesso ai menu “Monitoring”, “Configuration”
ed “Administration”. L'utente dispone di un accesso in lettura e scrittura a tutti i
gruppi di host.
Quanto ai permessi nei confronti dei gruppi di host, ad un singolo utente non può essere
concesso direttamente l'accesso a un host (o gruppo di host). Può essere concesso solo
l'accesso ad un host quando si fa parte di un gruppo di utenti a cui concesso l'accesso al
gruppo di host che lo contiene [10].
Per questo motivo gli utenti vengono assegnati ai cosiddetti “User Groups”, che consentono
di raggruppare vari utenti sia per fini organizzativi che per l'assegnazione dei permessi.
Può spesso avere un senso separare le informazioni disponibili per un gruppo di utenti da
quelle relative ad un altro. Questo può essere realizzato raggruppando gli utenti e quindi
assegnando permessi diversi nei confronti dei vari gruppi di host.
Un utente può appartenere a più gruppi. Ciò costituisce un framework molto flessibile.
Gli utenti presenti di default sono “Admin” di tipo Super Admin e “guest” di tipo User privo
di username e password. A questi ne è stato aggiunto un altro “Monitoring”, dotato di
password ma di tipo User, cui però sono stati aggiunti i permessi per consultare i dati di tutti
gli host. In fig. 3.4.1.1 è mostrato l’elenco degli utenti con i rispettivi gruppi di appartenenza.
Fig. 3.4.1.1: Elenco utenti di Zabbix Server
Per modificare gli attributi di ogni utente, basta cliccare sul nome presente nella tabella. Si
apre una scheda come mostrato in fig. 3.4.1.2.
32
Fig. 3.4.1.2: Scheda di configurazione utente
Nel tab “User” visualizzato, è possibile decidere username (Alias) e password, gruppo/i di
appartenenza. Nel tab “media”, è possibile definire l’e-mail per la ricezione delle notifiche e
da “Permissions” modificare i permessi.
3.4.2 Media Types
Da questa sezione è possibile configurare i canali di recapito delle notifiche inviate da Zabbix
Server. Nel lavoro svolto, è stato scelto di mandare le notifiche via mail.
Per configurare tale canale, si va sul tab Administration → Media Types e scegliere “Create
Media Type”. Si apre una finestra come mostrato in fig. 3.4.2.1.
33
Fig. 3.4.2.1: Configurazione invio mail sullo Zabbix Server
I campi visualizzati indicano rispettivamente:
1. Name: nome del media type;
2. Type: tipo di media;
3. SMTP server: server per la gestione dei messaggi in uscita, in questo caso è stato
scelto proprio lo Zabbix Server residente sul server LAN (localhost);
4. SMTP helo: dominio del server SMTP, in questo caso sempre localhost;
5. SMTP email: l’indirizzo inserito verrà utilizzato come mittente delle notifiche [10].
3.5
Configurazione degli host da monitorare
Dopo aver rilevato tutti gli host con la procedura della auto-discovery, bisogna impostarne i
parametri e le modalità di monitoraggio.
3.5.1 Host & Host groups
In questo momento, degli host sono presenti solo gli indirizzi IP. Per iniziare a configurarli,
bisogna selezionare il tab Configuration → Host e selezionare l’indirizzo IP dell’host da
configurare. Risulta comodo inoltre raggruppare gli host in “Host groups”, in base alle
34
proprie caratteristiche. Ogni host deve appartenere almeno ad un gruppo, che può essere
scelto tra quelli esistenti oppure creato ex novo.
In fig. 3.5.1.1 è mostrato l’esempio di configurazione di Main Router.
Fig. 3.5.1.1: Configurazione di Main Router
I campi visualizzati indicano rispettivamente:
1. Host name: nome con cui Zabbix Server indicherà l’host;
2. Groups, In groups: gruppi a cui appartiene l’host, da cui è possibile eliminarlo usando
il pulsante “>>”. Other groups: altri gruppi esistenti cui è possibile aggiungere l’host
con il pulsante “<<”. Per le sue caratteristiche Main Router, come tutti gli altri host,
sono stati associati ai tre gruppi indicati in figura;
3. New group: con cui è possibile creare un nuovo gruppo;
4. Agent interfaces: specifica come lo Zabbix Server si collega all’host. In questo caso,
si collega tramite l’indirizzo IP statico assegnato sulla intranet attraverso la agent port
10050.
Successivamente si passa alla scheda “Templates”, per associare l’host ad uno o più dei
template offerti da Zabbix. Un template è un set di funzionalità di monitoring preconfigurate,
ed è immaginato come un modello applicabile a tutti gli host con lo stesso sistema operativo
35
o dello stesso tipo. Per esempio, tutti gli host che montano Ubuntu Server sono stati associati
al Template OS Linux.
Quando un template viene collegato ad un host, tutte le entità (item, trigger, grafici) del
template vengono aggiunti all'host. I template sono assegnati direttamente ad ogni singolo
host (e non ad un gruppo di host). I template sono spesso utilizzati per raggruppare entità
per particolari servizi o applicazioni (come Apache, MySQL) e poi applicate agli host che
eseguono tali servizi.
Un altro vantaggio di usare template si verifica quando qualche entità deve essere cambiata
per tutti gli host. Cambiare qualcosa a livello di template, permette di propagare la modifica
a tutti gli host collegati. Pertanto, l'uso di template è un ottimo modo per ridurre il proprio
carico di lavoro e razionalizzare la configurazione di Zabbix.
In aggiunta ai template esistenti se ne possono aggiungere altri, creandoli o importandoli da
file XML esistente. E’ il caso del Template Squid, importato ed associato all’host Netservices
per monitorarne il servizio di proxy server.
Il risultato della configurazione illustrata è mostrata nella fig. 3.5.1.2.
Fig. 3.5.1.2: Schermata degli host configurati ed i relativi template associati su Zabbix Server
L’ultimo attributo “Availability” con la Z verde, indica che l’host comunica con il Zabbix
Server attraverso l’agent e che è attivo.
36
3.5.2 Items
Un item è un’entità che acquisisce il singolo dato richiesto dall’host. Associando l’host ad un
template, gli vengono automaticamente associati anche i relativi item ed è quindi possibile
acquisire i relativi dati.
Per gli host considerati, esistono numerosi item già configurati nei template associati. E’ stato
però necessario crearne di nuovi, dato che c’era bisogno di metriche non disponibili di default
su Zabbix.
Zabbix offre la possibilità di creare nuovi item interrogabili da agent. Leggendo il file di
configurazione /etc/zabbix/zabbix_agentd.conf, ci si accorge che è possibile creare degli
item personalizzati che interrogati dal server, forniscono il dato desiderato attraverso una
riga di comando mandata appositamente in esecuzione.
La procedura seguita per creare un item personalizzato su un determinato host, è la seguente.
Se il comando da lanciare prevede l’autorizzazione di utente root per essere eseguito, bisogna:
1) Creare un file sorgente <nome_script>.c in linguaggio C del tipo mostrato
nell’esempio riportato:
int main()
{
setuid(0); // pone lo user ID al valore corrispondente all’utente root
system("netstat -tulpn | grep dhcpd | grep 67|wc -l "); /* mostra le
connessioni attive di tipo DHCP sulla porta 67 sull’host locale, e ne
trasmette il numero, solitamente 1 se attiva e 0 se inattiva */
return 0;
}
2)
Compilarlo con il comando:
sudo gcc /etc/zabbix/<nome_script>.c -o /etc/zabbix/<nome_script>
3) Modificarne i permessi:
sudo chmod 4111 /etc/zabbix/<nome_script>
4) Provare che il comando fornisca il risultato per l’item desiderato:
/etc/zabbix/<nome_script>
5) Si inserisce in coda al file /etc/zabbix/zabbix_agentd.conf la seguente riga:
37
UserParameter=<key>,/etc/zabbix/<nome_script>
6) Riavvio dell’agent sull’host interessato.
Se invece non c’è bisogno di alcuna autorizzazione del genere, si seguono solo gli ultimi due
punti scrivendo la riga di comando relativa all’item considerato come mostrato al precedente
punto 5).
Per configurare ora l’item su Zabbix, bisogna andare sul tab Configuration → Hosts,
scegliere “Items” sulla riga dell’host desiderato e cliccare sul pulsante “Create item” in alto a
destra. La scheda di configurazione visualizzata è mostrata in fig. 3.5.2.1.
Fig. 3.5.2.1: Configurazione dell’item che fornisce la quantità di spazio utilizzato in byte
I campi mostrati, indicano rispettivamente:
1. Name: nome dell’item, che in questo caso fornisce la quantità di spazio occupata su
disco;
2. Type: protocollo o modalità di monitoraggio, in questo caso tramite Zabbix Agent;
3. Key: contenuto del campo <key> inserito nello UserParameter mostrato in
precedenza;
4. Host Interface: interfaccia per l’host selezionato, in questo caso indirizzo IP:porta;
5. Type of information/Data Type/Units: tipo, formato ed unità di misura del dato
estratto dall’item;
38
6. Use custom multiplier: se abilitato, moltiplica il valore ricevuto per il moltiplicatore
inserito. In questo caso serve a convertire il dato in ingresso ricevuto in Kb in byte,
in modo poi da consentire al server di assegnargli correttamente i prefissi (K, M, G).
7. Update interval (in sec): intervallo di richiesta del dato, di default 30 sec;
8. Flexible intervals/New flexible interval: possibilità di creare intervalli di tempo in cui
utilizzare una diversa frequenza di richiesta dati;
9. Store value: memorizza il valore nel database in tre modi: “As is” lo lascia intatto,
“Delta – Simple Change” lo calcola come differenza tra “value” e “prev_value”, ed
infine “Delta – Speed per second” in cui lo calcola come (value-prev_value)/(timeprev_time).
10. Show value: può applicare funzioni “mappings” al valore ricevuto, o mostrarlo più
semplicemente “As is”.
Conclusa la configurazione, si aggiunge l’item alla lista degli altri già esistenti, e se è stato
configurato correttamente, si leggerà “Enabled” nella colonna “status” di tale lista.
Gli item creati ex-novo per gli host indicati, sono i seguenti (le righe di configurazione
dell’agent ed i codici sorgente in C delle righe di comando “/etc/zabbix/<nome_script>”,
sono tutti riportati in appendice):
Main Router:
1. Dimensione dei pacchetti rifiutati (DROP) da iptables in input. Unità di misura:
bytes, Store value: Delta – Simple Change. Con questo item si monitora il firewall
posto a protezione della LAN ed il monitoraggio di questo dato serve a segnalare
eventuali attacchi di tipo DOS o DDOS in corso;
2. OpenVPN check. Unità di misura: nessuna, Store value: As is. Restituisce 1 in caso
il servizio di openVPN sia attivo, 0 in caso contrario;
3. Internet ping. Unità di misura: nessuna, Store value: As is. Verifica lo stato della
connettività ad internet attraverso un ping sui Google DNS, restituendo 1 nel caso
sia connesso, 0 in caso contrario;
4. Edge router ping. Unità di misura: nessuna, Store value: As is. Verifica lo stato della
connessione all’edge router attraverso un ping sull’interfaccia Eth1, restituendo 1 nel
caso sia connesso, 0 in caso contrario;
39
5. Ping interno con gli host Netservices, Servers e Trust. Unità di misura: nessuna, Store
value: As is. Verifica lo stato della connessione ad ognuno degli altri host del server
LAN attraverso un ping sull’interfaccia Eth0, restituendo 1 nel caso la connessione
sia attiva, 0 in caso contrario;
Netservices:
1. DHCP server check. Unità di misura: nessuna, Store value: As is. Restituisce 1 in
caso il servizio di DHCP sia attivo, 0 in caso contrario;
2. Monitoraggio DNS server autoritativo: Numero di query in ingresso e in uscita dal
server. Unità di misura: nessuna, Store value: Delta – Simple Change;
3. Monitoraggio DNS server autoritativo: Verifica delle connessioni di tipo TCP e
UDP. Restituisce 1 in caso la connessione TCP/UDP del DNS server sia attiva, 0 in
caso contrario;
4. Monitoraggio DNS server autoritativo: Esito delle query inoltrate al server:
o Success: se il server conosce l’IP del dominio richiesto;
o Recursion: in cui il server risolve totalmente (o dà errore) il dominio richiesto;
o Failure: il server non è riuscito a risolvere l’indirizzo a causa di un suo
problema o errore di configurazione;
o Referral: non conosce l’indirizzo IP del dominio richiesto e rimanda quindi
la query ad un altro DNS server;
o NXDomain: dominio non esistente;
o NXrrset: il dominio esiste, ma il suo record nel database del DNS Server non
esiste.
Unità di misura: query, Store value: Delta – Simple Change. Misura il numero di esiti
riportati.
5. Monitoraggio proxy server (gli item presenti nel template Squid sono tanti, ma per
questo lavoro ne sono stati utilizzati solo due):
o Numero di client connessi (da template Squid);
o Numero medio di richieste http al minuto (da template Squid);
40
o Squid check: restituisce 1 in caso il servizio di proxy Squid sia attivo, 0 in caso
contrario.
Unità di misura: nessuna, Store value: As is.
6. Ping interno con gli host Servers e Trust. Unità di misura: nessuna, Store value: As
is. Verifica lo stato della connessione ad ognuno degli altri host del server LAN
attraverso un ping sull’interfaccia Eth0, restituendo 1 nel caso la connessione sia
attiva, 0 in caso contrario.
Servers:
1. Apache server status. Unità di misura: nessuna, Store value: As is. Restituisce 1 in
caso il servizio di Apache server sia attivo, 0 in caso contrario;
2. MySQL status. Unità di misura: nessuna, Store value: As is. Restituisce 1 in caso il
servizio MySQL sia attivo, 0 in caso contrario;
3. Ping interno con Trust. Unità di misura: nessuna, Store value: As is. Verifica lo stato
della connessione all’host Trust del server LAN attraverso un ping sull’interfaccia
Eth0, restituendo 1 nel caso la connessione sia attiva, 0 in caso contrario.
Zabbix Server:
1. Internet ping. Unità di misura: nessuna, Store value: As is. Verifica lo stato della
connettività ad internet attraverso un ping sui Google DNS, restituendo 1 nel caso
sia connesso, 0 in caso contrario.
DMZ – WWW, Publication, PublicSVN:
1. Apache server status. Unità di misura: nessuna, Store value: As is. Restituisce 1 in
caso il servizio di Apache server sia attivo, 0 in caso contrario;
2. MySQL status (solo su WWW e Publication). Unità di misura: nessuna, Store value:
As is. Restituisce 1 in caso il servizio MySQL sia attivo, 0 in caso contrario;
3. Spazio su disco occupato e libero. Unità di misura: byte, Store value: As is.
Restituiscono i valori indicati e vengono configurati secondo le modalità illustrate in
fig. 3.5.2.1.
L’utilità degli item introdotti sta sia nell’essere alla base delle altre entità di monitoraggio che
saranno a breve introdotte, che per la diagnostica dell’infrastruttura.
41
3.5.3 Triggers
I trigger sono espressioni logiche che valutano i dati raccolti dagli item, indicando l’attuale
stato del sistema.
Mentre gli item vengono utilizzati per raccogliere dati di sistema, ai trigger è lasciato il
compito di valutare se tali dati siano nella norma o meno attraverso una espressione booleana
che permette di definirne l’accettabilità.
Un trigger può trovarsi in due stati:
a) OK: l’espressione booleana risulta non verificata, per cui il dato registrato è da
ritenersi nella norma;
b) PROBLEM: l’espressione booleana del trigger risulta invece positiva, per cui il dato
acquisito non è nella norma stabilita e vengono intraprese le conseguenti azioni
descritte nel §3.3.2.
Lo stato del trigger viene ricalcolato ogni 30 secondi. Quando un trigger si trova in stato di
PROBLEM, viene per prima cosa segnalato nella Dashboard con un livello di attenzione
stabilito in fase di configurazione, come mostrato in fig. 3.5.3.1.
Fig. 3.5.3.1: Esempio di configurazione di un trigger con livello di attenzione “High”
42
Per configurare un nuovo trigger, si va sul tab Configuration → Hosts, si seleziona “Trigger”
dalla riga dell’host corrispondente (in questo caso Main Router) e si clicca sul pulsante
“Create Trigger”. Come mostrato in figura, il nuovo trigger è stato configurato compilando
i campi seguenti:
- Name: nome assegnato. In questo caso si è anche fatto uso della macro
{HOST.NAME}, che riporta il nome dell’host cui appartiene il trigger. Ciò risulta
particolarmente utile per clonarlo (tasto “Clone” in basso) su altri host;
- Expression: espressione booleana costruita utilizzando i valori raccolti dagli item
inseriti. Nel caso considerato, si sono utilizzati gli item derivati da Internet ping su
Main Router, dalle key “internet.ping.last” ed “internet.ping.nodata”. L’espressione
visualizzata significa che, se per 3 minuti (180 s in parentesi) l’item padre
“internet.ping” restituisce 0 o non restituisce alcun dato, il trigger va in stato di
PROBLEM e segnala il problema utilizzando il contenuto del campo “Name”;
- Severity: da qui si può stabilire il grado di attenzione del trigger su una scala di sei
livelli. In questo caso, dato che il trigger segnala l’assenza di connessione ad internet
su Main Router e quindi su tutta la LAN, è stato scelto il livello di attenzione “High”.
Conclusa la configurazione, si aggiunge il trigger alla lista degli altri già esistenti e se gli item
contenuti nell’espressione sono stati configurati correttamente, si leggerà “Enabled” nella
colonna “status” di tale lista.
Così come per gli item, esiste anche una varietà di trigger esistenti e già abilitati in modo da
fornire un monitoring di base già abbastanza dettagliato. In aggiunta a ciò, sono stati creati
dei nuovi trigger al fine di completare il controllo sull’infrastruttura, specialmente per quanto
riguarda la connettività e la disponibilità dei servizi.
I trigger creati e mostrati nel seguente elenco, si basano tutti sugli item creati esposti in
precedenza.
Main Router:
1. Internet connection is down on {HOST.NAME} for 3 minutes: appena mostrato;
2. Edge router connection is down on {HOST.NAME} for 3 minutes: ottenuto
clonando il precedente e sostituendo il relativo item con “edge_router.ping”;
43
3. Netservices/Servers/Trust internal connection is down on {HOST.NAME} for 3
minutes: ottenuto clonando il precedente e sostituendo il relativo item con
“netservices/servers/trust.ping” – severity: Warning;
4. OpenVPN service is down on {HOST.NAME} for 3 minutes: ottenuto dall’item
“OpenVPN Check”, si attiva quando riceve il valore 0 per tre minuti. Severity:
Average.
Netservices:
1. DHCP service is down on {HOST.NAME} for 3 minutes: ottenuto dall’item
“DHCP Check”, si attiva quando riceve il valore 0 per tre minuti – severity: Warning;
2. DNS TCP connection is down on {HOST.NAME} for 3 minutes: ottenuto
clonando il precedente e sostituendo il relativo item con “dns_tcp.check” - severity:
Warning;
3. DNS UDP connection is down on {HOST.NAME} for 3 minutes: ottenuto
clonando il precedente e sostituendo il relativo item con “dns_udp.check” - severity:
Warning;
4. Squid Proxy service is down on {HOST.NAME} for 3 minutes: ottenuto clonando
il precedente e sostituendo il relativo item con “squid.check” - severity: Warning;
5. Servers/Trust internal connection is down on {HOST.NAME} for 3 minutes:
ottenuto clonando il corrispondente di Main Router e sostituendo il relativo item con
“servers/trust.ping” - severity: Warning.
Servers:
1. HTTP service is down on {HOST.NAME} for 3 minutes: ottenuto dall’item
“Apache server Check”, si attiva quando riceve il valore 0 per tre minuti - severity:
Warning;
2. MySQL service is down on {HOST.NAME} for 3 minutes: ottenuto clonando il
precedente e sostituendo il relativo item con “mysql.ping” - severity: Warning;
3. Trust internal connection is down on {HOST.NAME} for 3 minutes: ottenuto
clonando il corrispondente di Main Router e sostituendo il relativo item con
“trust.ping” - severity: Warning.
44
Zabbix Server:
1. Internet connection is down on {HOST.NAME} for 3 minutes: identico a quello
mostrato in figura.
DMZ – WWW, Publication, PublicSVN:
1. HTTP service is down on {HOST.NAME} for 3 minutes: ottenuto dall’item
“Apache server Check”, si attiva quando riceve il valore 0 per tre minuti - severity:
Warning;
2. MySQL service is down on {HOST.NAME} for 3 minutes (solo su WWW e
Publication): ottenuto clonando il precedente e sostituendo il relativo item con
“mysql.ping” - severity: Warning.
3.5.4 Grafici
Il grafico è sicuramente la rappresentazione più potente per valutare in maniera immediata le
performance di sistema. Zabbix offre una vasta gamma di grafici attraverso i template di cui
è dotato, lasciando comunque la possibilità all'utente di creare dei grafici personalizzati.
Nel lavoro effettuato sono stati utilizzati sia i grafici disponibili per monitorare le
performance degli host, che creati di nuovi per il monitoraggio dei servizi erogati.
Per creare un nuovo grafico, bisogna selezionare il tab Configuration → Hosts e selezionare
“Graph” dalla riga dell'host interessato. A questo punto, basta cliccare su pulsante “Create
Graph” in alto a destra per aprire la schermata di configurazione mostrata i fig. 3.5.4.1.
45
Fig. 3.5.4.1: Esempio di configurazione di un nuovo grafico
Gli attributi del nuovo vengono impostati nel modo seguente:
o Name: nome attribuito al grafico, in questo caso “Memory Usage”;
o Width/height: dimensioni in pixel del grafico, 900x200 di default;
o Graph Type: tipo di grafico disponibile, tra cui:
o Normal: ordinario, gli item monitorati sono visualizzati come linee continue
su piano di assi Y (item) vs X (tempo);
o Stacked: come il precedente ma in pila, dove ogni item viene sovrapposto
all’altro ed ognuno si distingue per una diversa colorazione dell’area sottesa;
o Pie: a torta;
o Exploded: a torta “esploso”.
o Show Legend: se selezionato, mostra la legenda;
o Show working time: se selezionato, permette di visualizzare anche il periodo di
inattività dell’host (non-working hours) come porzione dallo sfondo grigio (non
disponibile per i grafici a torta) [10];
o Show triggers: permette di visualizzare eventuali trigger associati agli item visualizzati,
come linee tratteggiate in grassetto (non disponibile per i grafici a torta);
46
o Percentile line (left/right): mostra il percentile per l'asse Y a sinistra/destra. Se, per
esempio, il 95% percentile è impostato, la linea del grafico sarà al livello in cui rientra
il 95 per cento dei valori disponibili sull’asse. Disponibile solo per i grafici “Normal”;
o Y axis min/max value: imposta il valore minimo/massimo dell'asse Y:
o Calculated: tali valori dell'asse Y saranno calcolati automaticamente;
o Fixed: tali valori per l'asse Y sono fissi. Non disponibile per i grafici a torta;
o Item: il valore più recente dell’item selezionato sarà il valore
minimo/massimo.
o Items: dati da visualizzare e relativa grafica. In questo caso sono la quantità di
memoria disponibile e di memoria totale, di cui si può scegliere anche il colore
dell’area sottesa, la posizione dei valori sull’asse (left/right) ed il valore da visualizzare
(min, max, avg, all) nel caso in cui esistano più valori per l’item considerato.
Il grafico relativo a questa configurazione è mostrato in fig. 3.5.4.2.
Fig. 3.5.4.2: Grafico che mostra l’andamento dell’utilizzo della memoria su Main Router
Il grafico in figura, mostra l’andamento dell’utilizzo della RAM assegnata a Main Router
nell’ultima ora. Questo tipo di grafico è strutturato in maniera particolare rispetto agli altri
grafici, dato che ha un valore massimo fisso sull’asse X rappresentato dalla memoria totale
che sottende un’area di colore rosso. A quest’area, ne viene sovrapposta una verde che
rappresenta lo spazio disponibile.
E’ quindi chiaro che tale grafico è strutturato in modo da mostrare una prevalenza di colore
verde se la memoria disponibile è sufficiente, o una prevalenza di colore rosso se la memoria
disponibile comincia a scarseggiare. Questo tipo di grafico risulta visivamente molto efficace,
47
per cui è stato inserito nel template OS Linux in modo da essere replicato su tutti gli altri
host.
I tipi di grafico utilizzati, mostrati nelle rispettive figure, per il monitoraggio di host e servizi
sono i seguenti:
o Memory Usage: appena descritto, utilizzato su tutti i 7 host e lo Zabbix Server;
o Cpu Utilization: fornito da template OS linux, è di tipo “Stacked” ed utilizzato su
tutti i 7 host e lo Zabbix Server;
Fig. 3.5.4.3: Grafico dell’andamento utilizzo CPU su host DMZ – WWW. E’ mostrato un picco di
percentuale di attesa I/O intorno alle 13:18.
o Disk Usage: è stato creato utilizzando due item già presenti nel template OS Linux:
Free Disk e Used Disk. E’ di tipo “Exploded” ed è stato utilizzato su tutti i 7 host e
lo Zabbix Server;
Fig. 3.5.4.4: Grafico di utilizzo disco su host DMZ – WWW. La rilevante occupazione del disco deriva
dal motivo che vi risiedono tutte i dati relativi al sito web di Telematics Lab.
48
o Network traffic on Eth1: fornito da template OS linux, è di tipo “Stacked” ed è
utilizzato su Main Router per monitorare il traffico esterno totale in ingresso e in
uscita dalla LAN;
Fig. 3.5.4.5: Grafico del traffico sull’interfaccia di rete Eth1 esterna alla LAN
o Grafici di monitoraggio servizi: sono stati creati quattro nuovi grafici per monitorare:
o Dimensione dei pacchetti scartati dal firewall su Main Router in ingresso;
o Statistiche sull’esito delle query inoltrate al server LAN;
o Numero di query in ingresso e in uscita dal server LAN;
o Statistiche su Squid proxy server, mostrate in fig. 3.5.4.6.
Fig. 3.5.4.6: Grafico riportante a) Numero di client connessi al proxy server (scala a destra); b) numero
medio di richieste HTTP al minuto (scala a sinistra).
I grafici di monitoraggio servizi, proprio come quello di esempio riportato nella precedente
figura, sono di tipo “Normal” e contengono gli item creati in precedenza per i servizi.
49
3.6
Risultati ottenuti
Una volta configurato quanto appena visto, è finalmente possibile visualizzare quanto
configurato finora. In questo paragrafo conclusivo, si vedrà con quali rappresentazioni visive
i dati acquisiti possono essere visualizzati.
3.6.1 Schermate
In una schermata, è possibile aggregare più grafici o altri elementi in modo da fornire una
rapida panoramica dello stato del sistema.
Una schermata è organizzata come una tabella, in cui si può scegliere il numero di righe e
colonne e l’elemento da inserire in ogni singola cella. In questo lavoro, tra i tanti tipi di
elementi disponibili, sono stati visualizzati:
o Grafici (sia creati che già esistenti);
o Plain text (informazione visualizzata in forma testuale);
o Mappe (spiegate nel sottoparagrafo successivo).
Per creare una schermata, si va sul tab Configuration → Screens → Create Screen e si
imposta il nome ed il numero di righe e colonne.
In seguito si inserisce in ogni cella l’elemento desiderato cliccando sul link “Change”. In fig.
3.6.1.1, è mostrato l’esempio dell’inserimento di un grafico in una cella.
Fig. 3.6.1.1: Inserimento di un grafico nella cella di una schermata
50
I campi visualizzati vengono così impostati:
o Resource: tipo di rappresentazione dei dati, in questo caso “Graph”;
o Graph name: dà la possibilità di selezionare tra i grafici esistenti, attraverso la finestra
presente sulla destra di fig. 3.6.1.1, in questo caso si tratta del grafico che traccia
l’andamento di utilizzo della memoria sull’host Netservices;
o Width/Height: dimensione in pixel del grafico nella cella;
o Column span / Row span: estende la cella per il numero selezionato di
colonne/righe, in tutti i casi sono stati lasciati i valori di default (1;1).
In fig. 3.6.1.2, è mostrato l’inserimento di un testo semplice (Plain Text) in una cella.
Fig. 3.6.1.2: Inserimento di un testo nella cella di una schermata
In questa modalità, è possibile visualizzare i dati più recenti raccolti da un item in forma
testuale, collocandoli in una tabella di due colonne: timestamp (data ed ora di acquisizione
del dato) ed item selezionato. Ci sono alcuni campi diversi rispetto al caso precedente:
o Show lines: indica la quantità di dati più recenti da visualizzare, ovvero quante righe
deve avere la tabella visualizzata in cella;
o Dynamic item: consente di visualizzare lo stesso item per diversi host.
Una volta impostate tutte le schermate, è possibile visualizzarle dal tab Monitoring →
Screens, in modo da apprezzarne l’impatto visivo e cominciare a monitorare l’infrastruttura.
Come si vedrà dalle prossime figure, è possibile selezionare la schermata da visualizzare dal
51
menu a tendina “Screens” e scegliere l’intervallo temporale da indagare attraverso lo
strumento “Zoom”, posto in alto alla schermata.
Le schermate disponibili sono le seguenti:
o Schermata di sistema per l’host: configurata per tutti i sette host e Zabbix Server,
raccoglie i grafici: “Memory usage”, “CPU utilization” e “Disk Usage” riguardanti le
performance di sistema. In fig. 3.6.1.3 ne è riportato un esempio;
Fig. 3.6.1.3: Schermata “Zabbix Server”, che riporta oltre alle principali performance di sistema, anche le
operazioni attuate sul server MySQL di Zabbix. Da notare in alto a destra, la scarsità di RAM disponibile.
o Schermata “Service Graph”: raggruppa tutti i grafici che monitorano le performance
dei servizi erogati dal server LAN. E’ riportata in fig. 3.6.1.4;
52
Fig. 3.6.1.4: Schermata “Service Graph”
o Schermate “Host status” e “Services Status”: raccolgono in maniera testuale i dati
riguardanti lo stato rispettivamente di tutti gli host e dei servizi monitorati. Lo stato
di disponibilità (Up) è rappresentato dal valore 1, mentre la non disponibilità (Down)
dal valore 0 o dall’assenza di valori ricevuti (No data found).
Fig. 3.6.1.5: Schermata “Host status”
53
Fig. 3.6.1.6: Schermata “Services status”
3.6.2 Mappe
La visualizzazione mediante schermate fornisce sì una rappresentazione analitica dello stato
del sistema, ma non abbastanza immediata. Per incrementare l’efficacia e l’immediatezza
visiva dell’impianto di monitoraggio, Zabbix offre la possibilità di costruire mappe della rete
monitorata che consentono di avere una panoramica sia della sua struttura che soprattutto
dello stato dei suoi componenti.
Per configurare una mappa, si impostano inizialmente i parametri generali (nome,
dimensioni, mostra stato e problemi dei trigger) da Configuration → Maps → Create Map.
Creata la mappa, si passa a popolarla con gli elementi desiderati (host, router, ecc.)
rappresentati da icone, e collegandoli con i “Link”. In fig. 3.6.2.1, è riportato un esempio di
configurazione mappa.
54
Fig. 3.6.2.1: Configurazione della mappa dell’intera infrastruttura (Whole network)
Nella mappa riportata in figura sono state aggiunte, utilizzando il pulsante “Icon +”, le tre
icone di tipo “server” rappresentanti i server LAN, DMZ ed il bastion host “Main Router”,
l’icona del router che rappresenta Edge Router e la nuvola che indica Internet. Se c’è un
problema su qualche host, verrà visualizzato il nome del relativo trigger sotto la relativa icona.
Una volta posizionate le icone, si aggiungono i link selezionando a coppie le icone interessate,
e poi cliccando su “Link +”. Si apre una finestra come mostrato in fig. 3.6.2.2.
55
Fig. 3.6.2.2: Configurazione del link tra Edge Router ed Internet
Si configura il link impostando:
o Label: etichetta del link, in questo caso l’indirizzo IP pubblico con cui Internet vede
l’intera infrastruttura;
o Connect to: icona a cui collegare l’elemento selezionato, in figura “Cloud” (Internet);
o Type / Colour (OK): stile di default della linea che rappresenta il link, in questo caso
verde ed in grassetto;
o Link indicators: lista di trigger collegata al link. Se il trigger va in stato di PROBLEM,
la linea del link cambia stile. Nell’esempio considerato, se la connessione ad Internet
risulta disattivata per 3 minuti, la linea passa da continua verde a tratteggiata rossa.
In fig. 3.6.2.3 sono riportate due mappe dell’intera rete, riguardanti due differenti situazioni.
56
Fig. 3.6.2.3 a): Mappa dell’intera rete con tutti i trigger in stato di OK
Fig. 3.6.2.3 b): Mappa dell’intera rete con problemi di connettività ad Internet su Main Router
La fig. 3.6.2.3 b), è stata ottenuta simulando un guasto sull’interfaccia di rete Eth1 di Main
Router. Dopo tre minuti, la mappa in questione passa dalla situazione in figura a) a quella in
figura b). Si attivano tre trigger su Main Router (3 Problems, in figura), ed il suo sfondo
diventa rosso, colore indice del trigger di maggior livello di attenzione.
Inoltre, dato che i trigger rivelatori sono così configurati sui link:
57
o Local Network – Main router: linea continua verde di default e diviene tratteggiata
rossa se si attiva uno dei seguenti trigger:
o Netservices/Servers/Trust internal connection is down on {HOST.NAME}
for 3 minutes (in stato di OK),
o Zabbix agent on {HOST.NAME} is unreachable for 3 minutes (in stato di
OK);
o Main Router – Edge Router: linea continua in grassetto verde di default e diviene
tratteggiata rossa se si attiva il trigger “Edge router connection is down on
{HOST.NAME} for 3 minutes” (in stato di PROBLEM);
o Edge Router – Internet: linea continua in grassetto verde di default e diviene
tratteggiata rossa se si attiva il trigger “Internet connection is down on
{HOST.NAME} for 3 minutes” (in stato di PROBLEM);
questi ultimi due link appariranno come linee tratteggiate rosse.
L’icona di nome “Local Network” presente sulla mappa generale, corrisponde a sua volta ad
un’altra mappa di nome “Local Network on Big Bang”, che è una rappresentazione dello
stato del server LAN.
In fig. 3.6.2.4, si riporta un’immagine di tale mappa durante la simulazione del guasto.
58
Fig. 3.6.2.4: Mappa del server LAN durante la simulazione di guasto sull’interfaccia Eth1 di Main
Router. Le linee tratteggiate rosse indicano i collegamenti non funzionanti, le linee continue quelli che
funzionano.
I link visibili in figura, sono stati così impostati:
o Link Zabbix Server – host: dall’etichetta “Zabbix Agent; Eth0”, sono linee continue
verdi di default e divengono tratteggiate rosse quando si attiva uno dei seguenti
trigger:
o Zabbix agent on {HOST.NAME} is unreachable for 3 minutes: in stato di
OK su tutti gli Host;
o “Service” on {HOST.NAME} is down for 3 minutes: permette di tenere
d’occhio anche la disponibilità dei servizi, che in questo caso sono tutti attivi
tranne openVPN su Main Router che si trova in stato di down;
59
o Link Host – host: dall’etichetta “Eth0”, sono linee continue blu di default e
divengono tratteggiate rosse quando la relativa connessione interna sull’interfaccia di
rete virtuale Eth0 è disattivata (tutto OK);
o Link Main Router – Internet: dall’etichetta “Eth1 – 172.17.200.2”, è una linea
continua blu di default e diventa tratteggiata rossa quando si attiva il trigger “Internet
connection on {HOST.NAME} is down for 3 minutes” (in stato di PROBLEM);
o Link Zabbix Server – Internet: dall’etichetta “Eth1 – 172.17.200.253”, è una linea
continua blu di default e diventa tratteggiata rossa quando si attiva il trigger “Internet
connection on {HOST.NAME} is down for 3 minutes” (in stato di OK).
L’icona di nome “DMZ” presente sulla mappa generale corrisponde a sua volta alla mappa
di nome “DMZ Hosts Chart”, che fornisce una rappresentazione dello stato del server DMZ.
Fig. 3.6.2.5: Mappa del server DMZ
I link visibili in figura, sono tutti del tipo host – Zabbix Server, sono rappresentati da linee
continue verdi di default e tratteggiate rosse quando si attiva uno dei seguenti trigger:
60
o Zabbix agent on {HOST.NAME} is unreachable for 3 minutes: in stato di OK;
o “Service” on {HOST.NAME} is down for 3 minutes: i servizi sono tutti attivi.
Risulta quindi evidente che la combinazione della segnalazione dei problemi che possono
affliggere la rete, sia sulle singole icone che sui relativi link, fornisce quel fattore di
immediatezza visiva che rende la mappa preferibile ai tipi di schermata visti in precedenza,
almeno per quanto riguarda la valutazione qualitativa dello stato del sistema.
3.6.3 Provvedimenti attuati
E’ chiaro che gli strumenti visti sinora recano in sé funzionalità di diagnostica e di valutazione
delle prestazioni di sistema sia in maniera qualitativa che quantitativa. Ciò rende possibile
accorgersi di potenziali problemi anche quando i trigger sono in stato di OK.
E’ il caso dell’utilizzo di memoria centrale in Zabbix Server, che risultava troppo elevato e
rischiava di pregiudicarne le prestazioni. Per questo motivo è stato deciso di aumentarne la
RAM prelevandola dall’host che ne faceva minor utilizzo. Guardando i grafici di utilizzo
memoria di tutti gli host, si è notato che Trust aveva il minor utilizzo in assoluto (meno del
22%), per cui si è deciso di abbassarne la RAM assegnata di 256 MB per poter incrementare
quella di Zabbix Server della stessa misura.
Nelle figure 3.6.3.1/2 sono mostrati gli effetti di tali modifiche.
Fig. 3.6.3.1: Grafici relativi alla situazione precedente (sinistra) e conseguente (destra) all’aumento di RAM
su Zabbix Server da 560 a 816 MB.
61
Fig. 3.6.3.2: Grafici relativi alla situazione precedente (sinistra) e conseguente (destra) al calo di RAM su
Trust da 512 a 256 MB.
L’effetto di tale variazione è pressochè nullo su Trust, mentre si rileva benefico per la RAM
di Zabbix Server.
62
Conclusioni e sviluppi futuri
L’utilizzo del software Zabbix sull’infrastruttura IT assegnata si è rivelato molto valido, sia a
causa della sua flessibilità che intuitività.
In particolare, una caratteristica molto interessante di Zabbix è la possibilità di creare una
mappa della rete che si sta monitorando. Risulta molto semplice creare la mappa della rete e
associare ad ogni icona aggiunta, un host monitorato. La mappa effettua anche una piccola
descrizione di eventuali problemi degli host. Questo aspetto è molto vantaggioso perchè
permette di ottenere una panoramica della rete e permette la comprensione, anche solo
sommaria, della sua struttura e dei vari problemi che l'affliggono anche a persone che non
hanno mai lavorato con tale software.
Attualmente ICANN ha implementato una infrastruttura di Zabbix distribuita sui cinque
continenti per monitorare i servizi DNS che gestiscono i gTLD (global Top Level Domain)
di Internet [12] e Freenet ha automatizzato il processo di monitoraggio di un ambiente Java
J2EE.
Al termine della Zabbix Conference 2014 svoltasi a Riga il 12 e 13 settembre, Alexei
Vladishev fondatore di Zabbix, ha salutato la platea con un elenco di "5 cose da migliorare
in Zabbix" [13] su cui si concentreranno presumibilmente i prossimi sforzi del team di
sviluppo:

Una nuova interfaccia utente;

API più veloci e stabili;

Scalabilità e High Availability;

Autenticazione e cifratura del traffico tra agent e server;

Reportistica avanzata.
Ciò significa che Zabbix è un grande progetto ancora in espansione.
63
Bibliografia
[1] Goldberg R. P., Popek G. J.: "Formal Requirements for Virtualizable third generation
architectures". Communications of the ACM 17(7), 1974.
[2] Sbirrazzuoli R.: “Virtualizzazione, concetti teorici. Sviluppo di un sistema di management di ambienti
di esecuzione virtualizzati per sistemi batch”. 2008.
[3] Menon A., Santos J. R., Turner Y., Janakiraman G., Zwaenepoel W. Performance
overheads in Xen: “Diagnosing Performance Overheads in the Xen Virtual Machine Environment”,
2005.
[4] Villano U., Mancini E., Tretola R., Rak M.: "A framework for Virtual Cluster Performance
Evaluation" 2009.
[5]
Wikipedia:
“Timeline
of
Virtualization
Development”.
[Online]
http://en.wikipedia.org/wiki/Virtualization_Development.
[6] Barham P., Dragovic B., Fraser K., Hand S., Harris T.: "Xen and the Art of Virtualization",
in Proceedings of the nineteenth ACM symposium on Operating systems principles, October
2003.
[7] Xen: Xen. [Online] http://www.xen.org.
[8] Grossato D.: “Vantaggi della virtualizzazione. La Virtualizzazione”. 2010. [Online]
http://www.slideshare.net/dgrossato.101/la-virtualizzazione-2010.
[9] Pifferi A., Nantista G., Ianniello L., Lora A., Simonetti M.: “Analisi e Implementazione di
Sistemi per il Monitoraggio della Rete Wireless Relativa al Progetto ADD (Anti Digital Divide) e delle
Infrastrutture di Campus AdR RM1”, Smart eLab – volume 2, 2013.
[10]
Zabbix
Documentation
2.4:
“Zabbix
Manual”,
[Online]
https://www.zabbix.com/documentation/2.4/manual.
[11] Bauer M. D.: “Server Linux sicuri”. Tecniche Nuove editore, 2003.
[12] Uribe I.: “Monitoring the Internet: when 6 millions of triggers is not enough”, Zabbix Conference.
September 12, 2014 – Riga, Latvia.
[13] Vladishev A.: “5 Things to Improve in Zabbix”, Zabbix Conference. September 13, 2014 –
Riga, Latvia.
64
Appendice
In questa sezione sono raccolte le righe di comando che permettono agli item creati di
raccogliere dati, ed il relativo codice sorgente in C nel caso siano necessarie le autorizzazioni
di utente root per eseguirle.
Main Router:
1. Dimensione dei pacchetti rifiutati (DROP) da iptables in input.
Riga di configurazione nell’agent:
UserParameter=iptables.block,/etc/zabbix/iptables_drop
Codice sorgente del comando:
int main()
{
setuid(0);
system("/sbin/iptables -L -n -v -x | grep 'Chain INPUT' | awk {'print $7'}");
return 0;
}
2. OpenVPN check.
Riga di configurazione nell’agent:
UserParameter=ovpn.check,/etc/zabbix/ovpn_check
Codice sorgente del comando:
int main()
{
setuid(0);
system("netstat -tulpn | grep 1194 | wc -l");
return 0;
}
3. Internet ping.
Riga di configurazione nell’agent:
UserParameter=internet.ping, ping 8.8.8.8 -c 1 | grep received| awk
{'print $4'}
4. Edge router ping.
65
Riga di configurazione nell’agent:
UserParameter=edge_r.ping,ping 172.17.200.1 -c 1 | grep received| awk
{'print $4'}
5. Ping interno con gli host Netservices, Servers e Trust.
Righe di configurazione nell’agent:
UserParameter=netservices.ping, ping netservices -c 1 | grep received|
awk {'print $4'}
UserParameter=servers.ping, ping servers -c 1 | grep received| awk
{'print $4'}
UserParameter=trust.ping, ping trust -c 1 | grep received| awk {'print
$4'}
Netservices:
1. DHCP server check.
Riga di configurazione nell’agent:
UserParameter=dhcp.check,/etc/zabbix/dhcp_check
Codice sorgente del comando:
int main()
{
setuid(0);
system("netstat -tulpn | grep dhcpd | grep 67|wc -l ");
return 0;
}
2. Monitoraggio DNS server autoritativo: Numero di query in ingresso e in uscita dal
server.
Righe di configurazione nell’agent:
UserParameter=bind.queries.in[*],curl http://localhost:8053/
2>/dev/null | xml2 | grep -A1 "/isc/bind/statistics/server/queriesin/rdtype/name=$1$" | tail -1 | cut -d= -f2
UserParameter=bind.queries.out[*],curl http://localhost:8053/
2>/dev/null | xml2 | grep -A1
"/isc/bind/statistics/views/view/rdtype/name=$1$" | tail -1 | cut -d=
-f2
3. Monitoraggio DNS server autoritativo: Verifica delle connessioni di tipo TCP e
UDP.
Riga di configurazione nell’agent:
UserParameter=bind.tcp.check,/etc/zabbix/dns_tcp_check
66
Codice sorgente del comando:
int main()
{
setuid(0);
system("netstat -tulpn | grep named | grep 254:53| grep tcp | wc -l");
return 0;
}
Riga di configurazione nell’agent:
UserParameter=bind.udp.check,/etc/zabbix/dns_udp_check
Codice sorgente del comando:
int main()
{
setuid(0);
system("netstat -tulpn | grep named | grep 254:53| grep udp | wc -l");
return 0;
}
4. Monitoraggio DNS server autoritativo: Esito delle query inoltrate al server:
o Success;
Riga di configurazione nell’agent:
UserParameter=named.success,/etc/zabbix/zabbix-binds
Codice sorgente del comando:
int main()
{
setuid(0);
system("rm -f /var/cache/bind/named.stats");
setuid(0);
system("rndc stats");
setuid(0);
system("grep "successful" /var/cache/bind/named.stats| awk {'print
$1'}");
return 0;
}
o Recursion;
Riga di configurazione nell’agent:
67
UserParameter=named.recursion,grep "recursion"
/var/cache/bind/named.stats | awk {'print $1'}
o Failure;
Riga di configurazione nell’agent:
UserParameter=named.failure,grep "queries resulted in SERVFAIL"
/var/cache/bind/named.stats | awk {'print $1'}
o Referral;
Riga di configurazione nell’agent:
UserParameter=named.referral,grep "non authoritative"
/var/cache/bind/named.stats| awk {'print $1'}
o NXDomain;
Riga di configurazione nell’agent:
UserParameter=named.nxdomain,grep "queries resulted in NXDOMAIN"
/var/cache/bind/named.stats | awk {'print $1'}
o NXrrset.
Riga di configurazione nell’agent:
UserParameter=named.nxrrset,grep "nxrrset"
/var/cache/bind/named.stats | awk {'print $1'}
5. Monitoraggio proxy server:
o Numero di client connessi (da template Squid);
Riga di configurazione dell’agent:
UserParameter=squid.clients,squidclient mgr:info|grep 'Number of
clients accessing cache:'|cut -d':' -f2| tr -d ' \t'
o Numero medio di richieste http al minuto (da template Squid);
Riga di configurazione dell’agent:
UserParameter=squid.avg_http_req_per_min,squidclient
mgr:info|grep 'Average HTTP requests per minute since
start:'|cut -d':' -f2| tr -d ' \t'
o Squid check: restituisce 1 in caso il servizio di proxy Squid sia attivo, 0 in caso
contrario.
Riga di configurazione dell’agent:
UserParameter=squid.check,/etc/zabbix/squid_check
68
Codice sorgente del comando:
int main()
{
setuid(0);
system("netstat -tulpn | grep squid | grep 3128 | wc -l");
return 0;
}
6. Ping interno con gli host Servers e Trust.
Righe di configurazione nell’agent:
UserParameter=servers.ping, ping servers -c 1 | grep received| awk
{'print $4'}
UserParameter=trust.ping, ping trust -c 1 | grep received| awk {'print
$4'}
Servers:
1. Apache server status;
Riga di configurazione dell’agent:
UserParameter=apache.status[*],wget -q -O /dev/null
“http://localhost/server-status?auto” && wget -q -O –
“http://localhost/server-status?auto” | awk ‘/$1: / {print $NF}’
2. MySQL status;
Riga di configurazione dell’agent:
UserParameter=mysql.ping,mysqladmin -uroot –p<password> ping|grep
alive|wc -l
3. Ping interno con Trust.
Riga di configurazione nell’agent:
UserParameter=trust.ping, ping trust -c 1 | grep received| awk {'print
$4'}
Zabbix Server:
1. Internet ping.
Riga di configurazione nell’agent:
UserParameter=internet.ping, ping 8.8.8.8 -c 1 | grep received| awk
{'print $4'}
DMZ – WWW, Publication, PublicSVN:
69
1. Apache server status. Analogo al precedente;
2. MySQL status (solo su WWW e Publication);
Riga di configurazione nell’agent:
UserParameter=check.mysql,/etc/zabbix/check_mysql
Codice sorgente del comando:
int main()
{
setuid(0);
system("netstat -tulpn | grep mysqld | wc -l");
return 0;
}
3. Spazio su disco occupato e libero.
Righe di configurazione nell’agent:
UserParameter=disk.used,df | grep /dev/sda5 | awk {'print $3'}
UserParameter=disk.ava,df | grep /dev/sda5 | awk {'print $4'}
70