Il monitoraggio di un DataCenter - SCoPE

Transcript

Università degli Studi di Napoli Federico II
Facoltà di Scienze Matematiche Fisiche e Naturali
Corso di Laurea in Informatica
Tesi Sperimentale di Laurea Triennale
Il monitoraggio di un DataCenter: Implementazione
di funzioni per le risorse locali di nodi remoti
Relatori
Candidato
Prof. G. Russo
Dr. D. Del Prete
Esposito Paolo
Matr. 566/2008
Anno accademico 2009/2010
I
Indice generale
Introduzione................................................................................................................................1
1.Enterprise Information Portal: Liferay.....................................................................................3
1.1.Caratteristiche...................................................................................................................6
1.2.Organizzazione Delle Portlet............................................................................................8
1.3.Permessi E Sicurezza......................................................................................................10
2.Panoramica sull'applicazione NAGIOS.................................................................................12
2.1.Caratteristiche E Requisiti..............................................................................................13
2.2.Installazione Automatica................................................................................................14
2.3.Installazione Manuale.....................................................................................................16
2.4.Configurazione Di NAGIOS..........................................................................................18
2.5.Configurazione Di Apache.............................................................................................24
2.6.Interfaccia Web...............................................................................................................27
3.L'addon NRPE........................................................................................................................30
3.1.Nagios Remote Plugin Executor....................................................................................30
3.2.Tipologia Dei Nodi Della Rete.......................................................................................33
3.3.Installazione E Configurazione Del NRPE....................................................................36
3.4.Risoluzione Dei Problemi..............................................................................................42
4.Configurazione dei plugin......................................................................................................45
4.1.Contenuto Del File Nrpe.cfg..........................................................................................47
4.2.Descrizione Dei Plugin...................................................................................................51
4.3.Script Utilizzati Per Gli Host..........................................................................................58
4.4.Il Protocollo SNMP........................................................................................................66
4.5.Script Per UPS, Switch E CMC.....................................................................................71
4.6.Considerazioni ...............................................................................................................73
4.7.Scheduler E Resource Manager.....................................................................................74
4.8.Problematiche.................................................................................................................77
5.Aggiunta dei servizi con Centreon.........................................................................................80
5.1.Host E Host Group.........................................................................................................83
5.2.Aggiungere Un Comando...............................................................................................87
5.3.Creare Un Servizio.........................................................................................................89
5.4.Centreon Come Tool Di Monitoraggio...........................................................................96
6. Creazione delle mappe con Nagvis.......................................................................................99
6.1.Inserire Una Mappa......................................................................................................106
6.2.Editor Di Mappe...........................................................................................................108
6.3.Url E Web Management...............................................................................................112
7.Conclusioni...........................................................................................................................117
8.Appendice.............................................................................................................................119
8.1.File Di Configurazione Delle Mappe...........................................................................119
8.2.Mappe...........................................................................................................................147
Bibliografia.............................................................................................................................158
Introduzione
Con l'aumento della complessità delle reti e l'accrescere del numero di macchine e
apparati collegati, diventa sempre più complicato monitorare il corretto funzionamento
degli stessi.
Quello di cui ha bisogno un amministratore di sistema per svolgere, in maniera
ottimale, il proprio lavoro è il controllo di tutte le risorse che deve gestire.
Dato il gran numero di macchine presenti sulla rete, controllare ogni singolo apparato
collegandosi volta per volta ed eseguendo determinati script, è un metodo lento e poco
funzionale.
Spesso, poi, si tratta di macchine adibite a compiti diversi che necessitano il
monitoraggio di parametri e funzionalità differenti.
Non si può prescindere quindi da un sistema di monitoraggio centralizzato che sia in
grado di controllare, in modo rapido ed efficiente, lo stato della rete e rilevare
eventuali problematiche.
Un sistema di monitoraggio ha il compito di controllare continuamente, ed ad
intervalli prestabiliti, le risorse degli host ed apparati attivi che compongono la rete.
Questo
tramite
una
interfaccia
messa
a
disposizione
dell'amministratore.
L'amministratore di rete, in questo modo, può individuare tempestivamente un
problema e provvedere alla sua risoluzione.
Questo lavoro di tesi è svolto sulla rete di calcolo del Tier2-Napoli, sulla quale è già
presente un sistema di monitoraggio funzionante basato sul software open source
NAGIOS.
La funzione principale di NAGIOS è quella di controllare nodi, reti e servizi
specificati, avvertendo quando questi non garantiscono il loro servizio, quando
vengono spenti e quando ritornano attivi.
NAGIOS è stato installato tramite il FAN (Fully Automated NAGIOS), che include
Esposito Paolo 566/2008
Pagina 1 di 148
diversi tool per la configurazione tra i quali, sono stati utilizzati, Centreon e Nagvis.
È stato inserito all'interno di una portlet del portale web di Tier2. Il portale è Liferay,
un EIP (Enterprise Informazion Portal) opern source basato sul linguaggio java.
L'obiettivo di questo lavoro di tesi è organizzare logicamente tutti gli host ed apparati
della rete di calcolo di Tier 2 ATLAS, classificandoli per tipologia, e definire per
ognuno di questi i servizi da monitorare visualizzandoli graficamente tramite una
mappa navigabile.
Il mio lavoro di tesi si è sviluppato nelle seguenti fasi:
•
Installazione e configurazione dell'addon NRPE su 80 macchine. L'addon
NRPE è progettato per permettere l'esecuzione di NAGIOS su macchine remote
linux. Il principale motivo è quello di permettere a NAGIOS di monitorare
risorse locali come, per esempio, il caricamento della CPU o l'utilizzo di
memoria.
•
Inserimento degli host e configurazione di 19 servizi nel tool Centreon.
Centreon è usato come interfaccia grafica di NAGIOS e permette di inserire
host, classificarli in host group e definire dei servizi su essi. Si possono testare i
servizi su determinati host ed, una volta completata la configurazione, esportare
il file di configurazione per NAGIOS.
•
Inserimento ed editing delle 12 mappe delle infrastrutture di rete con l'addon
Nagvis. Nagvis è usato per visualizzare i dati di NAGIOS. Permette di caricare
mappe in formato png e inserire su queste oggetti come le icone per gli host che
visualizzeranno informazioni riguardanti gli host e lo stato dei servizi attivi.
•
Organizzare le mappe in modo da favorire la navigabilità e individuare
agevolmente le anomalie.
È possibile in questo modo partire da una
panoramica generale della rete, visualizzare gli apparati classificati per
tipologia, ed entrare nel dettaglio visualizzando i servizi di un singolo host ed
accedere alla sua web management.
Pagina 2 di 148
Queste fasi hanno portato alla realizzazione di un sistema di monitoraggio
centralizzato, all'interno di un portale Liferay, in grado di monitorare le risorse locali
di host remoti. Il sistema è utilizzabile tramite una interfaccia grafica accessibile da un
qualunque Web Browser e il suo funzionamento è stato testato per tutta la durata del
tirocinio risolvendo, di volta in volta, le problematiche che si sono presentate.
1. Enterprise Information Portal: Liferay
Liferay è un Enterprise Portal Server Open Source basato sul linguaggio java che
utilizza le ultime tecnologie del Web 2.0.
I portal server nascono in un ambiente aziendale, per venire incontro alla necessità di
aggregare i servizi offerti da Legacy System aziendali.
Il portale svolge la funzione di Web Container. Una pagina può essere considerata una
aggregazione di moduli web, chiamati portlet, destinati a contenere applicazioni.
La scelta è ricaduta su Liferay in quanto offre una grande quantità di servizi integrati
di qualità ed un'ottima flessibilità. Tutto questo si va ad aggiungere ad una grande
capacità di organizzare e supportare la collaborazione.
Liferay infatti è un portale open source che offre un sistema potente ed integrato di
funzioni di collaborazione tra le quali:
•
Wiki: Ogni gruppo può condividere una propria Wiki con propri e differenziati
insiemi di autorizzazioni. Ogni utente con i diritti necessari può contribuire alla
crescita del repository di conoscenza condiviso. I contenuti vengono inseriti
semplicemente con un editor WISWYG, le pagine possono essere raggruppate
in gerarchie con tag di sistemi a vocabolario multipo (taxonomy e/o
folksonomy).
•
Bacheca elettronica: Un sistema di message boeard che permette di condividere
idee e annunci all'interno di una organizzazione o una community. Mette a
disposizione report sull'attività svolta nella bacheca, riportando i post recenti e
Pagina 3 di 148
gli utenti attivi. Ogni thread è visibile via feed RSS, ogni post può inviare una
mail di avviso che permetti di rispondere al post del client di posta. Come per
tutte le altre portlet, anche quella della bacheca è sottoposta al sistema di
gestione degli accessi e autorizzazioni che garantisce i controllo utilizzando i
ruoli.
•
RSS: Permette di condividere tutte le tipologie di contenuto tramite feeding
RSS
•
Blog: Un sistema ricco di funzionalità reso più efficace dalla natura “sociale”
del portale nel suo complesso. Tra le funzionalità più importanti l'editor
WYSWYG, social bookmarking, notifiche email per i contributi e i commenti,
sistemi di rating dei contributi, subscription via RSS, scheduling delle
pubblicazioni
•
Tracking delle attività: tiene traccia delle attività più recenti effettuate sul
portale.
•
Instant messaging: Comprende delle funzioni di instant messaging. Tramite la
lista degli amici vengono automaticamente visualizzati i nomi degli amici
collegati. L'accesso al servizio è inserito in una barra in fondo alla videata e
segue l'utente lungo la navigazione all'interno del portale rimandendo sempre
disponibile.
•
Calendari: È possibile impostare e utilizzare calendari di gruppo basati sulle
community. Gli eventi possono essere condivisi e gli alert possono essere settati
per un avviso via email o instant messaging.
•
Avvisi: È possibile inviare messaggi di tipo broadcast a gruppi di utenti, ogni
utente può impostare le modalità di ricezione degli avvisi.
•
Sondaggi: Sono disponibili delle portlet per l'impostazione, la presentazione e
la raccolta dati di sondaggi. Possono essere configurati e pubblicati più
sondaggi in contemporanea con visibilità differenziate rispetto ai gruppi.
Pagina 4 di 148
figura 1 : Schermata di prova con alcune portlet
Liferay è conforme alle specifiche SOA (Service Oriented Architecture) per una
robusta integrazione applicativa. Integra OpenSSO (Single Sign On) e può cooperare
con standard quali Shibbolet, Liberty Alliance, Open ID, CAS.
Qualunque applicazione sviluppata su Liferay beneficia di tutte le possibilità tipiche di
un Portal Server Enterprise: Multi-Tier, Limitess Clustering, High Avaibility, Page
Caching, ect.
Supporta standard molto importanti e diffusi:
•
Portlet Specification and API 1.0 (JSR-168)
•
JSR-252 (Java Server Faces) 1.2
•
JMX (Java Management Extension) 1.2
•
WSRP (Web Services for Remote Portlets) 1.0
•
Full J2EE 1.4 compliance quando usato con JBoss AS
Pagina 5 di 148
Alcune delle sue caratteristiche che lo contraddistinguono sono:
•
Elevata dinamicità che permette di creare, rimuovere e modificare portlet, temi,
layout, finestre e impostazioni di sicurezza a runtime.
•
IPC
(Interportlet
Comunication)
notevolmente
irrobustita
attraverso
un'organizzazione gerarchica delle portlet.
1.1. Caratteristiche
Liferay si può definire come un Portlet Engine. Viene distribuito anche come EAR
(Enterprise Archive) all'interno della Application Server JBoss.
JBoss implementa l'intera suite di servizi che si basano sulla Java Enterprise Edition.
Sono legati a JBoss tanti altri progetti open source che vengono racchiusi tutti sotto il
marchio della JBoss Enterprise Middleware Suite (JEMS)
In questo modo Liferay si può avvalere di tutti i vantaggi apportati dalla suite JEMS:
•
Disponibilità del servizio Object-Relational Mapping (ORM) fornito dalla
piattaforma per lo sviluppo di applicazioni Hibernate.
•
Utilizzo del Java Authentication and Authorization Service (JAAS) per la
gestione degli accessi alle risorse.
•
Caching per ridurre l'uso della banda e il tempo di accesso al sito.
•
Architettura cluster realizzando il sistema su un insieme di macchine
nascondendo la struttura alla vista del client.
•
Hot deployment delle portlet in modo da aggiungere applicazione war senza far
ripartire il server.
•
Single Sign On (SSO) e Lightweight Directory Access Protocol (LDAP) per
ottenere un'unica autenticazione e accedere alle risorse a lui consentite.
•
Business Process Management & Business Rules per ottimizzare, gestire e
monitorare i processi aziendali.
•
Gestire le transazioni distribuite su più server adibiti alla gestione delle risorse,
tramite un gestore delle transazioni.
Pagina 6 di 148
•
Utilizzo dell' Enterprise Messaging System (EMS) per permettere alle
organizzazioni di inviare messaggi tra i vari sistemi.
Di seguito una panoramica generale delle varie caratteristiche:
• Out-of-the-box tools: Grazie ad una community molto estesa, Liferay Portal
Server fornisce un grandissimo numero di portlet già integrate.
• SOA Framework: Liferay Portal Server è stato sviluppato utilizzando
l'architettura orientata ai servizi SOA Service Oriented Architecture che lo rende
la scelta ottimale per soluzioni Enterprise Application Integration in tecnologia
Web 2.0 tramite Web Services.
• Dynamic drag & drop: Liferay Portal Server offre la funzionalità di drag & drop
delle portlet. Gli utenti possono spostare gli elementi nel portale semplicemente
trascinando e rilasciando il mouse.
• Secure Single Sign On (SSO): Per accedere ai contenuti e alle applicazioni da
un punto unico di accesso. Liferay Portal Server può aggregare diversi sistemi
applicativi e renderli disponibili accedendo una volta sola con il massimo della
riservatezza tramite il Single Sign On.
• Granular, Role-Based Authorizations: Per garantire che le persone accedano con
diritto alle sole informazioni per le quali sono autorizzate. Gli amministratori
del portale possono assegnare ai singoli utenti o gruppi di utenti diversi "ruoli"
per attribuire loro differenti livelli di accesso e differenti diritti di modifica. Ad
esempio, un "direttore vendite" può visualizzare e modificare tutti i documenti
di vendita, ma un "Assistente di vendita" può solo visualizzarli.
• Personal User Pages : Tutti gli utenti abilitati potranno avere un spazio
personale dove immettere proprie informazioni. Potranno decidere se renderle
pubbliche o tenerle private. È possibile personalizzare lo spazio messo a
disposizione tramite il drag & drop delle portlet.
• Gestione contenuti: Il CMS integrato all'interno di Liferay Portal Server
fornisce un insieme esteso di funzionalità fortemente integrate con le funzioni
Pagina 7 di 148
di collaborazione e fornisce un repository centralizzato per conservare e gestire
contenuti da visualizzare sul web. Ciascuna community e ciascuna organization
hanno a disposizione una propria separata document library e image gallery.
Il CMS è implementato tramite Liferay Journal, un contenuto instrinseco (builtin) del portale Liferay che abilita una serie di funzionalità di gestione contenuti:
• Web Publishing: E' un sistema che può essere usato per creare pagine web in
modo veloce usando dei contenuti riusabili, dei modelli (Template) per il layout
flessibili.
• Flexibile Template Mechanism (XSL/VM): I modelli creati per gli Articoli
possono essere fatti in XSL o Velocity (VM) dando cosi agli sviluppatori la
flessibilità di disegnare le pagine web.
• Document Library: Provvede un deposito centralizzato per i servizi della
Library, fatto con JCR-170 Java Content Repository (Jackrabbit) per trattare
diversi documenti (PDF, DOC ...) che possono essere salvati sotto una unica
URL (vedi DocManagement).
• Image Gallery: Provvede un deposito centralizzato per immagini.
• Portal Publishing & Staging: Publishing permette di modificare pagine web in
tempo reale però senza pubblicare subito il cambiamento, solo quando si decide
di farlo. Invece Staging per creare varie copie di modifica della stessa pagina e
testarle senza toccare le pagine correnti sul Portale
1.2. Organizzazione delle Portlet
Liferay mette a disposizione tre tipologie di Portlet di amministrazione: Enterprise,
Organization e Location. .
La Portlet di tipo Enterprise ha il livello più alto di funzioni amministrative ed ha
accesso alle altre due Portlet amministrative e a quelle degli utenti.
La Portlet Organization può accedere, oltre che alle proprie informazioni, anche a tutte
quelle delle Location e degli utenti che appartengono ad essa.
Pagina 8 di 148
La Portlet Location, di conseguenza, accede alle proprie informazioni e a quelle dei
propri utenti.
Organization e Location rappresentano una gerarchia societaria. Organization
rappresenta la corporazione padre e può avere un qualunque numero di Location che
rappresentano invece le corporazioni figlie. Un utente può appartenere solo ad una
singola Organization e Location.
Gli utenti invece (Users) sono agglomerati in gruppi e assegnati, dagli amministratori,
in base ai permessi e ruoli. Un utente può appartenere ad un qualunque numero di
gruppi.
figura 2 : Vista della schermata Location
Come si vede dalla figura 1, le varie tipologie sono organizzate in tab. Per ognuna di
esse è possibile cercare oppure aggiungere. Cercare per esempio tutte le Location che
appartengono ad una determinata Organization, oppure aggiungere una Location
inserendo le informazioni necessarie.
Pagina 9 di 148
1.3. Permessi e sicurezza
Liferay ha un modello di sicurezza che include un sistema di permessi granulare che da agli
amministratori il pieno controllo sugli accessi e privilegi sulle Portlet ed oggetti all'interno del
portale.
Per comprendere questo modello di sicurezza è necessario prima capire tutte le entità
che lo compongono.
Risorsa è un termine generico per qualunque oggetto rappresentato in un portale.
Risorse sono, per esempio, Portlet, classi Java e File.
Le risorse possono avere una delle tre seguenti competenze: Enterprise, Community e
Individual.
Enterprise racchiude tutti gli oggetti all'interno del portale.
I permessi possono essere definiti come azioni da compiere su una risorsa.
Con i permessi di visualizzazione, per esempio, un utente può leggere qualunque topic.
Se i permessi sono assegnati ad una Community, Organization o Location, allora tutti
gli utenti che sono membri di questa entità riceveranno questi permessi.
Un ruolo è una collezione di permessi. Non ha nessuna altra utilità o scopo se non
quello di contenere i permessi a lui assegnati. Un ruolo può essere assegnato anche ad
una delle entità sopra descritte. In questo modo, tutti gli utenti che fanno parte di quei
gruppi, riceveranno i permessi di quel ruolo.
Un utente, in generale, è una persona che esegue operazioni sul portale. A seconda di
Pagina 10 di 148
quali saranno i privilegi e i ruoli a lui assegnati, avrà o non avrà i permessi per
eseguire determinate operazioni.
Prima di effettuare il login sul portale, l'utente è considerato un ospite (Guest) e in
quanto tale avrà il proprio set di permessi di default per gli oggetti del portale.
Solamente una volta autenticato sarà riconosciuto come un utente registrato. Un utente
registrato quindi, riassumendo quanto detto sopra, può ricevere i permessi nel seguente
modi:
•
Permessi direttamente assegnati all'utente
•
Permessi assegnati alla Community di appartenenza dell'utente
•
Permessi assegnati alla Organization alla quale l'utente appartiene
•
Permessi assegnati alla Location dell'utente
•
Permessi appartenenti al ruolo assegnato all'utente
•
Permessi di appartenenza al ruolo della Community dell'utente
•
Permessi di appartenenza al ruolo della Organization dell'utente
•
Permessi di appartenenza al ruolo della Location dell'utente
Pagina 11 di 148
figura 3 : Schermata dei ruoli con le azioni associate
2. Panoramica sull'applicazione NAGIOS
NAGIOS è una applicazione open source per il monitoraggio delle reti locali.
Un sistema di monitoraggio si occupa di controllare risorse delle macchine (carico
della CPU, memoria utilizzata, numero di processi attivi, ect.), e la disponibilità dei
servizi che i server offrono.
NAGIOS è l'acronimo di Notice Any Glitches In Our System, cioè notifica qualsiasi
malfunzionamento nel nostro sistema. Tra le varie funzionalità infatti c'è anche la
possibilità di abilitare le notifiche che ci saranno inviate, tramite email o sms, nel caso
si presenti un problema.
Sul mercato sono presenti altre soluzioni per il controllo dei sistemi.
La HP (Hewlett Packard) per esempio, distribuisce OpenView. OpenView è un
programma modulare che, grazie alla sua modularità, permette di caricare solo il
modulo relativo a quello che si vuole controllare, senza quindi appesantire troppo il
sistema.
Pagina 12 di 148
Un'altra alternativa è il Tivoli-netview della IBM che ha funzionalità dello stesso
livello di OpenView.
Entrambi però hanno un costo molto alto e presentano alcuni lati negativo. Openview
per esempio non dispone di una interfaccia web e può visionare lo stato dei sistemi
solo dal pc sul quale è installato.
Nonostante siano programmi più che buoni, considerando anche il costo, si preferisce
l'alternativa open source.
2.1. Caratteristiche e requisiti
NAGIOS è un demone, un programma sempre attivo eseguito in background e
residente in memoria. Nei file di configurazione sono specificate le modalità di
controllo e, in caso di malfunzionamenti, invia le notifiche a tutti gli utenti interessati.
NAGIOS si serve dei plugin per effettuare le interrogazioni ai servizi. Questi plugin
altro non sono che programmi i quali, una volta lanciati, interrogano i servizi e
restituiscono uno status e un output.
L'interfaccia web mette a disposizione una elevata quantità di dettagli mostrando lo
stato di tutti i servizi e tutto quello che è stato deciso debba essere controllato.
I requisiti necessari per la compilazione e il funzionamento di NAGIOS sono:
•
Un compilatore C utilizzato per la compilazione del programma e di tutti i
plugin relativi.
•
Una macchina che funga da web server che venga configurata affinché
Pagina 13 di 148
visualizzi l'interfaccia web. Deve supportare la tecnologia standard CGI usata
per interfacciarsi con applicazioni esterne.
•
La Graphics Library GD necessaria per generare, nell'interfaccia web, grafici e
disegni.
•
In ogni caso, al momento della configurazione di NAGIOS, qualunque requisito
manchi viene segnalato.
2.2. Installazione automatica
L'installazione di NAGIOS può essere fatta in due modi: Automatica e Manuale. Ho
eseguito entrambe le installazioni, la prima per il sistema definitivo sul server e la
seconda inizialmente come sistema di prova su una macchina locale.
Il primo modo, che è anche quello più semplice per chi voglia installare rapidamente
un sistema di monitoraggio completo di tool di configurazione, consiste
nell'installazione tramite FAN (Fully Automated NAGIOS).
Questa installazione è completamente automatica e si può completare in pochi
semplici passi.
Per prima cosa recarsi all'indirizzo:
http://fannagioscd.sourceforge.net/drupal/?q=node/11 .
Pagina 14 di 148
Da questa pagina è possibile scaricare la iso dell'ultima versione di FAN, attualmente
la FAN 2.0. La iso successivamente deve essere masterizzata su un cd.
L'installazione dal cd è guidata e necessita di risposte ad alcune domande.
Completata la procedura di installazione, si può accedere all'interfaccia di FAN tramite
un browser web, inserendo l'indirizzo IP della macchina.
Nel nostro caso, si può accedere alla pagina visualizzata nella figura 4, dall'indirizzo:
http://tier2-nagios.na.infn.it/
Da questa interfaccia sono raggiungibili i vari tool di configurazione, come si può
osservare appunto dalla figura.
figura 4 : Schermata principale di FAN
Pagina 15 di 148
2.3. Installazione manuale
L'altro modo per installare NAGIOS è la procedura manuale.
A questo proposito è necessario scaricare, dal sito ufficiale www.nagios.org, i file
sorgenti. I file che ci interessano sono il “Nagios Core” e il “Nagios Plugins”.
L'ultima versione di questi file è rispettivamente: nagios-3.2.3.tar.gz e nagios-plugins1.4.15.tar.gz.
Prima di iniziare l'installazione è necessario creare un nuovo utente il quale avvierà il
demone. Quello di default è “nagios”, ma è possibile cambiarlo in fase di
compilazione:
# adduser nagios
Una volta scaricati i file, estrarre il primo:
# tar -xzvf nagios-3.2.3.tar.gz
Supponiamo che il file sia stato estratto nella directory “/usr/local”, in questa viene
creata una directory, di nome nagios-3.2.3, nella quale è contenuto il programma.
Entrando in questa directory si può iniziare l'installazione.
Il primo comando da lanciare è “./configure” .
Questo comando è seguito da una serie di parametri. Non specificando alcun
parametro vengono utilizzati quelli di default. Nell'esempio seguente vengono
specificati proprio i parametri di default, unicamente per far capire come
personalizzare ulteriormente la propria installazione:
# ./configure --prefix=/usr/local/nagios --with-cgiurl=/nagios/cgi-bin --withEsposito Paolo 566/2008
Pagina 16 di 148
htmurl=/nagios/ --with- nagios-user=nagios –with-nagios-grp=nagios
Questa configurazione potrebbe non andare a buon fine nel caso mancassero
determinati pacchetti necessari all'installazione. In tal caso un messaggio di errore
indica quali pacchetti mancano, quindi installare questi pacchetti ed eseguire
nuovamente il comando.
Completata la configurazione dell'installazione, si può procedere con la compilazione,
seguita dall'installazione del programma:
# make all
# make install
Si procede poi con l'installazione dello script init, necessario per avviare
automaticamente il programma durante il boot del sistema e controllarne il corretto
funzionamento. In pratica controlla le operazioni di start, stop, restart e reload del
servizio.
# make install-init
Per completare l'installazione, installare i file di esempio utili per orientarsi durante la
prima configurazione:
# make install-config
Installiamo ora i plugin scaricati con l'altro file.
# tar -xzvf nagios-plugins-1.4.15.tar.gz
Pagina 17 di 148
Spostarsi nella cartella creata e far partire la configurazione dell'installazione.
# ./configure --prefix=/usr/local/nagios --with-nagios-user=nagios --with-nagiosgroup=nagios
# make all
# make install
A questo punto l'installazione può dirsi terminata e la directory /user/local/nagios/ ha il
seguente contenuto:
bin etc libexec sbin share var
Di seguito una breve descrizione del contenuto di queste cartelle:
•
bin: contiene il file eseguibile nagios
•
etc: i file di esempio e i file effettivi di configurazione
•
libexec: i file eseguibili dei plugin
•
sbin: gli script CGI per l'interfacia web
•
share: le pagine web statiche e la documentazione
•
var: le informazioni di esecuzione di nagios
Ultimata l'installazione non resta che la configurazione
2.4. Configurazione di NAGIOS
La configurazione di NAGIOS è un processo molto importante in quanto permette di
personalizzarlo tenendo conto di tutte le necessità.
Pagina 18 di 148
Proprio per questo motivo la configurazione non è un processo standard, ma varia a
seconda di quello che si vuole monitorare.
L'esempio seguente prende in considerazione il monitoraggio dello stato di una sola
risorsa, la macchina “local_pc”.
Per tutti i file di configurazione si può ovviamente prendere spunto dai file di esempio
precedentemente installati.
Prendere quindi il file hosts.cfg-sample e crearne uno uguale di nome hosts.cfg.
In questo file vengono specificate le informazioni di tutti gli host che devono essere
monitorati.
Il contenuto del file è il seguente:
figura 5 : Contenuto del file hosts.cfg
La definizione è abbastanza intuitiva in quanto ogni parametro è auto-esplicativo. Il
parametro più importante è “address”, cioè l'indirizzo della macchina. Può essere sia
un indirizzo locale che un indirizzo esterno.
Pagina 19 di 148
Il file hostgroups.cfg definisce invece i gruppi di host e il gruppo di contatto che sarà
allertato in caso di malfunzionamento.
figura 6 : Contenuto del file hostgroups.cfg
I contatti di riferimento invece sono organizzati in gruppi nel file contactgroups.cfg,
come è visibile in figura 7.
figura 7 : Contenuto del file contactgroups.cfg
I dettagli relativi ai contatti invece sono definiti nel file contact.cfg
Pagina 20 di 148
figura 8 : Contenuto del file contact.cfg
L'ultimo file di configurazione rimasto è quello relativo ai servizi “service.cfg”. Anche
in questo caso è presente un template definito come “generic-service” che va
obbligatoriamente incluso in testa al file.
Sotto a questa definizione vengono inserite le dichiarazioni dei servizi che si vogliono
monitorare.
Nella figura 9 si può vedere la definizione del servizio ping.
Osservando la dichiarazione del servizio si può capire come possa può capire come
possa essere regolato qualsiasi dettaglio, come il periodo di tempo (la cui definizione è
indicata nel file time.periods.cfg) di ventiquattro ore per sette giorni a settimana, il
numero massimo di tentativi prima di inviare la segnalazione di malfunzionamento,
dove inviare la notifica, ect.
Il parametro che indica il comando che viene eseguito per effettuare il controllo è
check_command, dove viene specificato il nome del plugin da utilizzare.
Nella figura 9 si può vedere anche come passare dei parametri al plugin, utilizzando il
punto esclamativo.
Pagina 21 di 148
figura 9 : Contenuto del file service.cfg
Come inserire nuovi plugin è spiegato nei capitoli successivi dove si parlerà dell'addon
NRPE e dei suoi plugin.
Il file dove sono indicate le opzioni per la gestione dei CGI, per l'utilizzo
dell'interfaccia web, è cgi.cfg.
I CGI sono una serie di programmi che NAGIOS utilizza per visualizzare nelle pagine
web le più svariate informazioni. Questi si trovano nella sottodirectory sbin.
In questo file vengono abilitate le linee relative ai permessi d'accesso.
Può essere utile definire, per esempio, l'utente che potrà accedere alla consultazione di
tutte le informazioni di NAGIOS, tramite browser.
In questo caso si deve specificare l'utente alla riga:
authorized_for_system_information =
Pagina 22 di 148
Tra i file rimanenti dependencies.cfg che contiene le dipendenze dei servizi al suo
interno. Si deve indicare, per esempio, che il sito non può funzionare senza
l'esecuzione del web server.
Un altro file è escalations.cfg nel quale vengono definite il numero totale di volte in
cui una notifica deve essere segnalata.
Altri file di configurazione verranno spiegati più avanti, quando si parlerà di NRPE.
Per ultimare la fase di installazione bisogna configurare il Server Web
2.5. Configurazione di Apache
Prima di avviare il programma è necessario predisporre il nostro Server Web Apache,
per il funzionamento di NAGIOS. Quindi nel file httpd.cfg devono essere aggiunge le
righe mostrate in figura 10:
Pagina 23 di 148
figura 10 : Contenuto del file httpd.cfg
In questo modo vengono dichiarate e protette le directory di NAGIOS.
Il discorso autenticazione si completa con la creazione del file “.htaccess ” nella
cartella cgi, con il contenuti mostrato in figura 11:
figura 11 : Contenuto del file .htaccess
Così facendo, la consultazione dei dati relativi allo stato dei servizi, è protetta.
Accedendo quindi alla pagina di Nagios, viene richiesta l'autenticazione con il nome
utente e password.
Pagina 24 di 148
Con il comando htpasswd si crea il file htpasswd.users che indica ad apache dove sono
inclusi i dati di accesso. Il comando è il seguente:
# htpasswd -c /usr/local/nagios/etc/ htpasswd.users local_user_1
Il file così viene creato e viene chiesto di inserire la password per l'utente specificato.
L'opzione -c serve per creare il file, quindi nel caso si vogliano aggiungere altri utenti
si potrà anche omettere.
La fase di configurazione è completata. Per avviare il demone di NAGIOS si deve
andare nella cartella /etc/xinetd/ e lanciare il seguente comando:
# nagios start
La maggior parte delle operazioni descritte sopra sono automatizzate utilizzando FAN.
Come verrà spiegato più avanti, nel capitolo riguardante Centreon, tutta la fase di
aggiunta di host, host group e servizi, così come fermare, avviare, riavviare e ricaricare
NAGIOS, può essere gestita tramite l'interfaccia di Centreon.
2.6. Interfaccia Web
In questo capitolo viene descritta l'interfaccia di NAGIOS e vengono spiegate tutte le
sue funzionalità accessibili dal suo menù.
Nella figura seguente si può vedere l'interfaccia di Nagios, in particolare il suo menù,
Pagina 25 di 148
alla quale si accede dall'indirizzo http://tier2-nagios.na.infn.it/nagios/.
figura 12 : Menu di Nagios
Nella seguente lista invece vengono elencate e descritte le varie voci del menù con le
rispettive funzionalità:
•
Tactical Overview
Per monitorare tutte le attività di monitoraggio della rete. Permette di vedere
rapidamente le interruzioni della rete, lo stato degli host e dei servizi
distinguendo tra i problemi che sono stati gestiti in qualche modo e quelli
invece che non sono stati gestiti e richiedono un intervento.
•
Nagvis Overview
Collegamento a Nagvis
•
NaReTo Overview
Pagina 26 di 148
Collegamento a NaReTo
•
Service Detail
Visualizza una lista dove sono mostrati tutti i servizi e i relativi dettagli sul loro
stato.
•
Host Detail
Visualizza una lista dove sono mostrati tutti gli host e i relativi dettagli sul loro
stato.
•
Hostname
È un form di ricerca che permette di ricercare un determinato host. La ricerca
mostra tutti i servizi sul host cercato.
•
Host Group
Visualizza un sommario di tutti gli host group con il sommario sullo stato dei
relativi host e servizi.
•
Service Group
•
Status Map
Per visualizzare una mappa creata automaticamente di tutti gli host che sono
stati definiti sulla rete.
•
Service Problems
Per visualizzare una lista di tutti i problemi relativi ai servizi, per ogni host. È
possibile visualizzare tutti i problemi oppure solo quelli non gestiti e risolti.
•
Host Problems
Per visualizzare una lista di tutti gli host che hanno problemi. Così come i
Service Problem, anche qui si possono visualizzare tutti gli host che hanno
problemi oppure solo quelli che hanno problemi che non sono stati risolti.
•
Comments
Permette di inserire, quindi anche di visualizzare, commenti relativi ad un
determinato host o servizio.
•
Downtime
Pagina 27 di 148
Visualizza, nel caso ce ne siano, gli host o i servizi che attendono di essere
schedulati.
•
Trends
Per visualizzare un grafico, creato automaticamente, sullo stato di host e servizi
su un prefissato periodo di tempo.
•
Availability
Per visualizzare la disponibilità di determinati host e servizi in un determinato
periodo di tempo, il tutto tramite parametri specificati dall'utente.
•
Alerts
Per visualizzare la cronologia dei problemi, per uno specifico host oppure per
tutti gli host. Si può anche filtrare le informazioni visualizzando solamente un
determinato tipo di problema.
•
Notifications
Per visualizzare le notifiche degli host e dei servizi che sono state mandate ai
contatti designati. Così come per la cronologia dei problemi, anche qui si può
filtrare le informazioni visualizzando solamente un determinato tipo di notifica.
•
Event Log
Mosta semplicemente il log file.
•
Performance
Visualizza statistiche relative agli host e servizi controllati in determinati
intervalli di tempo.
•
View Config
Visualizza qualsiasi file di configurazione scelto dall'utente.
3. L'addon NRPE
I servizi standard di una macchina possono essere controllati da remoto tramite
Pagina 28 di 148
l'interrogazione delle porte TCP. Allo stesso modo però non possono essere controllate
le risorse locali quali caricamento cpu, uso memoria, capienza del disco, processi in
esecuzione o numero di utenti collegati.
NRPE è stato progettato proprio per risolvere questo problema e permettere
l'esecuzione di NAGIOS su macchine remote linux.
E' possibile eseguire il NAGIOS plugin, su macchine remote linux, attraverso SSH.
C'è infatti un plugin chiamato check_by_ssh che permette di fare tutto questo.
Usare SSH è più sicuro che usare l'addon NRPE ma comporta un maggiore overhead
sia sulla macchina di monitoraggio che su quella remota.
Questo può diventare un problema quando si inizia a monitorare centinaia o migliaia
di macchine. Proprio per questo motivo molti preferiscono utilizzare l'addon NRPE
3.1. Nagios Remote Plugin Executor
L'addon di NRPE consiste di 2 componenti:
•
Il plugin check_nrpe, sulla macchina adibita al monitoraggio. Dove quindi è
presente NAGIOS.
•
Il demone nrpe che gira sulla macchina remota linux, dove si vuole effettuare il
controllo.
Quando NAGIOS ha bisogno di monitorare una risorsa su una macchina remota, la
logica di funzionamento è la seguente:
•
NAGIOS esegue il plugin check_nrpe e gli comunica che servizio ha bisogno di
essere controllato passando come parametro il nome del plugin remoto che si
vuole lanciare e il nome della macchina remota.
•
il plugin check_nrpe contatta il demone NRPE, in ascolto su una determinata
Pagina 29 di 148
porta (di solito la porta 5666), sul host remoto in questione, eventualmente con
una connessione protetta SSL.
•
Il demone NRPE esegue il plugin locale appropriato per controllare il servizio o
la risorsa.
•
Il risultato dal controllo del servizio è restituito dal demone NRPE al plugin
check_nrpe che lo ritorna al processo NAGIOS.
figura 13 : Schema del collegamento tra il plugin check_nrpe e il demone NRPE
Il demone NRPE richiede quindi che il plugin NAGIOS sia installato sulla macchina
remota. Senza il demone non è in grado di monitorare niente.
L'uso più diffuso dell'addon NRPE è monitorare risorse locali o private su una
macchina remota linux come caricamento cpu, memoria usata, swap usata, utenti
correnti, dischi usati, stato dei processi, ect.
figura 14 : Utilizzo diretto del NRPE
Si può anche usare NRPE per controllare indirettamente servizi pubblici e risorse di un
Pagina 30 di 148
server remoto che non possono essere raggiungibili direttamente dal host di
monitoraggio.
Se un host remoto con il demone NRPE e i plugin può comunicare con un web server
remoto, ma la macchina di monitoraggio no, si può configurare il demone NRPE per
monitorare il web server remoto indirettamente.
figura 15 : Utilizzo indiretto del NRPE
Pagina 31 di 148
3.2. Tipologia dei Nodi della rete
Prima di iniziare a installare NRPE su tutte le macchine è necessario avere una visione
completa di come è strutturata la rete, in particolare il data center, e le tipologie di
macchine che lo compongono.
Il datacenter SCoPE è situato nei pressi del dipartimento di Biologia, non molto
lontano dalla Control Room. Tutti quanti gli apparati sono raccolti all'interno dei rack,
come è visibile nella seguente figura:
figura 16: Rack del centro di calcolo.
Diventa fondamentale quindi distinguere il tipo di macchina, quali sono i suoi compiti
e quali sue risorse ci interessa monitorare.
Più in avanti si avrà una visione globale, attraverso le mappe, di quali e quanti
Pagina 32 di 148
componenti sono contenuti all'interno di ogni rack. È importante però ora fare una
distinzione in base alla tipologia delle macchine.
Di seguito un elenco, con una descrizione riguardante l' utilizzo, di tutti gli apparati e
macchine presenti:
•
Worker Node: è un nodo che esegue i calcoli elaborando i dati contenuti
all'interno degli Storage Element. Tra le varie risorse che può essere utile
monitorare c'è la quantità di memoria libera, lo spazio sul disco o il carico della
CPU.
•
Storage Element: è un nodo che ha come compito principale la
memorizzazione e l'accesso ai dati, che devono essere elaborati dai Worker
Node. Le risorse che può essere utile monitorare sono le stesse dei Worker
Node.
•
Service Node: è un nodo che ha il compito di smistare i job che devono essere
eseguiti sui Worker Node. Fa parte di questa tipologia anche il Computing
Element, macchina che deve gestire le code e che quindi deve avere uno
scheduler e un gestore delle risorse. In questo caso, oltre alle solite risorse,
diventa fondamentale monitorare anche le code.
•
Switch: apparati adibiti alla gestione del traffico. Poiché il trasferimento dei
dati è un parametro fondamentale per gli switch può essere utile controllare il
traffico oppure da quanto tempo lo switch è up.
•
CMC (Central Management Console ): apparati presenti in tutti i rack che
hanno il compito di controllare informazioni quali la temperatura, temperatura
dell'acqua o la velocità delle ventole. Questi quindi sono informazioni che
vanno monitorate per questa tipologia.
•
UPS (Uninterruptible Power Supply ): sono dei gruppi di continuità che
entrano in funzione quando manca la corrente e assicurano una determinata
autonomia in questi casi. Oltre al tempo di autonomia può essere utile
Pagina 33 di 148
monitorare anche la carica.
Queste quindi sono le varie tipologie di apparati presenti nel centro di calcolo. È stato
descritto brevemente quali sono le risorse locali che può essere utile monitorare. Per
ogni risorsa è presente un relativo plugin (script) eseguibile localmente o da remoto.
In seguito si vedrà come utilizzare questi plugin, in particolare per il controllo remoto
delle risorse.
3.3. Installazione e configurazione del NRPE
Nel caso non siano stati installati ancora i plugin, si possono scaricare, conoscendo
l'indirizzo del file, direttamente con il comando wget:
# wget http://downloads.sourceforge.net/project/nagiosplug/nagiosplug/1.4.14/nagiosplugins-1.4.14.tar.gz?use_mirror=garr&29422187
Per procedere con l'installazione è necessario scaricare l'addon NRPE. Sia il plugin che
il demone si trovano in un unico pacchetto. Conoscendo già l'indirizzo del file da
scaricare, utilizziamo il comando wget per scaricarlo:
# wget http://downloads.sourceforge.net/project/nagios/nrpe-2.x/nrpe-2.12/nrpe2.12.tar.gz?use_mirror=garr&62681991
Per estrarre i file ed entrare nella cartella:
# tar xzf nrpe-2.12.tar.gz
# cd nrpe-2.12
Configurare l'addon nrpe con il seguente comando:
# ./configure
La configurazione potrebbe non andare a buon fine ritornando il seguente messaggio
Pagina 34 di 148
di errore:
checking for SSL headers... configure: error: Cannot find ssl headers
Questo significa che non sono state trovate le librerie relative al SSL.
SSL è l'acronimo di Secure Sockets Layers, letteralmente Livello di Socket Sicuri, ed è
un protocollo che permette una comunicazione sicura su reti TCP.
Per ovviare a questa mancanza, ci sono due modi per procedere.
Il primo modo prevede di installare le librerie in questione e ricompilare:
# yum install libssl-dev
Il secondo modo prevede invece di continuare la configurazione disabilitando lo SSL.
Quindi eseguo di nuovo la configurazione senza SSL e compilo:
# ./configure –disable-ssl
# make all
Alla fine di questo processo viene visualizzato a video il messaggio visibile nella
figura 17:
Pagina 35 di 148
figura 17 : Messaggio dopo la compilazione
Queste sono fondamentalmente le istruzioni per proseguire. La procedura completa
verrà però descritta di seguito.
Installare alcuni plugin che utilizzerò per il test, il demone e file di esempio per la
configurazione demone:
# make install-plugin
# make install-daemon
# make install-daemon-config
Installare il demone nrpe come un servizio sotto xinetd
# make install-xinetd
XINETD sta per eXtended InterNET services Daemon, e ha preso il posto di INETD
per ragioni di sicurezza. INETDT è un demone che resta in ascolto sulle porte
specificate nel suo file di configurazione e si occupa di avviare il relativo servizio nel
momento in cui viene fatta una richiesta.
Viene chiamato super demone per la sua funzione di controllo di altri demoni.
I vantaggi nell'usarlo sono evidenti. In questo modo si ottimizzano le risorse del
sistema avviando un programma relativo ad un determinato servizio solo quando ci
sono effettive richieste.
Il file nel quale vengono assegnati i servizi alle relative porte è /etc/services, un file
utilizzato anche da altri programmi.
Per proseguire nella configurazione quindi è necessario aggiungere anche nrpe tra i
suoi servizi. Aprire quindi il file /etc/services e metterlo in ascolto sulla porta 5666
aggiungendo la seguente riga:
nrpe
5666/tcp
# NRPE
Pagina 36 di 148
Altro file di configurazione da modificare è il file /etc/xinetd.d/nrpe. Il contenuto del
file è mostrato nella figura 18.
figura 18 : Contenuto del file /etc/xinetd.d/nrpe
Di default questo file è disabilitato, quindi la voce disable è impostata a yes.
Per utilizzare però NRPE sotto xinetd è necessario abilitare questo file di
configurazione e impostare disable a no. Questa operazione va accompagnata con
quella fatta precedentemente aggiungendo la riga nel file /etc/services.
Nella figura 18 possiamo notare che alla voce only_from c'è indirizzo IP. In particolare
only_from indica gli indirizzi abilitati alla comunicazione con il demone. L'indirizzo
IP della figura 18 è quello del server di monitoraggio e quindi dovrà essere impostato
proprio come mostrato in figura.
Inizialmente però, per fare dei test in locale, mettiamo come indirizzo quello del
localhost, quindi 127.0.0.1:
only_from = 127.0.0.1
Riavviare il servizio xinetd per rendere valide le modifiche:
Pagina 37 di 148
# service xinetd restart
Per testare se il demone nrpe è stato installato e configurato con successo, possiamo
testarlo quindi prima in locale.
Possiamo, a questo scopo, utilizzare alcuni script di prova installati precedentemente.
Prima di tutto assicuriamoci che il demone stia girando sotto xinetd.
Utilizziamo netstat che ci permette di vedere lo stato delle connessioni sul computer,
con le opzioni “-at” che ci permettono rispettivamente di vedere anche lo stato dei
socket non attivi in quel momento e di prendere solo le connessioni tcp:
# netstat -at | grep nrpe
Con il grep prendiamo solo le righe dove compare nrpe.
L'output dovrebbe mostrare un nrpe in ascolto. Il risultato di questo comando dovrebbe
essere quello nella figura 19
figura 19 : Output del comando netstat -at | grep nrpe
Il secondo test che facciamo ci assicura che il demone nrpe funziona correttamente.
Utiliziamo sempre uno dei plugin installati precedentemente.
Spostiamoci nella cartella dove è istallato check_nrpe, che dovrebbe essere
/usr/local/nagios/libexec/ (in alternativa cercare in /usr/lib64/nagios/plugins o qualcosa
di simile) , e lanciamo lo script:
# ./check_nrpe -H localhost
Questo comando dovrebbe restituire la versione installata di nrpe:
NRPE v2.12
L'opzione -H serve per specificare il nome del host. Un'altra opzione del comando
Pagina 38 di 148
check_nrpe è -c che viene utilizzata per l'esecuzione di un plugin e verrà spiegata più
in avanti.
A questo punto si dovrebbe controllare se il firewall sulla macchina permette l'accesso
al demone nrpe ai servizi remoti.
Con il comando “iptables -L” vediamo l'attuale situazione del firewall.
Nel caso siano permessi tutti gli accessi, come in figura 20, si può proseguire,
altrimenti si deve creare una eccezione.
figura 20 : Output del comando iptables -L
Questa procedura di configurazione, compresi i passaggi per Xinetd, è stata adottata
sui Storage Element, Worker Node e Service Node. La correttezza della procedura è
assicurata dai 2 test che vengono eseguiti.
Ci sono state alcune complicazioni che hanno portato a delle varianti nella
configurazione.
La prima complicazione ha riguardato gli Storage Element per i quali alla voce
only_from, della figura 18, c'è stato bisogno di specificare un altro indirizzo.
L'indirizzo in questione è quello esterno di tier2-nagios.na.infn.it:
only_from = 90.147.67.9
L'ultimo file di configurazione rimasto è nrpe.cfg, dove sono definiti i vari comandi
per lanciare gli script di prova. Questo file verrà descritto nel prossimo capitolo,
riguardante la configurazione dei plugin.
Per concludere invece questo capitolo vediamo una panoramica sulle problematiche
che si possono presentare.
Pagina 39 di 148
3.4. Risoluzione dei problemi
Di seguito una serie di errori che possono essere ritornati dall'esecuzione del plugin
check_nrpe, con il relativo significato.
•
“CHECK_NRPE: Socket timeout after 10 seconds" or "Connection refused or
timed out":
Questo errore può indicare che il comando che è stato chiesto di lanciare al
demone NRPE ha preso più di 10 secondi per essere eseguito. Questa è la causa
più comune di questo errore. In questo caso si può utilizzare l'opzione -t dalla
linea di comando per specificare un tempo più lungo per il plugin check_nrpe.
L'esempio seguente incrementa incrementa il tempo portandolo a 30 secondi:
# check_nrpe -H localhost -c generic_command -t 30
Un'altra causa di questo problema può essere che il demone NRPE non sia
installato o non stia girando sulla macchina remota. Bisogna quindi verificare
che il demone stia girando, come un demone indipendente oppure come sotto
inetd/xinetd. Si può controllare con i seguenti comandi:
# ps axuw | grep nrpe
# netstat -at | grep nrpe
L'ultima causa di questo problema può essere il firewall che blocca la
comunicazione tra il server di monitoraggio, dove è stato lanciato il plugin
check_nrpe, e la macchina remota sulla quale gira il demone NRPE.
In questo caso di devono verificare le regole del firewall, come detto già
precedentemente utilizzando il comando iptables, e controllare che non ci sia un
firewall fisicamente posizionato tra le due macchine.
•
"CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs
for an error message." :
La prima cosa che si dovrebbe controllare, come suggerisce il messaggio
Pagina 40 di 148
dell'errore, è il log del server remoto. Il messaggio del log dovrebbe dare
qualche indicazione a riguardo. Controllare la versione del OpenSSL su
entrambe le macchine. Se si sta usando una versione commerciale di SSL sul
host remoto, ci potrebbero essere problemi di compatibilità.
•
"NRPE: Unable to read output":
Questo errore indica che il comando lanciato dal demone NRPE non ha
ritornato nessun carattere in output. Questo può significare che la definizione
del comando, nel relativo file, è incorretta oppure che il plugin cui fa
riferimento il comando è mal funzionante. In questo caso si deve lanciare il
plugin direttamente da linea di comando, senza il check_nrpe, per controllarne
il funzionamento.
•
CHECK_NRPE: Error - Could not complete SSL handshake
Questo errore indica che non si riesce a stabilire la connessione tra le due
macchine. Questo problema dipende dalla macchina remota con il demone in
ascolto. Può capitare che la macchina funzioni in determinati momenti e in altri
momenti no, in particolare quando il carico della CPU tocca soglie elevate.
Questa eventualità si verifica lì dove NRPE gira in modalità standalone e non
sotto Xinedt.
•
"NRPE: Command 'x' not defined":
Questo errore significa che non è stato definito il comando x nel file di
configurazione sul host remoto. Corretto il comando, è necessario, in caso il
demone stia girando indipendentemente e non sotto inetd o xinetd, riavviare il
servizio.
•
"NRPE: Command timed out after x seconds":
Questo errore indica che il comando che è stato lanciato dal demone NRPE non
ha finito la sua esecuzione nei tempi specificati. Si può incrementare questo
tempo nel file di configurazione, dove sono definiti i comandi, modificando il
valore della variabile command_timeout. Così come nel caso precedente è
necessario riavviare il servizio per rendere attiva questa modifica.
Pagina 41 di 148
Nel caso ci siano altri problemi può essere utile attivare il debug. Nel file di
configurazione modificare il valore del parametro debug portandolo ad 1 e riavviare il
servizio. Eseguendo di nuovo il plugin check_nrpe si dovrebbero avere delle
informazioni di debuggin, nel file di log, sulla macchia remota. Leggendo attentamente
il file di log si dovrebbero trovare degli indizi su dove persiste il problema.
I file di log di Nagios si trovano nella cartella /usr/local/nagios/var suddivisi in
differenti file. Il più importante è sicuramente “nagios.log” nel quale sono salvati tutti i
log in generale. Questo file viene salvato, ogni giorno, con la data corrispondente nella
sottodirectory archives. Così facendo si possono consultare i vecchi log, suddivisi per
data, e controllare eventualmente la causa di qualche malfunzionamento. In questo file
di log sono visualizzabili tutti i risultati dei controlli che vengono ritornati al server di
monitoraggio e tutte le informazioni sui malfunzionamenti.
Altri file di configurazione sono comment.log, downtime.log, status.sav e nagios.lock.
Comment.log contiene tutti commenti generati automaticamente da Nagios o che sono
stati scritti da un utente per descrivere un determinato malfunzionamento che si è
presentato su un host o un servizio.
Downtime.log contiene i periodi nei quali il monitoraggio di un determinato servizio o
host è stato sospeso con la relativa motivazione. Si può voler sospendere un servizio
che presenta un malfunzionamento per un determinato periodo in modo da evitare che
venga ripetutamente notificato.
Status.sav contiene lo stato che hanno gli host prima di terminare un determinato
processo.
Nagios.lock utilizzato quando Nagios, avendo molti servizi da monitorare, tende a
creare molti processi figli, quindi è necessario memorizzare l'id del processo padre.
Pagina 42 di 148
Questo file viene utilizzato anche quando si intende arrestare l'esecuzione di nagions e
quindi fermare il processo padre e tutti i suoi processi figlio.
4. Configurazione dei plugin
Nei precedenti capitoli sono stati installati il nucleo del programma di monitoraggio
NAGIOS e il suo addon NRPE per l'esecuzione remota del plugin. È stato installato
anche il pacchetto nagios-plugins che, come si intuisce dal nome del pacchetto,
contiene una collezione di plugin che possono essere utilizzati per il monitoraggio.
Di solito i plugin sono posizionati nella cartella omonima nella diretcory di
installazione di NAGIOS. Altre volte può capitare che, con una installazione
differente, siano posizionati invece nella cartella libexec.
Importante è non trascurare il percorso di questa directory, che potrebbe essere causa
del l'errore "NRPE: Unable to read output" in quanto, con un percorso errato, non
verrebbe trovato il plugin e l'esecuzione del plugin check_nrpe non produrrebbe alcun
output con conseguente errore.
Precedentemente è stato già accennato l'utilizzo del plugin check_nrpe. Questo plugin
è eseguito sul server di monitoraggio e richiede diverse opzioni. L'uso del plugin a
linea di comando è nel seguente formato:
# check_nrpe -H <host> [-n] [-u] [-p <port>] [-t <timeout>] [-c <command>] [-a
<arglist...>]
Le opzioni racchiuse tra parentesi quadre sono obbligatorie. Di seguito una breve
descrizione di quello che queste opzioni specificano:
•
-H: Indirizzo dell'host sul quale gira il demone NRPE.
•
-n: Non usare SSL
•
-u: Per far ritornare lo stato Unknown invece che Critical, quando scade il
tempo di attesa per il socket.
Pagina 43 di 148
•
-p: La porta sulla quale il demone sta girando. Per specificarne una diversa da
quella 5666 di default.
•
-t: Numero di secondi prima che il tempo della connessione scada. In questo
modo si specifica un valore diverso da quello standard di 10 secondi.
•
-c: Il nome del comando che il server remoto deve lanciare.
•
-a: Lista di argomenti che vengono passati al plugin specificato dal comando.
L'opzione -c è quella più importante in quanto specifica indirettamente il plugin che
deve essere eseguito. Per ogni plugin che voglia essere eseguito, sulla macchina
remota, si deve creare un comando nel file di configurazione.
Il file di configurazione nel quale vengono specificati questi comandi, nelle ultime
versioni di nagios, prende il nome di nrpe.cfg. Nelle versioni precedenti invece si
chiamava command.cfg.
Questo file si trova, a meno che non sia stato specificato un percorso diverso in fase di
installazione, nella cartella /ect/nagios. La definizione di un comando ha il formato
seguente:
command[<command_name>]=<command_line>
Quando il demone riceve la richiesta di ritornare il risultato di “command_name”,
eseguirà il comando specificato con la “command_line”. Questa richiesta fatta al
demone è proprio l'opzione -c seguita dal nome del comando, cioè il “command”.
4.1. Contenuto del file nrpe.cfg
Il file nrpe.cfg è un file di configurazione campione per il demone NRPE, quindi ha
bisogno di essere posizionato sul host remoto nel quale gira il demone e non sul host
da quale il client check_nrpe è stato eseguito.
Di seguito viene mostrato il contenuto del file, descritto riga per riga:
Pagina 44 di 148
log_facility=daemon
#Specifica il servizio che si occupa dei messaggi di log al
momento dell'autenticazione. La facility di default è daemon, cioè il demone syslogd.
pid_file=/var/run/nrpe.pid
#Il nome del file nel quale il demone NRPE scrive il
suo numero ID del suo processo. Il file è scritto solo se il demone è avviato dall'utente
root e in modalità indipendente. Quindi non viene creato alcun file in quanto il demone
gira come servizio sotto xinetd.
server_port=5666
#Porta sulla quale il demone aspetta per le connessioni.
server_address=172.16.20.148
#Questo indirizzo è utile per specificare una
particolare interfaccia, nel caso ce ne siano diverse, per il bind, assegnando questo
indirizzo alla socket.
nrpe_user=nagios
nrpe_group=nagios
#Queste due voci determinano rispettivamente
l'utente e il gruppo con cui dovrebbe girare il demone. Si può specificare un nome
utente (nome di un gruppo nel secondo caso) oppure un ID (GID)
allowed_hosts=127.0.0.1
#Questa è una opzionale lista di indirizzi IP (oppure
hostname), separati da una virgola, che indica quali host sono abilitati a comunicare
con il demone. Questo fa solo un controllo elementare sull'indirizzo IP del client.
Quindi è altamente consigliato, nel caso si voglia limitare la comunicazione a
determinati host, utilizzare il file /etc/hosts.allow per specificare gli host abilitati alla
connessione sulla porta sulla quale sta girando il demone.
Tutta le opzioni presenti fino a questo punto del file sono ignorate nel caso il demone
giri sotto xinetd. Quindi vengono specificate in un altro file, cioè il file nrpe nella
directory /etc/xinetd.d/, che verrà visto dettagliatamente in seguito.
dont_blame_nrpe=0
#Questa opzione determina se permettere o meno ai
client di specificare gli argomenti dei comandi che stanno eseguendo. Questa opzione
Pagina 45 di 148
è disabilitata di default ovviamente per questioni di sicurezza. Questa opzione, per
funzionare, necessita anche che, in fase di configurazione, sia con la seguente opzione:
--enable-command-args
Un'altra opzione disabilitata di default per questione di sicurezza è la seguente:
command_prefix=/usr/bin/sudo
#Questa opzione permette di inserire come prefisso a
tutti i comandi una stringa inserita dall'utente. Uno spazio è automaticamente aggiunto
tra la stringa specificata come prefisso e la linea di comando definita.
L'esempio specificato (/usr/bin/sudo) è solo un possibile scenario d'uso. In questo
modo si restringe l'esecuzione dei comandi con l'utilizzo di sudo. Per far questo è
necessario aggiungere l'utente nagios nel file /etc/sudoers. Per esempio si potrebbe
aggiungere questa riga, per permettere l'esecuzione dei plugin in quella cartella:
nagios
ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/
Questo fa in modo che gli utenti nagios possano lanciare tutti e soli i comandi di quella
directory senza password. Ovviamente non si deve assolutamente dare agli utenti
generici i permessi di scrittura su questa directory o ai suoi contenuti.
debug=0
#con questa opzione si possono aggiungere anche i messaggi di debug ai
log di sistema. Utile nel caso sia presente un malfunzionamento e si voglia qualche
informazione in più sulla causa.
command_timeout=60
#questa specifica il massimo numero di secondi
consentito ai plugin per finire la loro esecuzione. Dopo il tempo specificato il demone
ucciderà il processo.
connection_timeout=300
#questa specifica il massimo numero di secondi che
il demone aspetterà per una connessione che si sta stabilendo, prima di uscire. Spesso
viene visto come un problema di rete che ferma la SSL prima che sia stabilita
nonostante tutte le sessioni di rete siano connesse. Questo causa un accumulo che può
consumare le risorse del sistema, quindi si consiglia di non mettere valori troppo bassi.
allow_weak_random_seed=1
#questa direttiva, disabilitata di default, permette di
Pagina 46 di 148
usare SSL anche se non sono presenti i file /dev/random e /dev/urandom, file speciali
utilizzati per la generazione casuale di numeri. La generazione di numeri casuali viene
fata da un file il quale è un puntatore alla variabile d'ambiente $RANDFILE
oppure $HOME/.rnd. Se nessuna delle due esiste viene messo uno pseudo numero e un
segnale di warning viene inviato.
include=<somefile.cfg>
# questa opzione, disabilitata per default, permettere di
includere le definizioni da un file di configurazione esterno.
include_dir=<somedirectory>
#questa direttiva permette di includere file di
configurazione da una o più directory ricorsivamente.
Il resto del file consiste nella parte più importante per il funzionamento dei plugin,
cioè la definizione dei comandi che il demone lancerà.
La definizione è scritta nel formato seguente:
command[<command_name>]=<command_line>
La linea di comando per ogni plugin utilizzato verrà mostrata e descritta nel successivo
capitolo.
Come si è visto, molte delle opzioni del file nrpe.cfg sono ignorate in quanto l'addon
nrpe è stato configurato in modo da girare sotto il demone xinetd.
In questo caso è necessario dare uno sguardo al contenuto del file (figura 16). Come si
può intuire molte delle opzioni che troviamo qui sono le stesse del file nrpe.cfg, le
stesse opzioni che in quel file vengono ignorate.
Di default questo file è disabilitato, quindi per abilitarlo si deve settare la relativa voce
a yes. La voce only_from indica l'indirizzo del server di monitoraggio.
Il servizio, come possiamo notare dalla prima voce, prende il nome di nrpe, stesso
nome che è stato dato al servizio nel file etc/services.
Pagina 47 di 148
Si è visto come avviare NRPE sotto il demone xinetd. Nel caso si voglia invece
avviarlo in modalità standalone è sufficiente andare nella sottocartella sbin ed eseguire
il seguente comando:
# nrpe – c /etc/nagios/nrpe.cfg -d
Per avviarlo automaticamente al boot del sistema invece, si devono aggiungere le
seguenti righe nel file /etc/rc.local:
if [ -x /usr/local/nagios/sbin/nrpe ]; then
echo -n ' nrpe'
/usr/local/nagios/sbin/nrpe -c /etc/nagios/nrpe.cfg -d
fi
4.2. Descrizione dei plugin
Nel precedente capitolo è stata vista la forma della definizione di un comando.
Se per esempio i plugin stessero nella cartella /usr/lib64/nagios/plugins/ la linea di un
comando avrebbe la seguente definizione:
command[nome_comando_plugin]=/usr/lib64/nagios/plugins/script
I vari plugin utilizzati, quelli che nella linea di comando precedente sono stati
generalizzati con il nome script, sono da distinguere in 2 tipologie.
La prima tipologia è composta dai plugin base di NAGIOS, quelli cioè scaricati e
scompattati precedentemente. La seconda tipologia invece comprende tutti gli script
esterni, creati da terzi. Molti di questi sono fatti dal gruppo ATLASItalia e sono
scaricabili dal relativo sito web.
Pagina 48 di 148
Non tutti i plugin base installati con NAGIOS sono stati utilizzati in questo lavoro. Per
completezza però vengono ugualmente spiegati nel caso si debba utilizzarli. Di seguito
vengono descritti brevemente tutti quelli di base, per maggiori informazioni si può
consultare il man. I plugin effettivamente utilizzati invece verranno spiegati
dettagliatamente nel prossimo capitolo.
I plugin vengono scritti nella forma “/nome_plugin”, cioè come compaiono nel file
nrpe.cfg nella definizione dei comandi (dopo il relativo percorso). Gli stessi plugin
possono ovviamente essere eseguiti da linea di comando come eseguibili, quindi nella
forma: “./nome_plugin”.
•
/check_apt
È utilizzabile nei sistemi che usano apt-get come software per la gestione dei
pacchetti e controlla se sono presenti degli aggiornamenti software. Nel caso si
usino le opzioni di default non è necessario avere i privilegi di root. Si può
decidere se fare l'update o l'upgrade, se filtrare la ricerca per una determinata
stringa o se fare l'avanzamento di versione
•
/check_breeze
Controlla la potenza del segnale di apparecchi wireless di tipo breezecom.
•
/check_by_ssh
Utilizza SSH per eseguire un comando su un host remoto. È necessario
specificare il nome del host e il nome del comando da eseguire. Si può
specificare il protocollo da utilizzare, se utilizzare un ipv4 o un ipv6 oppure
specificare l'username per il login sul host remoto. Utile per installare i plugin
su macchine remote controllando tutto da un server di monitoraggio.
•
/check_clamd
Controlla le connessioni CLAMD, quindi di un server clamd, specificando un
Pagina 49 di 148
host oppure un socket. Come nel caso precedente si può specificare se utilizzare
ipv4 o ipv6. Opzionalmente si può utilizzare la connessione SSL.
•
/check_cluster
Controlla lo stato dei cluster per un servizio o per un host specificando le soglie
di warning e critical per un certo numero di host o servizi.
•
/check_dhcp
Controlla la presenza del server DHCP su una rete. Si può specificare l'indirizzo
IP del server.
•
/check_dig
Controlla il servizio DNS di un host specificato utilizzando il comando dig. Si
possono specificare le soglie di warning e critical su determinati tempi di
risposta oppure controllare la correttezza dell'output.
•
/check_disk_smb
Controlla lo spazio di condivisione del protocollo SMB utilizzato per la
condivisione di risorse e file.
•
/check_dns
Utilizza, a differenza di dig, nslookup per ottenere l'indirizzo IP di un dato host
o dominio. Si può specificare facoltativamente un server DNS da utilizzare. Di
default viene utilizzato il server specificato in /etc/resolv.conf.
•
/check_dummy
Ritorna semplicemente lo stato specificato a riga di comando.
•
/check_file_age
Controlla che un file non sia vuoto ed effettua controlli sulla data di ultimo
accesso o modifica specificando un periodo di tempo.
•
/check_flexlm
Pagina 50 di 148
Controlla la presenza del gestore delle licenze flexlm.
•
/check_fping
Controllo di un host con il comando fping.
•
/check_ftp
Controlla una connessione FTP con un host o socket specificato. Si può fare
opzionalmente anche un controllo sulla correttezza dell'output.
•
/check_game
Controlla un game server con il comando qstat
•
/check_hpjd
Controlla lo stato di una stampante HP JetDirect. Nella macchina sulla quale
gira il plugin deve essere installato Net-snmp
•
/check_http
Controlla il servizio HTTP su un host specificato. Può controllare anche tempi
di connessione e certificati scaduti.
•
/check_icmp
Effettua dei controlli sul protocollo ICMP, utilizzato per trasmettere
informazioni riguardati malfunzionamenti dei componenti di una rete.
•
/check_ide_smart
Controlla, utilizzando l'interfaccia SMART, lo stato di un hard disk di tipo ide.
•
/check_ifoperstatus
Controlla lo stato di una determinata interfaccia di rete, di un determinato host,
utilizzano snmp.
•
/check_ifstatus
Controlla, a differenza del precedente, lo stato di tutte le interfacce.
Pagina 51 di 148
•
/check_imap
Controlla le connessioni IMAP di un host o socket specificato ed eventualmente
si autentica.
•
/check_ircd
Controlla un IRC Server
•
/check_jabber
Controlla una connessione JABBER su un host o socket specificato.
•
/check_ldap e /check_ldaps
Controllano un server LDAP
•
/check_log
Controlla un file di log su un determinato percorso.
•
/check_mailq
Controlla la lunghezza della coda delle email.
•
/check_mrtg
Controlla nel log file MRTG il valore medio o il valore massimo di una delle
variabili memorizzate al suo interno.
•
/check_mrtgtraf
Controlla il transfer rate in entrata e in uscita da un router o uno switch
memorizzato in un file di log MRTG. Se il nuovo valore è più vecchio di
“expire minutes” allora viene ritornato uno stato di warning. Se sia il traffico in
entrata che in uscita eccede le relative soglie allora viene ritornato uno stato di
critical.
•
/check_mysql
Controlla la connessione di un server MySQL
Pagina 52 di 148
•
/check_mysql_query
Controlla la connessione di un server MySQL con l'ausilio dei risultati di una
query.
•
/check_nagios
Controlla lo stato del processo NAGIOS sulla macchina locale. Si assicura che
il file di log non sia più vecchio di quello specificato nell'opzione che specifica
la scadenza in minuti. Fa anche uno controllo sulla tabella dei processi con un
confronto con gli argomenti dei comandi.
•
/check_nntp e /check_nntps
Controllano la connessione, rispettivamente NNTP e NNTPS per un
determinato host o socket.
•
/check_nrpe
Utilizzato per controllare l'installazione dell'addon NRPE e per eseguire i
plugin in remoto.
•
/check_nt
Raccoglie dai dal servizio Nsclient che gira su una macchina con windows
server nt/2000/2003/xp.
•
/check_ntp, /check_ntp_peer, /check_ntp_time
Effettuano controlli sul server ntp specificato
•
/check_nwstat
Contatta il MRTGEXT NLM che gira su un server Novel per ottenere varie
informazioni.
•
/check_oracle
Effettua l'autenticazione su un server Oracle.
Pagina 53 di 148
•
/check_overcr
Contatta il demone Over-CR, che gira su un server remoto unix, per ottenere le
informazioni richieste.
•
/check_pgsql
Contatta un server PostgreSQL per vedere se accetta connessioni, prova
l'autenticazione e le query.
•
/check_ping
Usa il ping per controllare statistiche sulla connessione di un host remoto.
•
/check_pop
Controlla la connessione POP specificando un host o un socket.
•
/check_procs
Controlla tutti i processi e genera stati di warning e critical se le metriche
specificate superano le soglie richieste.
•
/check_radius
Controlla se il server radius accetta connessioni.
•
/check_real
Controlla il servizio REAL su un host specificato.
•
/check_rpc
Controlla se c'è un servizio RPC su un server remoto.
•
/check_sensors
Utilizzando i sensori lm-sensors controlla lo stato del hardware.
•
/check_simap
Controlla una connessione SIMAP su un host o socket specificato
Pagina 54 di 148
•
/check_ssmtp
Cerca di aprire una connessione SSMTP con un host specificato.
•
/check_swap
Controlla lo spazio swap su un host.
•
/check_tcp
Controlla una connessione TCP su un host o socket specificato
•
/check_time
Controlla l'ora su un host specificato.
•
/check_udp
Controlla la connessione UDP su un host o socket specificato
•
/check_ups
Controlla lo stato degli UPS con i Network UPS Tools
•
/check_users
Controlla il numero di utenti autenticati, in quel momento, nel sistema locale e
genera un errore se il numero degli utenti supera le soglie specificate.
•
/check_wave
Controlla la potenza di un segnale ricevuto.
Questa lista comprende tutti i plugin base che fanno parte del pacchetto Nagios-Plugin.
Non sono stati inseriti quelli effettivamente aggiunti come servizi che verranno invece
descritti dettagliatamente, insieme a tutti gli altri script utilizzati, nel prossimo
capitolo.
Pagina 55 di 148
4.3. Script utilizzati per gli Host
I primi script utilizzati in questo lavoro di tesi, che vengono analizzati, sono quelli che
fanno parte del plugin di base di NAGIOS, in particolare check_disk, check_load e
check_ssh.
Check_disk è un plugin che controlla la quantità di spazio occupata su un disco di un
file system montato e genera degli avvertimenti se lo spazio libero è minore della
soglia specificata.
Questo plugin prende due opzioni obbligatorie che sono le soglie di warning e di
critical.
Per tutti gli host sono state inserite le stesse soglie, rispettivamente 5% e 1%. Finchè lo
spazio libero è superiore al 5% lo stato ritornato dal plugin è OK. Appena scende sotto
il 5% lo stato diventa warning e quando arriva al 1%, cioè quasi tutto il disco è
occupato, lo stato diventa critical.
Se non si inserisce nessuna altra opzione il plugin fa un controllo su tutte le partizioni
disponibili. Questo però può essere un problema in quanto, sul alcuni host, è presente
una partizione opt che è quasi del tutto occupata. Lo spazio libero della partizione opt
è costantemente è al di sotto del 5%, quindi comporterebbe un perenne stato di
Pagina 56 di 148
warning.
Fortunatamente il plugin check_disk permette anche di specificare la partizione sulla
quale effettuare il controllo con l'ausilio dell'opzione “-p”.
Lì dove non c'è stato bisogno di distinguere le partizioni, il comando inserito nel file di
configurazione prende il nome di “check_all_disk” e ha questa forma:
command[check_all_disk]=/usr/lib64/nagios/plugins/check_disk -w 5% -c 1%
Gli host in questione sono tutti gli Storage Element.
Per gli altri host, dove c'era bisogno di non considerare la partizione opt, è stato creato
un comando per ogni partizione.
È possibile vedere le partizioni di una macchina con il comando:
# df
Sui Worker Node sono presenti solo 2 partizioni, una di queste è proprio opt.
Quindi è stato creato un comando di nome “check_disk” che controlla solo l'altra
partizione (/dev/sda1):
command[check_disk]=/usr/lib64/nagios/plugins/check_disk -w 5% -c 1% -p
/dev/sda1
Sui Service Node la situazione invece cambia da host in host. Su atlas-squid, monitor e
t2-hlr-01 è stato utilizzato “check_all_disk”.
Su atlasui01, atlasui02 e atlasce01 invece sono stati usati “check_disk1” e
“check_disk2” per le 2 rispettive partizioni. Di seguito i due comandi per le due
partizioni di atlasce01:
command[check_disk1]=/usr/lib/nagios/plugins/check_disk -w 5% -c 1% -p /dev/sda1
command[check_disk3]=/usr/lib/nagios/plugins/check_disk -w 5% -c 1% -p /dev/sda3
Check_load è un plugin che controlla il carico medio della CPU di un host. Anche in
Pagina 57 di 148
questo caso è necessario specificare delle soglie di warning e critical. Essendo però un
calcolo medio ogni soglia prende non uno ma tre valori che rappresentano
rispettivamente il carico negli ultimi 1, 5 e 15 minuti. La soglia si considera superata
se uno qualunque dei tre valori di carico supera i valori specificati nell'opzione. I
valori vengono calcolati con una media pesata del carico durante il periodo di
riferimento in modo da dare più importanza ai valori più recenti.
Praticamente ogni CPU parte da uno stato di idle, uno stato nel quale non sta
eseguendo nessun processo. In questo stato ha un carico pari a 0. Ogni processo che è
in uno stato di running o di waiting sulla CPU aggiunge al carico un valore di 1.
Spesso si considerano anche processi in attesa sull' I\O e questo comporta ovviamente
un aumento del carico della CPU.
Tutte le macchine in questione hanno 2 o 4 CPU core, quindi si deve ripartire il carico
per ogni CPU dividendo il carico totale per il numero delle stesse. Per questo motivo le
soglie sono state aumentate e moltiplicate per il numero di core.
Per conoscere informazioni riguardanti la CPU del sistema si può eseguire il seguente
comando:
# cat /proc/cpuinfo
Questo script, pur controllando solo il carico della CPU, ha due scopi di utilizzo
fondamentalmente diversi. Ci sono determinate macchine, in particolare i Worker
Node, che devono sempre lavorare, quindi lo scopo di check_load in questo caso è
controllare appunto che stiano lavorando. Uno eventuale stato di warning quindi è da
prendere positivamente. Negli altri casi invece, la funzione di check_load è di
controllare che succeda l'esatto contrario, cioè che le macchine non siano troppo sotto
sforzo e il carico della cpu non sia eccessivamente elevato. In questo caso quindi un
eventuale warning deve essere preso negativamente,
Di seguito la definizione dei comandi del plugin check_load adattate al numero di
CPU core presenti nel sistema:
Pagina 58 di 148
command[check_load]=/usr/lib64/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_load]=/usr/local/nagios/libexec/check_load -w 30,20,10 -c 60,50,40
Check_ssh è un plugin che controlla la connessione SSH (Secure Shell) su una
determinata porta e host. La porta di default sulla quale gira il demone è la 22.
L'unica opzione che deve essere obbligatoriamente specificata è l'host name.
Il plugin viene eseguito da remoto, ma il controllo del SSH deve essere fatto
localmente, quindi come host si inserisce localhost. Un'altra opzione che deve essere
settata è se usare una connessione ipv4 o ipv6. In questo caso si utilizza la prima. Già è
stato detto che la porta di default è la 22, su alcune macchine però il demone è attivo
su una porta diversa, la 5022, quindi si deve utilizzare l'opzione “-p” per specificare
una porta che non si quella di default. La connessione viene provata per 10 secondi
dopo i quali la richiesta scade. Anche questo è un valore di default, si può specificare
un tempo diverso con l'opzione “-t”.
Di seguito la definizione del comando per atlasce01.na.infn.it:
command[check_ssh]=/usr/lib/nagios/plugins/check_ssh -4 -t 10 -p 22 localhost
Oltre a questi plugin sono stati aggiunti anche altri script, scritti in perl, messi a
disposizione da ATLASItalia: check_memory, check_nfs_stale. check_df, check_pbs,
check_cert, check_pbs_all, check_0queue. Per far funzionare questi script in perl, oltre
ad aver installato sul sistema il perl c'è bisogno di un particolare modulo di nagios
relativo al perl. Infatti già provando gli script in perl senza nrpe, se non è presente
questo modulo, viene restituito un errore del seguente tipo:
Can't locate Nagios/Plugin.pm in @INC (@INC contains: ...) at ./check_memory.pl
line 46.
BEGIN failed--compilation aborted at ./check_memory.pl line 46.
Pagina 59 di 148
Si può installare il modulo mancante in due modi. Il primo modo è direttamente
tramite il perl, eseguendo questo comando:
# perl -MCPAN -e 'install Nagios::Plugin'
L'altro modo è installare il pacchetto tramite il gestore di pacchetti della distribuzione
utilizzata (in questo caso yum). Quindi, se presente nei repository, si può fare:
# yum install perl-Nagios-Plugin
Check_memory è uno script che controlla la quantità di memoria centrale libera.
Prende come valori 2 soglie, rispettivamente per il warning e per il critical. I valori
delle soglie devono essere in percentuale. Sono stati inserite le stesse soglie utilizzate
per il plugin check_disk, cioè 5% per il warning e 1% per il critical.
La definizione del comando è la stessa per tutti gli host, prendiamo come esempio
quella di atlasce01.na.infn.it:
command[check_memory]=/usr/lib/nagios/plugins/check_memory.pl -w 5% -c 1%
Check_nfs_stale è uno script che controlla presenza, ed eventualmente cerca di
risolvere, l'errore “NFS: Stale file handle” sulle macchine che montano l'area software
via NFS. Lo script ha bisogno dei permessi di scrittura sui file temporanei $temp_file
per montare e smontare i comandi senza la richiesta della password. Questo script, per
il momento, non è stato aggiunto come comando e quindi neanche come servizio.
Restituisce critical se il problema NFS è stato trovato e lo script non è riuscito a
risolverlo, warning se è stato trovato il problema ma lo script lo ha risolto e OK nel
caso in cui non sia stato trovato.
Check_df è uno script che controlla, tramite il comando df, se il file system passato
come parametro è montato correttamente. L'unico parametro obbligatorio da
specificare ovviamente è il nome del file system da controllare. Anche questo script,
Pagina 60 di 148
come il precedente, non è stato aggiunto temporaneamente né ai comandi né ai servizi.
Ritorna OK se il path passato è stato trovato, critical in tutti gli altri casi.
Check_pbs è uno script che controlla le code con il comando “qstat -q”. Esegue
controllo su soft limit ed hard limit di tutte le code ed esegue un controllo sulla cosa
cert che non ha soft ed hard limit definiti in maui.cfg. Prende due parametri opzionali,
il percorso del file maui.cfg e il percorso dell'output. Un parametro interno invece, di
nome max_runnable_job, deve essere settato con il numero massimo di job che
possono essere eseguiti contemporaneamente. Questo script è usato sul CE, di seguito
la definizione del comando:
command[check_pbs]=/usr/lib/nagios/plugins/check_pbs.pl
Questo script ha bisogno di uno scheduler di cluster per funzionare, in particolare del
Maui. I controlli che fa sono i seguenti:
•
Controllo sui soft limit: controlla le code con i job in coda e i job che stanno
girando al di sotto del soft limit e che il numero totale di job sul CE al di sotto
del proprio limiti.
•
Controllo sugli hard limit: controlla le code con i job in coda e i job che stanno
girando al di sotto del hard limit e che il numero totale di job sul CE al di sotto
del proprio limiti. Questo controllo è effettuato solo se il precedente controllo
non ha trovato nessuna coda che rispecchia le sue condizioni, quindi si può
assumere che tutte le code hanno un numero di job che stanno girando
maggiore del soft limit.
•
Controllo della coda cert: controlla se la coda cert ha dei job in coda e che il
numero totale di job che stanno girando sul CE è minore del proprio limite.
Questo controllo deve essere fatto separatamente dagli altri due in quanto la
coda cert non ha soft limit e hard limit definiti in maui.cfg,. In ogni caso,
commentando determinate righe che si riferiscono al cert, nel file di
Pagina 61 di 148
configurazione, si può far in modo che anche questa coda abbia i soft e hard
limit e venga trattata come tutte le altre.
I primi due controlli sono mirati a controllare se il sistema di code PBS è
sottoutilizzato. Per esempio se ci sono dei job in coda che per qualche motivo non
stanno girando.
Il controllo numero 3 è uguale ai precedenti solo che è per la coda cert.
Questo script ritorna critical se almeno uno dei 3 controlli è verificato, altrimenti
ritorna lo stato OK.
Check_cert è uno script che controlla se la coda cert ha dei job in coda ma nessuno di
questi sta girando, questo indipendentemente dal numero di job totali, parametro che
invece viene considerato nello script check_pbs. Questo script è utile quando si vuole
essere certi che la coda cert giri sempre. L'unico parametro che prende, per'altro
opzionale, è il nome della coda cert. Anche questo script è utilizzato sul CE, di seguito
la definizione del comando:
command[check_cert]=/usr/lib/nagios/plugins/check_cert.pl
Ritorna lo stato di critical se uno dei controllo si verifica, in tutti gli altri casi invece
Check_pbs_all è uno script che esegue contemporaneamente check_pbs e check_cert.
Questo script può essere usato nel caso non si abbia la necessità di gestire
separatamente i due script, per esempio se non si ha la necessità di specificare un
tempo di timeout diverso. Vediamo sempre la definizione del comando sul CE:
command[check_pbs_all]=/usr/lib/nagios/plugins/check_pbs_all.pl
Ritorna lo stato di critical se uno dei controllo si verifica, in tutti gli altri casi invece
Pagina 62 di 148
Check_0queue è l'ultimo script rimasto, lasciato per ultimo in quanto è l'unico di
questi a non essere scritto in perl, ma è uno script shell. Controlla semplicemente se
sulla coda passata come parametro sono presenti o meno dei job in coda. Utile quando
si vuole essere certi che la coda abbia sempre qualche job che sta girando. E' usata per
la coda atlas. Anche questo script utilizza il comando “qstat -q”. Di seguito la
definizione del comando sul CE:
command[check_0queue]=/usr/lib/nagios/plugins/check_0queue atlas
Ritorna lo stato OK se la coda specificata è abilitata e ci sono dei job in coda.
Ritorna lo stato di warning se la coda specificata è disabiltiata a prescindere dal
numero di job in coda.
Ritorna lo stato critical se la coda specificata è abilitata e non ci sono job in coda.
4.4. Il protocollo SNMP
Non tutti i nodi della rete sono macchine, con un sistema operativo che gestisce le
risorse. Senza un sistema operativo non si può ovviamente utilizzare l'addon nrpe per
controllare le risorse locali di un nodo remoto. In questi casi si può usare per il
monitoraggio il protocollo SNMP (Simple Network Managment Protocol ), usato di
solito sulle reti TCP/IP, un protocollo utilizzato per la gestione di infrastrutture di rete.
SNMP permette il monitoraggio e il controllo di dispositivi di rete quali Router,
Switch o Hub, permettendo di conoscere informazioni di tipo prestazionali o sullo
stato del sistema.
Un framework SNMP è composto da un sistema gestito (managed object), un agente di
gestione (management agent) e un sistema di gestione (manager).
Un sistema gestito, come un generico nodo o uno switch per esempio, ospita un agente
di gestione ed un certo numero di subagent. L'agente di gestione funge da
intermediario tra il sistema di gestione e i subagent. Quando un sistema di gestione
Pagina 63 di 148
interroga l'agente di gestione, questo invia le informazioni richieste sul dispositivo del
quale si occupa.
Ogni subagent prende le decisioni di gestione per quanto concerne nei propri compiti,
in un determinato sottosistema o aspetto del sistema.
In sistemi con una gestione più semplice, l'agente di gestione e i sottoagenti possono
costituire un'unica struttura, chiamata semplicemente agente, in grado di dialogare con
il sistema di gestione e prendere decisioni.
Di solito gli agenti, in un dispositivo di rete, sono implementati proprio nel firmware
del dispositivo oppure, nel caso dei server, all'interno di servizi software.
SNMP utilizza una chiara separazione tra il protocollo di gestione e la struttura
dell'oggetto gestito. In questa architettura, per ogni sottosistema, è definito un database
di nome MIB (Management Information Base), gestito dal corrispondente subagent il
quale rappresenta lo stato del sottosistema gestito, limitato ai soli aspetti dei quali si
vuole consentire la gestione.
Gli oggetti gestiti dagli agent, quindi tutti gli attributi che si possono monitorare, sono
contenuti in questa MIB, secondo la struttura definita nella SMI (Structure
Management Information).
Il MIB ha una struttura ad albero ed ogni oggetto è identificato all'interno di questa
struttura tramite un OID (Object Identification). Un oggetto ha anche una etichetta
associata, quindi può essere identificato o tramite il suo ID o tramite la sua etichetta.
Ogni modifica a questa MIB causa un un cambiamento dello stato del corrispondente
sistema che rappresenta. Questa è una proprietà delle MIB che viene garantita da un
subagent.
Si accede alla MIB tramite un'interfaccia messa a disposizione del sistema di gestione.
Pagina 64 di 148
Ogni MIB, cambia nei propri contenuti, ma mantiene la stessa struttura generale e gli
stessi meccanismi di accesso ai dati, in lettura e scrittura, da parte del sistema di
gestione.
Sulle macchine da monitorare è già installato, tramite il pacchetto snmpd, il demone
SNMP.
SNMP utilizza come protocollo di trasmissione UDP in modo da ottenere migliori
performance e minore overhead della rete. In particolare viene utilizzata la porta UDP
161 per le interrogazioni e le risposte, e la porta UDP 162 come destinazione dei
messaggi trap SNMP generate dagli agent SNMP.
Gli apparati di rete gestiti da SNMP sono organizzati in una comunità (community). La
comunità rappresenta un identificativo che permette di garantire la sicurezza delle
interrogazioni SNMP. Un agente SNMP risponde solo alla richieste di informazioni
effettuate da un sistema di gestione appartenente alla stessa comunità.
I nomi di comunità sono formati da 32 caratteri e sono di tipo case sensitive.
Esistono tre tipi di comunità:
monitor, che permette di lavorare in sola lettura, quindi di effettuare solamente
interrogazioni agli agenti (il cui nome di comunità deve corrisponde a quello del
sistema di gestione che ne ha fatto la richiesta). Il control, che permette tramite gli
agenti SNMP di effettuare delle operazioni in lettura/scrittura sul dispositivo, quindi di
variarne delle impostazioni sempre previo controllo di sicurezza. Il trap, che permette
ad un agente di inviare un messaggio trap SNMP al sistema di gestione secondo la
propria configurazione.
Spesso i nomi di community di default predefiniti sono public per le comunità di sola
lettura e write o private per quelle in lettura/scrittura. Ovviamente è bene modificare
queste impostazioni di default per motivi di sicurezza.
Pagina 65 di 148
SNMP utilizza sei tipi di messaggi di base per svolgere il proprio lavoro. Ogni
messaggio è definito in PDU (Protocol Data Unit) separate, e precisamente:
•
GetRequest: è utilizzata per interrogare un MIB su un agent SNMP.
•
GetNextRequest: è utilizzata per leggere in modo sequenziale un MIB.
•
GetBulk: permette di leggere un MIB con un unica richiesta anzichè utilizzare
più messaggi GetNextRequest.
•
SetRequest: modifica il valore all'interno di un MIB acceddibile in
lettura/scrittura.
•
GetResponse: identifica la risposta da parte di un agent SNMP ad
un'interrogazione di una management station.
•
Trap: permette all'agent di inviare un messaggio al verificarsi di un determinato
evento.
Alcune trap sono predefinite:
•
coldStart: generata quando l'agente SNMP si reinizializza e la configurazione è
stata cambiata (Es. reboot del sistema).
•
warmStart: generata quando l'agente SNMP si reinizializza ma senza
cambiamenti nella configurazione.
•
linkDown: generata quando il collegamento con l'agent non funziona
correttamente.
•
linkUp: generata quando il collegamento con l'agent viene ripristinato.
•
authenticationFailure: generata da un'autenticazione con l'agent non andata a
buon fine (Es. nome di comunità errato).
•
egpNeighborLoss: generata da problemi di EGP (Exterior Gateway Protocol utilizzato dai router).
Pagina 66 di 148
•
enterpriseSpecific: evento definito dal produttore del device.
La SMI (Structure Mangement Information) definisce in modo standard come devono
essere strutturate le informazioni e la loro gerarchia per essere inserite nel database
MIB e quindi gestite da una manager SNMP.
La gerarchia degli oggetti, è ad albero:
-----------------[root]
[ccit(0)][iso(1)][joint-iso-ccitt(2)]
----------------[org(3)]
----------------[dod(6)]
----------------[internet(1)]
[directory(1)][management(2)][experimental(3)][private(4)]
-----------[mib(II)][enterprise(1)]
[System(1)][Interfaces(2)][Address Translation(3)][Ip(4)][Icmp(5)][Tcp(6)][Udp(7)]
[Egp(8)][Snmp(9)]
Ogni oggetto della gerarchia viene identificato in modo univoco, attraverso il suo
percorso nell'albero, la variabile Hostname per esempio è identificata da:
iso.org.dod.internet.management.mib.system.sysdescr oppure 1.3.6.1.2.1.1.1.
Gli oggetti sono definiti tramite la sinstassi ASN.1 (Abstract Syntax Notation One), la
quale permette di non avere ambiguità tra funzioni e proprietà dell'oggetto definito.
La management Information Base, è una base di dati contenente tutte le informazioni
gestite dall'agent SNMP che è in funzione sulla device monitorata. Gli oggetti
all'interno di una MIB vengono definiti in base alle strutture SMI. Attualmente lo
standard utilizzato è la MIB-II.
All'interno di ogni MIB gli oggetti sono suddivisi in categorie, in particolare:
•
System: contiene informazioni di carattere generale sul device di rete.
Pagina 67 di 148
•
Interfaces: contiene le informazioni relative alle interfacce di rete.
•
Address Translation: contiene informazioni relative alla conversioni degli
indirizzi (Es. da logico a fisico), esiste per compatibilà con MIB-I.
•
Ip: contiene informazioni relative al protocollo IP.
•
Icmp: contiene informazioni relative al protocollo ICMP.
•
Tcp: contiene informazioni relative al protocollo TCP. Gli oggetti di questo
gruppo esistono solo per la durate della sessione TCP.
•
Udp: contiene informazioni relative al protocollo UDP.
•
Egp: contiene informazioni relative al protocollo EGP (protocollo utilizzato da
un router per scambiare informazioni tra Autonomous System).
•
Transmission: sperimentale, contiene informazione sui mezzi trasmissione
utilizzato da ogni interfaccia di rete.
•
Snmp: contiene informazioni relative al protocollo SNMP.
4.5. Script per UPS, Switch e CMC
Tutti gli script che seguiranno fanno uso del SNMP. Questi script, considerando la loro
natura, sono presenti solo sul server e non si deve fare alcun tipo di configurazione,
ma possono essere utilizzati semplicemente eseguendo il plugin dal server e
specificando il dns dell'apparato:
•
Water Temperature: Si utilizza il plugin check_snmp per controllare la
temperatura dell'acqua dell'impianto di raffreddamento, tramite i CMC. Tra i
vari parametri da passare ci sono le soglie di warning e critical, il dns del CMC
e l'unità di misura della temperatura. Il comando da lanciare dal server è il
seguente:
check_snmp -H cmc.na.infn.it -C public -o .1.3.6.1.4.1.2606.4.2.3.5.2.1.5.1 -w
Pagina 68 di 148
40 -c 60 -l 'Temperature' -u '°C'
•
Temperature: Si utilizza il plugin check_snmp per controllare la temperatura
dell'ambiente all'interno dei rack, sempre tramite i CMC. I parametri da passare
sono gli stessi del precedente script.
/check_snmp -H cmc.na.infn.it -C public -o .1.3.6.1.4.1.2606.4.2.3.5.2.1.5.1 -w
35 -c 60 -l 'Temperature' -u '°C'
•
Fan Speed: Si utilizza uno script denominato check_snmp_fanspeed per
controllare la velocità delle ventole. Anche in questo caso si utilizzano i CMC e
si inseriscono soglie di warning o critical che si riferiscono alla velocità.
/check_snmp_fanspeed.sh cmc.na.infn.it
•
Uptime: Tramite il plugin check_snmp si controlla da quanto tempo è up
l'apparato. Questo script può essere utilizzato sia per i CMC che per i Switch e
UPS. La definizione del comando è la seguente:
check_snmp cmc.na.infn.it -C public -o sysUpTime.0
•
Traffic: Uno dei parametri più importanti che interessano degli Switch, cioè la
percentuale di banda utilizzata. Si utilizza uno script chiamato traffico_link:
/traffico_link.sh switch.na.infn.it
•
Descrption: Tramite il plugin check_snmp, per tutti gli apparati, è possibile
ottenere come informazione la descrizione dell'apparato. La definizione del
comando è la seguente:
/check_snmp switch.na.infn.it -C public -o sysDescr.0
•
UPS Charge: tramite lo script check_snmp_ups_charge si può controllare la
carica rimanente di un UPS:
/check_snmp -H upsmon.na.infn.it -o UPSMIB::upsEstimatedChargeRemaining.0 -C !n0npublic -w 80:50 -c 49:0
Pagina 69 di 148
•
UPS Autonomy: Tramite lo script check_snmp si può conoscere qual'è il tempo
rimanente della carica della batteria prima che si esaurisca. Anche questo viene
utilizzato per gli UPS e la definizione del comando è:
/check_snmp -H upsmon.na.infn.it -o UPSMIB::upsEstimatedChargeRemaining.0 -C !n0npublic -w 80:50 -c 49:0
•
UPS Status: Questo script chiamato check_ups_status, che controlla lo stato
degli ups, è definito come segue:
/check_ups_status.pl -H upsmon.na.infn.it -C !n0npublic
4.6. Considerazioni
In questi capitoli si è visto come installare il software di monitoraggio NAGIOS sul
server, l'addon NRPE sugli host per il monitoraggio, da remoto, delle risorse locali e
come configurare i plugin sulle varie macchine.
I plugin eseguiti tramite NRPE possono essere testati prima localmente, mettendo
“localhost” come indirizzo del server, poi da remoto, eseguendoli direttamente dal
server tier2-nagios. Tutti gli accessi remoti alle macchine sono stati fatti con SSH,
quasi sempre sulla porta 22.
Per accedere ad una macchina tramite ssh si può eseguire il seguente comando:
# ssh [email protected]
Pagina 70 di 148
Per accedere viene chiesta anche la password dell'username specificato.
L'installazione e la configurazione di queste componenti è stata fatta prima
manualmente, poi automatizzata il più possibile.
L'applicazione NAGIOS è stata installata dal cd con il FAN, che automaticamente
installa anche Centreon e Nagvis, che verranno visti in seguito. L'installazione del
NRPE su tutte le macchine invece è stata fatta tramite i pacchetti rpm aggiornando i
repository. La configurazione dei file del NRPE è stata fatta prima semi-automatica,
con l'utilizzo di una macchina lxlupo per copiare un file di configurazione, di una
macchina configurata correttamente, su tutte le altre macchine non ancora configurate.
Successivamente è stata automatizzata anche questa procedura in modo che, quando è
installato NRPE su una macchina, questa sia già configurata.
I repository sono stati aggiornati su molte macchine in modo da includere anche il
perl-Nagios-Plugin, che prima non era presente, necessario per il funzionamento degli
script in perl.
Questo lavoro di tesi, come già accennato precedentemente, è stato fatto su un sistema
di monitoraggio NAGIOS già esistente. Per provare prima in locale la configurazione
NAGIOS-NRPE è stato necessario installare localmente un'altra copia di NAGIOS.
Localmente si dovevano provare anche gli script della macchina CE, prima di caricarli
con il file di configurazione su questa macchina. La macchina CE è adibita al controllo
delle code e prende il nome di atlasce01.na.infn.it . Per provare quindi gli script
relativi alle code devono essere presenti uno scheduler di cluster e un gestore delle
risorse. Entrambi ovviamente sono già presenti su atlasce01. Per provare gli script
localmente si devono installare anche sulla macchina locale. Sono stati scelti, come
scheduler il Maui e come gestore delle risorse il Torque compatibile con Maui.
Pagina 71 di 148
4.7. Scheduler e Resource Manager
Il Maui è uno scheduler di cluster avanzato, usato per migliorare il controllo e
l'efficienza dei cluster e delle risorse dei supercomputer.
Questa mini-guida evidenzia i passi chiave e le considerazioni coinvolte nell'
installazione, la costruzione, la configurazione e il testing del Maui su nuovi sistemi.
Il primo passo è la comprensione di cos'è il Maui.
Il Maui è uno scheduler, prende decisioni riguardo a dove, quando e come far girare i
job tramite un insieme di politiche configurabili, priorità e limiti.
Prende le sue decisioni interrogando e controllando un sistema di gestione delle risorse
come OpenPBS, PBSPro, Torque, LoadLeveler, SGE, ect.
Per far girare il Maui sono richiesti tra i 20 e i 50 mb di RAM e almeno 20 MB di
spazio sul disco per tenere sorgenti, file binari, statistiche e log file.
Richiede che un manager di risorse sia installato ed operativo.
Maui deve girare sotto un user id con accesso da amministratore al manager delle
risorse che viene usato.
L'installazione e configurazione del Maui deve essere condotta sotto questo user id.
Prima di tutto devono essere determinate l'host e la home directory che ospiteranno il
Maui.
Spesso l'host sarà lo stesso della macchina sulla quale gira il manager delle risorse.
La Home directory invece sarà la locazione standard local, per esempio /usr/local/src.
Per prima cosa è necessario andare sul sito http://www.clusterresources.com.
Qui sarà possibile scaricare il file tar solo dopo aver effettuato la registrazione.
Una volta scaricato il file maui-3.3.tar.gz sul desktop spostarlo in una cartella
appropriata:
# mv /root/Desktop/maui-3.3.tar.gz /usr/local/src/
Estrarre ed entrare nella cartella estratta:
# gtar -xzvf maui-3.3.tar.gz
Pagina 72 di 148
# cd maui-3.3
A questo punto, se si lancia ./configure si vede che l'operazione non va a buon fine,
con il seguente errore:
configure: WARNING: Resource Manager not specified - attempting build with pbs
configure: error: can't find pbs-config or libpbs.a
Come si evince dall'errore manca proprio un Resorce Manager.
È stato scelto e installato TORQUE come gestore delle risorse affiancato dal Maui
come scheduler.
TORQUE è un manager delle risorse anche conosciuto con il suo nome storico: PBS
(Portable Batch System).
Scaricare Torque:
# cd /usr/local/src
# wget http://www.clusterresources.com/downloads/torque/torque-2.5.1.tar.gz
Estrarre ed entrare nella cartella creata:
# tar -xzvf torque-2.5.1.tar.gz
# cd torque-2.5.1
Compilare e Inizializzare:
# ./configure
# make
# make install
TORQUE richiede solo pochi passi per inizializzare, configurare e far girare il sistema.
Per prima cosa il server ha bisogno di conoscere di quali computer node può fidarsi.
Pagina 73 di 148
In secondo luogo il server deve essere inizializzato e configurato.
Infine ogni computer node ha bisogno di sapere dove è posizionato il pbs_server.
Per configurare il pbs_server lanciare il comando torque.setup <USER>, dove user è
l'utente che sarà l'admin di TORQUE:
# ./torque.setup root
Una alternativa è fare:
# pbs_server -t create
Se non si è specificato durante il configure una cartella diversa, il pbs_server e il
pbs_mom vengono messi nella cartella /usr/local/sbin
Per vedere la configurazione lanciare il comando:
# qmgr -c 'p s'
l'output del comando è è il seguente:
#
# Set server attributes.
#
set server acl_hosts = pc10.scope.unina.it
set server log_events = 511
set server mail_from = adm
set server scheduler_iteration = 600
set server node_check_rate = 150
set server tcp_timeout = 6
A questo punto l'installazione e la configurazione di TORQUE è terminata. Possiamo
utilizzare il comando “qstat -q” e controllare che ci sia una coda fittizia, creata da
Pagina 74 di 148
torque.setup, chiamata batch. Possiamo proseguire anche la configurazione del Maui
da dove era stata interrotta e provare gli script, alcuni dei quali richiedono proprio la
posizione del file maui.cfg.
4.8. Problematiche
Durante questa parziale fase del lavoro ho riscontrato e risolto alcune problematiche.
Una prima problematica riguarda il file di log /var/log/messages.
Ogni volta che viene fatta una interrogazione al demone nrpe, da parte del server, 2
righe di codice vengono scritte nel file di log del sistema, in particolare le seguenti
righe:
Nov 3 10:58:15 pc01 xinetd[2940]: START: nrpe pid=25903 from=172.xxx.xxx.xxx
Nov 3 10:58:16 pc01 xinetd[2940]: EXIT: nrpe status=0 pid=25903 duration=1
Su una macchina vengono eseguiti mediamente 5 script ogni 5 minuti. Questo
significa 2 righe di file log ogni minuto, 120 righe ogni ora, 2880 righe al giorno nel
file di log.
Questo è un problema sia dal punto di vista dello spazio occupato all'interno del file,
sia dal punto di vista della grandezza del file stesso. Il file ovviamente viene svuotato
periodicamente. Questa situazione quindi, di per se, no sarebbe un problema se non
fosse che il file di log, su alcune macchine, è utilizzato da altre persone per altri scopi.
È necessario quindi spostare i log del demone xinetd da qualche altra parte in modo da
liberare il file di log del sistema. Per fare questo è sufficiente andare nel file di
configurazione di xinetd, xinetd.conf, che si trova nella directory etc.
Alla voce log_type è impostato il valore “SYSLOG daemon info” che fa appunto
copiare il log nel file di sistema. Sostituire il valore come segue:
log_type
= SYSLOG authpriv
Pagina 75 di 148
In questo modo i log di xinetd vengono messi in un file di log diverso, in particolare
“/var/log/secure”. Il problema quindi è stato risolto
Altri problemi che si sono presentati sono emersi quando sono stati provati gli script
che utilizzano SNMP. Provando check_ups_autonomy, tramite check_snmp, usciva il
seguente errore:
External command error: UPS-MIB::upsEstimatedMinutesRemaining.0: Unknown
Object Identifier
Non riusciva quindi ad identificare l'oggetto all'interno della MIB. Questo richiedeva
che i MIB venissero aggiornati. Questo aggiornamento è stato fatto anche per gli altri
apparati che usano SNMP.
Un altro problema è sorto con l'altro script per gli ups, check_ups_charge. In
particolare lanciando questo script viene ritornato l'errore seguente:
Range format incorrect
Dopo alcune ricerche si è ipotizzato che questo errore possa essere dovuto ad un bug
presente in check_snmp nella versione nagios-plugins 1.4.14.
Questa ipotesi è stata fatta in quanto ci sono altri precedenti sui forum di persone che
hanno avuto lo stesso problema e hanno risolto passando ad una versione precedente.
L'ipotesi è avvalorata dal fatto che questo script, su una versione vecchia di FAN,
quindi con una versione vecchia del nagios-plugin, funzionava.
Il problema non è stato risolto, quindi lo script attualmente non funziona. Piuttosto che
fare un downgrade della versione del nagios-plugin, in questi giorni è uscita una nuova
versione: nagios-plugins 1.4.15.
Pagina 76 di 148
Si potrebbe quindi provare ad fare un upgrade per vedere se il problema si risolve.
5. Aggiunta dei servizi con Centreon
Centreon è un tool di monitoraggio che configura e controlla Nagios tramite una
interfaccia web e memorizza l'output dei plugin di Nagios all'interno di un database
MySQL. Questi dati sono utilizzati per mostrare lo stato degli Host e Servizi, proprio
come fa Nagios, e vengono utilizzati per la creazione di grafici.
Centreon, così come Nagios e Nagvis è compreso nel pacchetto di installazione di
FAN. Poiché Centreon è già installato, quindi perfettamente funzionante e integrato
con Nagios, in questo capitolo vengono affrontate solo le funzionalità di Centreon, in
particolare quelle necessarie per aggiungere i servizi sugli host da monitorare in
nagios.
Pagina 77 di 148
L'installazione di Centreon si può raggiungere, tramite interfaccia web e previa
autenticazione, dall'indirizzo:
http://tier2-nagios.na.infn.it/centreon
figura 21 : Home di Centreon con sommario della situazione degli Host e Servizi
Una volta effettuata l'autenticazione si accede alla pagina principale di Centreon. La
prima schermata che si vede è “Tactical Overview”, un sommario con la situazione
generale di tutti gli host e servizi, lo stesso Tactical Overview che si vede in Nagios ma
con una interfaccia nettamente migliore.
5.1. Host e Host Group
Il primo passo nella procedura di configurazione è aggiungere un Host. Per fare questo
andare in:
Configuration → Hosts
Nel menu a tendina sono disponibili tutte le possibili azioni da fare su un determinato
host, come duplicarlo, cancellarlo o disabilitarlo. Quella che interessa però è l'azione
“add” che permette di aggiungere un host. Premendo il tasto “add” si apre la
schermata, con un form da compilare, visualizzata in figura 22.
Pagina 78 di 148
figura 22 : Form per l'aggiunta di un nuovo host
Prendiamo come esempio, di un host da inserire, atlasse04.na.infn.it.
Le informazioni necessarie sono il nome del Host, un alias e il suo indirizzo IP:
Host Name = atlasse04.na.infn.it
Alias = Storage Element 04
IP Address = 90.147.67.14
Altre informazioni non sono necessarie in questo momento in quanto, verranno
aggiunge successivamente, con l'aggiunta di host group, command e service. Quindi si
può già salvare il nuovo Host creato.
Pagina 79 di 148
Aggiungere qui informazioni, come il periodo di controllo, significherebbe fare una
distinzione tra i vari host. Queste informazioni invece sono comuni a tutti gli host che
hanno un particolare servizio e vengono specificate nel template del servizio come si
vedrà più avanti.
Gli stessi servizi non vengono associati a singoli host ma a gruppi di host della stessa
tipologia. A questo scopo tutti gli host sono stati raggruppati in 2 modi: per il rack di
appartenenza e per la funzionalità. Per quelli raggruppati per funzionalità è stata fatta
una ulteriore distinzione per la loro locazione (Scope o Atlas).
Per creare un Host Group, sempre nella sezione “Hosts”, selezionare “Hosts Group”
nel menu a sinistra (che visualizza la lista di tutti gli Host Group) e selezionare “add”.
Si aprirà un form come quello visibile nella seguente figura:
figura 23 : Form per l'aggiunta di un nuovo host group
Pagina 80 di 148
Supponiamo di voler creare un gruppo nel quale sono contenuti i CMC di Atlas, allora
si inserisce come nome del gruppo e alias “CMC_atlas”.
Più sotto, dove compare la lista di tutti gli host, si deve specificare quali host fanno
parte di questo gruppo, selezionarli e premere il pulsante “Add”
Quindi selezionare cmcatlas1, cmcatlas2, cmcatlas3, cmcatlas4 e salvare il gruppo.
In questo capitolo non vengono descritti tutti gli host e host group creati in quanto
saranno visibili chiaramente nelle mappe più in avanti.
5.2. Aggiungere un comando
Una volta aggiunti tutti gli Host ed raggruppati in Host Group, si devono aggiungere i
comandi relativi all'esecuzione dei plugin.
Nella sezione “Commands” si può visualizzare la lista di tutti i comandi già aggiunti
ed aggiungerne altri con “add”.
Il form per l'aggiunta di un nuovo comando è visibile in figura 24:
figura 24 : Form per l'aggiunta di un nuovo comando
Pagina 81 di 148
Per creare il comando per l'esecuzione dello script check_memory è necessario inserire
un nome per il comando e la linea del comando da eseguire.
Come nome del comando si può inserire qualcosa che risalti l'utilizzo di nrpe, per
esempio check_memory_nrpe. In questo modo, quando si visualizza la lista dei
comandi, tramite il form di ricerca, si possono filtrare i comandi in modo da
visualizzare solo quelli eseguiti tramite NRPE.
La linea di comando invece è quella che è stata eseguita dalla shell del server per
l'esecuzione di un plugin remoto, quindi:
$USER1$/libexec/check_nrpe -H $HOSTADDRESS$ -c check_memory
USER1 e HOSTADDRESS sono due variabili che, di volta in volta, contengono
l'utente che sta eseguendo il comando e l'indirizzo del host remoto, quando si esegue il
comando su un determinato host.
È possibile comporre la linea di comando in modo più rapido e senza errori
aggiungendo direttamente le variabili o lo script, selezionando quello che interessa
aggiungere nei menu a tendina sulla destra.
A questo punto il comando si può anche salvare. È presente però un'altra funzionalità
molto importante che permette di testare il plugin. Subito sotto la linea di comando si
può inserire l'indirizzo di un host e testare il plugin per vedere se funziona. Questa
funzionalità, non presente nelle precedenti versioni di Centreon, è utilissima per capire
se il comando è stato scritto correttamente.
Ad ogni comando corrisponde un plugin da eseguire e corrisponderà un servizio.
Tutti i plugin, che sono stati descritti già precedentemente, vengono richiamati da
“check_nrpe” il quale specifica il nome del Host e il nome del Comando.
La linea di comando, per ogni plugin, deve essere scritta nella stessa forma vista per il
comando check_memory.
Fanno eccezione i comandi per i plugin che utilizzano SNMP. In questo caso non si
Pagina 82 di 148
deve utilizzare check_nrpe, ma check_snmp. Questo comando richiede anche altri
parametri, gli stessi presenti nella descrizione dei relativi plugin nel capitolo 4.
5.3. Creare un servizio
Il passo finale di questa procedura è l'aggiunta di un servizio. Ogni servizio esegue un
determinato comando, di quelli descritti precedentemente.
Prima di creare un servizio si deve creare un template per il servizio. Selezionare
quindi la Tab Services, tra le voci del menu di sinistra c'è anche quella relativa ai
Template. Qui è possibile vedere la lista dei template già creata oppure creare un
nuovo template cliccando su add. Si aprirà un form per la creazione del servizio così
come si può vedere nella figura 25.
figura 25 : Form per l'aggiunta di un nuovo template per i servizi
Pagina 83 di 148
Le prime informazioni necessarie da inserire sono il nome del template e l'alias.
È necessario poi impostare i parametri relativi ai tempi dei controlli. Una impostazione
tipo potrebbe essere:
Check Period = 24x7
Max Check Attempts = 3
Normal Check Interval = 5 * 60 sec
Retry Check Interval = 1 * 60 sec
In questo modo si imposta il controllo per 24 ore, 7 giorni a settimana. Il massimo
numero di tentativo è impostato a 3. Ogni controllo viene fatto ad intervalli di 5 minuti
e in caso di errore viene riprovato dopo 1 minuto.
Nella parte bassa del template si possono attivare anche le notifiche, che vengono
inviate all'amministratore del sistema. Si possono impostare le notifiche per 24 ore, 7
giorni a settimana, proprio come sopra, in modo da renderle attive per tutto il periodo
di controllo. Si deve poi scegliere il motivo per il quale ricevere la notifica, se per un
warning, un critical, un recovery, ect.
Queste sono le impostazioni più importanti per un template. Fatto questo si può
passare alla creazione di un servizio.
I servizi possono essere creati per un determinato Host oppure per un gruppo di Host.
Precedentemente gli Host sono stati raggruppati proprio per questo motivo.
Raggruppare gli Host della stessa tipologia fa in modo che si possa creare un servizio
per quel gruppo di host.
Pagina 84 di 148
A questo scopo andare in “Services by hosts group” per aggiungere un nuovo servizio
su un Host Group. Qui ovviamente sarà visibile la lista di tutti gli Host Group con i
relativi servizi. Tra le varie informazioni consultabili in questa schermata, per ogni
servizio, c'è il periodo di controllo (e di retry), il template utilizzato e lo stato del
servizio, cioè se è abilitato o disabilitato. Da qui è possibile anche disabilitarlo,
disabilitandolo però anche per tutti gli altri host group.
Sempre selezionando “add” si può aggiungere un nuovo servizio. Il form per la
creazione di un nuovo servizio è quello della figura seguente:
figura 26 : Form per l'aggiunta di un nuovo servizio per host group
Pagina 85 di 148
Precedentemente si è visto come aggiungere un comando per il plugin check_memory.
Se si volesse creare un servizio che implementi questo controllo, alla voce “check
command”, selezionare dal menu a tendina lo script check_memory.
Nelle informazioni generali inserire un nome del servizio che ricordi il comando
utilizzato e selezionare il template precedentemente creato.
Le altre informazioni sottostanti possono essere lasciate vuote in quanto sono già
comprese nel template. Nel caso che si specifichi un valore diverso in questi campi
sarà preso in considerazione al posto di quello presente nel template.
Le informazioni di base per il servizio sono state inserite, non resta che specificare gli
host group sul quale renderlo attivo. Per far ciò si deve passare alla tab “relations”. Per
creare il collegamento tra il servizio e il gruppo di host, nella schermata “Linked with
HostGroup” si deve aggiungere il gruppo\i dalla lista di quelli disponibili. Fatto
questo non resta che salvare il servizio creato.
Con la creazione del servizio il processo di configurazione con Centreon è terminato,
non resta che esportare la configurazione per il Nagios.
Per esportare la configurazione e rendere attivi le modifiche andare alla voce “nagios”,
mettere una spunta a “move export file” e “restart nagios”, selezionare come metodo
“reload” e premere sul tasto “export”.
Dopo pochi secondi dovrebbe uscire un riepilogo delle operazioni fatte ed
eventualmente dei warning e critical.
I warning solitamente si riferiscono a degli host che non hanno associato alcun
servizio. Questo host vengono anche specificati. I critical invece se quanto fatto non è
stato fatto correttamente.
Pagina 86 di 148
La verifica delle operazioni fatte può essere visualizzata in Nagios, ma così come in
Nagios può essere vista anche in Centreon in quanto è esso stesso un tool di
monitoraggio. Nel prossimo paragrafo viene illustrata questa funzionalità di
monitoraggio.
5.4. Centreon come Tool di monitoraggio
Una volta esportato il file di configurazione per nagios è possibile monitorare lo stato
dei servizi anche da Centreon. Nell'introduzione di questo capitolo si è visto che, nella
home di Centreon, è visibile la “Tactical Overview” per un sommario sullo stato dei
servizi e degli host. Del resto è la stessa che è visualizzabile da Nagios.
Nel menu principale, subito dopo la voce “Home”, c'è “Monitoring”.
Il monitoraggio è diviso in 3 sezioni: Services, Hosts e Event Log.
Come è intuibile dal nome la prima permette di monitorare tutto quello che riguarda i
Servizi, la seconda quello che riguarda gli Host e l'ultima il log degli eventi.
La sezione Services permette di vedere:
•
Services Problems
Visualizza tutti i servizi che hanno problemi. In particolare per ogni servizio
non funzionante si può vedere l'host sul quale ha un problema, lo stato del
servizio (warning, critical, unknown), la durata del servizio, quando è stato
effettuato l'ultimo controllo, quante volte è stato provato e in fine l'output
dell'errore. Si possono questi servizi per lo stato del servizio visualizzando solo
quelli che hanno un warning, un critical o un unknown. Passando il mouse sul
Pagina 87 di 148
nome del servizio si possono visualizzare informazioni più dettagliate come
quando ci sarà il prossimo controllo oppure la latenza. Si può anche cliccare sul
servizio in modo da vedere la schermata dei dettagli
•
All Services
A differenza del precedente qui vengono visualizzati tutti i servizi. Le
informazioni a disposizione sono le stesse visibili in Services Problems, anche
qui passando il puntatore sopra il nome del servizio si vedono informazioni
dettagliate. L'unico filtraggio che si può fare in questa voce è quello dei servizi
funzionanti. Si possono vedere quindi tutti i servizi che ritornano lo stato OK.
•
Grids
Un elenco di tutti gli host, per ogni host una lista di tutti i servizi attivi, con
relativo colore che indica lo stato del servizio. Anche qui si può cliccare su un
servizio per vederne i dettagli. È possibile filtrare visualizzando solo quelli che
hanno problemi.
•
Overview
Simile a Grids con l'aggiunta di un'unica informazione: Lo stato del Host.
•
Summary
Un elenco di tutti gli host, raggruppati per Host Group. Per ogni host c'è il
numero di servizi che funzionano, il numero di quelli che hanno un warning o il
numero di quelli che hanno un critical. Si possono filtrare vedendo solo quelli
che hanno problemi.
In aggiunta alla versione precedente di Centreon c'è anche una funzionalità che
permette la creazione dei grafici per ogni servizio.
In tutte le voci elencate sopra, di fianco ad ogni servizio, c'è un'icona che rappresenta il
grafico. Si può visualizzare il grafico semplicemente passando con il puntatore sopra
Pagina 88 di 148
l'icona, oppure entrando nei dettagli del servizio selezionando il nome del servizio.
C'è proprio una voce del menu dedicata al visualizzazione dei grafici, chiamata
“Views”.
Qui si possono vedere tutti i grafici specificando un intervallo di due periodi di tempo
(data e ora), oppure si può entrare nello specifico selezionando un determinato Host
Group, Host o Servizio e vedere tutti i grafici. Selezionando un Host Group si vedono
tutti i grafici di tutti i servizi di tutti gli Host di quel gruppo. Selezionando un Host si
vedono tutti i grafici di tutti i servizi di quel Host. Selezionando invece un Servizio si
vede solo il grafico relativo a quel servizio.
figura 27 : grafico per il servizio check_memory su atlasce01
Nella figura precedente si vede il grafico del servizio check_memory attivo sul host
atlasce01. Il grafico fa riferimento ad un periodo di 3 giorni
I grafici generalmente vengono generati in automatico prendendo i parametri di output
dagli script. Non tutti gli script però hanno un grafico. Questo perchè i grafici vengono
costruiti su dei dati ritornati dagli script. Questi dati prendono il nome di perfdata
(performance data).
Se uno script non ha dei perfdata, ma solo uno stato, allora Centreon non ha modo di
costruire un grafico.
Pagina 89 di 148
6.
Creazione delle mappe con Nagvis
Tutto quello che è stato fatto fin'ora permette di visualizzare lo stato dei servizi
all'interno di una tabella che elenca gli stessi e gli host sui quali sono attivi.
Sicuramente quanto fatto è sufficiente ad avere una panoramica generale delle risorse
dei nodi in quanto le informazioni ottenute sono complete ed esaurienti. È anche vero
però che visualizzare le informazioni in questa forma tabellare non è il massimo
dell'efficienza.
Viene in aiuto agli amministratori del sistema un altro addon di Nagios installato, così
come Centreon, nel pacchetto FAN 2.0: Nagvis.
Nagvis è usato per dare una visuale grafica ai dati di Nagios con la possibilità di
aggiungere mappe in formato png.
Su ogni mappa c'è la possibilità di inserire delle “service icon” che fanno riferimento
ad i servizi e cambiano icona e colore a seconda dello stato degli stessi.
Precedentemente tutti gli apparati della rete sono stati raggruppati per tipologia e rack
di appartenenza, per poi essere suddivisi tra quelli che appartengono a SCoPE
Pagina 90 di 148
Datacenter e quelli che appartengono invece a ATLAS Datacenter.
Tutto questo lavoro di raggruppamento è stato fatto principalmente per poter essere
utilizzato in Nagvis.
Si parte da una mappa generale, visibile in figura 28, nella quale sono rappresentati
tutte le tipologie di apparati: Storage Elements, Worker Nodes, Service Nodes, CMC,
Switch, Router e UPS. Per alcuni di essi c'è la distinzione (L1 e L2) tra la locazione
nel datacenter, come spiega la legenda in basso alla mappa.
Per ogni tipologia c'è una icona che si riferisce al gruppo, ai suoi host e ai servizi attivi
su essi.
figura 28 : mappa principale visibile dalla home di tier2.na.infn.it
Questa mappa è visualizzabile dalla home del portale di Liferay, raggiungibile
dall'indirizzo tier2.na.infn.it.
Pagina 91 di 148
L'obbiettivo è quello di visualizzare, da questa mappa, la stato generale dei servizi per
ogni tipologia di apparato, in modo da inquadrare più velocemente il problema che si
presenta.
L'icona verde indica che tutti i servizi relativi a quella tipologia restituiscono uno stato
di OK. L'icona gialla indica che almeno un servizio di quella tipologia restituisce un
warning. L'icona rossa indica che almeno un servizio di quella tipologia restituisce lo
stato critical. L'icone grigia invece indica che almeno un servizio restituisce lo stato
unknown.
Portando il puntatore del mouse su una di queste icone, si visualizza un elenco
(ridotto) degli apparati che fanno parte di quella tipologia, con il relativo stato del host,
stato del servizio e numero dei servizi che sono in quello stato, come si vede in figura
29.
Pagina 92 di 148
figura 29 : mappa principale, sommario servizi sui Service Node
Questa mappa è stata resa anche navigabile. Selezionando infatti una delle icone, si
accede ad una mappa più dettagliata nella quale sono visibili i singoli apparati
all'interno dei rack. Nella figura 30 c'è la mappa dei Service Node.
Quasi tutte le icone visibili nella mappa generale sono navigabili nel dettaglio. Anche
nella legenda sotto a questo riquadro ci sono 2 icone navigabili, che si riferiscono però
a tutti gli apparati del datacenter di SCoPE e di ATLAS. Quindi, in Centreon, sono stati
creati anche questi due gruppi. Non sono navigabili invece le icone degli UPS.
Nella mappa dettagliata ci sono altre icone, questa volta si riferiscono al singolo host.
Passando il mouse su queste icone si vede, in dettaglio, lo stato di tutti i servizi attivi
su quel host più altre informazioni generali sullo stato del host. Nella figura 30 c'è il
dettaglio dei servizi per atlasce01.
Pagina 93 di 148
figura 30 : mappa nel dettaglio dei Service Node
Si può ancora scendere nel dettaglio selezionando il singolo host. In questo caso si
accede direttamente alla Web Management dell'apparato. Si apre in una nuova pagina
la home della web management con la schermata di autenticazione.
Nella figura seguente la Web Management di atlasce01.
Pagina 94 di 148
figura 31 : web management di atlasce01
Queste mappe costituiscono l'obiettivo finale del lavoro di tesi e sono da considerarsi
il risultato finale di tutto il lavoro fatto con NAGIOS, NRPE e Centreon. I precedenti
capitoli infatti descrivono tutto il lavoro che c'è dietro.
Le mappe sono state ottenute con una procedura che viene spiegata dettagliatamente
nei prossimi paragrafi. In questo capitolo vengono illustrate solo alcune mappe allo
scopo di spiegare il risultato ottenuto e i passi necessari per ottenerlo. Tutte le mappe
sono incluse nel capitolo dell'appendice.
Pagina 95 di 148
6.1. Inserire una mappa
Per la creazione di una mappa con Nagvis si deve partire da una base, una immagine
png esterna da importare in Nagvis.
Le immagini delle mappe generali, visualizzabili entrando nel dettaglio dalla legenda
in basso, sono state create per un'altra tesi (Un sistema di monitoraggio per una rete ad
alte prestazioni e ad alte affidabilità). Quindi il lavoro è stato fatto con l'ausilio di
queste mappe. Da queste mappe sono state create infatti quelle specifiche per ogni
tipologia di apparato.
Per importare una mappa in Nagvis è necessario fare 2 operazioni: La prima
operazione è quella di caricare, sul server di tier2-nagios, l'immagine in formato png.
La seconda operazione è invece quella di creare, per ogni immagine, un file di
configurazione omonimo con estensione cfg.
Le immagini png sono tutte della stessa risoluzione (900x704) tranne quella principale
nella home. I file png devono essere caricati su tier2-nagios, nella directory:
/usr/share/nagios/nagvis/nagvis/images/maps/
Inserito questo file png nella directory delle mappe, si deve creare un file di
configurazione nella directory:
/usr/share/nagios/nagvis/etc/maps/
Carichiamo per esempio l'immagine “Tier2_INFN_SN.png” , quella utilizzata per la
mappa della figura 30. Nel percorso per i file di configurazione delle mappe si deve
creare un file “Tier2_INFN_SN.cfg”. Questo file, inizialmente vuoto, deve avere una
struttura iniziale definita così:
define global {
Pagina 96 di 148
allowed_user=EVERYONE
allowed_for_config=EVERYONE
iconset=std_medium
map_image=Tier2_INFN_SN.png
}
Qui si devono specificare gli utenti che possono visualizzare e modificare la mappa, la
grandezza dell'icona e il file png di riferimento.
Sono sufficienti queste poche informazioni per creare una mappa. La mappa
ovviamente è inizialmente vuota e mostra semplicemente l'immagine png.
Per accedere alla mappa tramite Nagvis e modificarla si può andare direttamente
all'indirizzo:
http://tier2-nagios.na.infn.it/nagios/nagvis/wui/
Da qui si può, con il tasto destro del mouse, aprire una delle mappe caricate, per
esempio, Tier2_INFN_SN, della quale è stato creato il file di configurazione
precedentemente.
Pagina 97 di 148
6.2. Editor di mappe
Come si è visto nel paragrafo precedente, per creare una mappa sono sufficienti poche
righe di codice nel suo file di configurazione, per specificare il nome della mappa e il
nome del file png.
Questo file di configurazione però corrisponde a quello di una mappa vuota.
Aggiungendo oggetti sulla mappa, per ogni oggetto, viene creata una nuova struttura
all'interno del file.
Si parla di oggetti da aggiungere alla mappa, definiamo quindi cosa sono questi
oggetti.
Ci sono 3 tipologie di oggetti che si possono aggiungere: icone, line e oggetti speciali.
Per adesso gli oggetti speciali sono solo due: campi di testo e pulsanti di collegamento.
I pulsanti di collegamento possono (e vengono) utilizzati come pulsanti utili per
tornare alla pagina precedente. Questi pulsanti sono stati aggiunti su ogni mappa, di
fianco al titolo in alto, e hanno una forma a freccia, indirizzata verso sinistra, che sta
ad indicare appunto la sua funzionalità.
Nella figura 32 si può vedere come è fatto questo pulsante.
Ogni volta che si aggiunge un oggetto, questo inizialmente prende dimensioni, aspetto
e funzionalità di default. Passando con il mouse sull'oggetto in questione, compare un
menù con un elenco di tutti i parametri modificabili dell'oggetto e con due possibili
opzioni: eliminare l'oggetto e modificarlo. I parametri dipendono dal tipo di oggetto
creato.
Cliccando su modifica si possono ovviamente modificare tutti i parametri e
personalizzare quindi l'oggetto. I parametri già personalizzati sono quelli evidenziati in
nero, sotto la voce “Configured”. Quelli grigi invece hanno i valori di default e si
trovano sotto la voce “Inherited”. Di seguito il menù per il tasto che porta alla pagina
precedente:
Pagina 98 di 148
figura 32 : parametri per gli oggetti
Questo tipo di oggetto è chiamato Shape. Come detto la creazione di questo oggetto
genera una nuova struttura nel file di configurazione, che contiene solo i parametri
Configured. Infatti, sotto quella inizialmente creata per il caricamento della mappa, c'è
quella appena aggiunta:
define shape {
icon=B-dietro.png
x=677
y=5
url=index.php?map=atlas
}
Qui possiamo notare 4 parametri. Il primo è l'immagine png utilizzata per questo
collegamento, immagine aggiunta successivamente quindi non di default.
Il secondo e il terzo parametro indicano la posizione del pulsante sullo schermo.
Pagina 99 di 148
L'ultimo parametro invece il collegamento del pulsante. In questo caso è stata scelta la
mappa principale.
Da questo si può fare una considerazione. Se si può aggiungere un oggetto
graficamente personalizzandolo e si crea così una nuova voce nel file di
configurazione, allora si può anche l'opposto. Si può aggiungere direttamente la voce
nel file di configurazione e vedere così, graficamente l'oggetto creato.
L'altra tipologia di oggetto utilizzata, come si è visto nelle figure 28,29 e 30, sono le
icone. Le icone possono far riferimento ad un Host, Servizio, gruppo di Host, gruppo
di Servizi e Mappa. L'icona di Host, la più usata in questo lavoro, oltre a mostrare le
informazioni generali sullo stato del host, mostra anche un sommario sullo stato dei
servizi ed un elenco con tutti i servizi con relativo stato e output. Icone per host sono
tutte quelle della figura 30, nella quale si vede lo stato dei servizi della macchina
atlasce01.
Nella figura 29 invece si vedono tutte le icone di gruppi di Host.
Anche le due icone della legenda (figura 28) sono riferite a gruppi di host. Le icone
degli UPS sono icone di host. Quella invece in alto è una icona del tipo mappa.
L'unica icona non utilizzata è quella per i singoli servizi.
Si è visto nel dettaglio l'oggetto special di tipo Shape. L'oggetto icon di tipo Host ha
molti parametri in più che possono essere modificati. Nella figura 33 si vedono i
parametri per la Icon Host di atlasce01
Pagina 100 di 148
figura 32 : parametri dell'icona di atlasce01
Vediamo anche cosa viene aggiunto nel file di configurazione:
define host {
url=http://tier2-nagios.na.infn.it/checkaccess.php?address=http://atlasce01.na.infn.it
url_target=_blank
host_name=atlasce01.na.infn.it
x=592
y=320
iconset=std_mini
Pagina 101 di 148
Si può notare che, a differenza del “define shape”, non c'è più l'immagine png da usare
per l'oggetto, in quanto le icone hanno immagini prestabilite che cambiano a seconda
dello stato dei servizi. C'è invece la grandezza dell'icona. È stato aggiunto anche qui
un url, infatti selezionando l'icona si va all'indirizzo specificato che rappresenta la web
management. Il discorso però della web management e degli url viene affrontato nel
prossimi paragrafo.
L'oggetto icona per gli hostgroup è praticamente identico a quello delle icone per gli
host. Identico per quanto riguarda i parametri. L'unica differenza, oltre ovviamente a
quello che si controlla, è da ricercarsi nel file di configurazione.
Si può notare che al posto del “define host” c'è un “define hostgroup”.
Anche per l'icona della mappa, che vede lo stato generale di tutto quello incluso in
quella mappa, è uguale fatta eccezione per il define, che questa volta è “define map”.
Con questo si è fatta una panoramica di tutti gli oggetti utilizzati nelle mappe. Si è
visto a cosa servono e come personalizzarli. Le mappe complete sono visibili
nell'appendice.
L'unico aspetto rimasto, che è stato volutamente messo da parte per essere affrontato
dettagliatamente, è quello che riguarda la Web Management.
6.3. Url e Web Management
Accedere alla Web Management di un apparato è una delle finalità di questo lavoro di
tesi. Una volta completate le mappe, l'amministratore della rete ha a disposizione la
mappa principale dalla quale è visibile un quadro generale dello stato dei servizi su
tutti gli apparati.
Nel caso ci sia un problema su un determinato apparato, l'amministratore deve poter
ovviamente accedere a questo apparato per controllarne la causa. Per questo motivo è
Pagina 102 di 148
stata implementata la possibilità di poter cliccare su una singola icona di host per
essere indirizzati direttamente alla sua web management.
Di default queste icone hanno già un collegamento, specificato nel campo url e
url_target. Il collegamento di default apre una pagina generata automaticamente dove
sono visualizzabili le informazioni sui servizi di quel host. Queste informazioni però
sono ridondanti in quanto già visualizzabili dalla mappa sulla quale è presente questa
icona di host. Quindi il collegamento a questa pagina risulta inutile.
Il collegamento, come già detto, è messo di default. Per toglierlo e fare in modo che
l'icona non punti a niente si deve andare nel file di configurazione, rintracciare il
define relativo a quell'icona, e aggiungere dentro il define:
url=
In questo modo l'icona risulta non cliccabile. Questo è stato fatto per gli apparati che
non hanno una web management, cioè per tutti gli ups, tranne upsmon250.na.infn.it.
Anche per l'icona della mappa è stato disabilitato l'url.
Lì dove si inserisce invece un url, si deve specificare un “url_target”, cioè dove aprire
l'url. Di default l'url target ha il valore “_self”, che indica che il link deve essere aperto
nella stessa pagina. Questo ovviamente può essere alquanto fastidioso in quanto,
piuttosto sarebbe meglio aprire la web management in un'altra pagina.
Questo si fa inserendo il seguente valore:
url_target = _blank
Per accedere all'interfaccia grafica della web management si deve inserire, nel campo
url, l'host name della macchina preceduto da “ipmi-”
Pagina 103 di 148
Questo va fatto in tutti i casi tranne che per gli switch.
Alcuni host non hanno ancora un'interfaccia, ma l'indirizzo del'url è stato comunque
messo in previsione di un funzionamento futuro.
Gli indirizzi non sono raggiungibili dall'esterno, ma solo dall'interno della rete. Quindi
provando ad andare sulla web management dall'esterno si visualizza un “impossibile
visualizzare la pagina”. Si è voluto sostituire questa pagina di errore generico con una
pagina personalizzata che spiegasse il motivo dell'impossibilità di accedere a quel link.
In particolare per la mancanza di permessi potendoci accedere solo chi è interno alla
rete.
È stata quindi fatta una pagina di errore in html con un segnale di divieto d'accesso.
Di seguito il codice della pagina errore.html:
<html>
<head>
<title>Accesso Negato</title>
</head>
<body>

 Access forbidden! 

You don't have permission to access the request page 
<img src="noaccess.jpg" title="Accesso Negato" alt="Accesso Negato" width="224"
height="200" />

</body>
Pagina 104 di 148
</html>
Ora il problema è come e quando mostrare questa pagina.
Per far questo si è dovuto creare un ulteriore file, questa volta in php, che facesse il
controllo sull'indirizzo che sta cercando di accedere a quella pagina.
Se l'indirizzo è esterno si fa un redirect alla pagina di errore altrimenti si va
all'interfaccia grafica della Web Management.
Nell'url di ogni icona di host quindi è necessario inserire un collegamento a questo file
php, chiamato “checkaccess.php”. Il file php però ha bisogno di sapere da quale icona
di host è stato chiamato e quindi quale indirizzo di host utilizzare.
La soluzione più semplice è passare, come parametro al file php, l'host name che lo sta
chiamando. Per capire meglio l'indirizzo completo, di seguito l'url per atlasce01:
http://tier2-nagios.na.infn.it/checkaccess.php?address=http://ipmi-atlasce01.na.infn.it
Quindi l'indirizzo è quello del file checkaccess.php al quale si passa come parametro
address (tramite il punto interrogativo) l'host name. Tutti gli url alla web management
degli host sono visibili dal file di configurazione della mappa che li contiene.
Il file checkaccess.php si trova, così come errore.html, nella directory /var/www/html
di tier2-nagios. Di seguito il suo codice:
<?php
$ip=$_SERVER['REMOTE_ADDR'];
if ((($ip[0]=="1") && ($ip[1]=="7") && ($ip[2]=="3") && ($ip[4]=="1") &&
($ip[5]=="6")) || (($ip[0]=="1") && ($ip[1]=="9") && ($ip[2]=="2") &&
($ip[4]=="8") && ($ip[5]=="4") && ($ip[7]=="1") && ($ip[8]=="3") &&
($ip[9]=="4") && ($ip[11]=="2") && ($ip[12]=="3") && ($ip[13]=="0")))
Pagina 105 di 148
{
$address=$_GET['address'];
header("location: $address");
}
else
{
header("location: /errore.html");
}
?>
Con questo si può dire completato il mio lavoro. Il codice dei file di configurazione
delle mappe è incluso, così come le immagini delle mappe, nell'appendice.
Pagina 106 di 148
7. Conclusioni
Come si evince dalla lettura di questa tesi NAGIOS è una applicazione open source
completa che risulta essere una valida alternativa agli altri tool di monitoraggio
reperibili a pagamento. Garanzia di validità è proprio questo lavoro svolto su una rete
grande ed eterogenea come quella del Tier2-Napoli.
Grazie alla sua diffusione, il suo utilizzo è accompagnato da nuove release che
vengono incontro alle nuove necessità che si presentano, addon sempre più funzionali
per una migliore gestione dell'applicazione e da una documentazione oramai
collaudata per una corretta installazione, configurazione e risoluzione di eventuali
problemi.
Unico limite evidente è il suo impossibile utilizzo su piattaforma windows.
Questa tesi si pone come obiettivo quello di guidare, passo per passo, chiunque abbia
la necessità di installare una applicazione di monitoraggio per le risorse di una rete. In
particolare si concentra sul monitoraggio di risorse locali di host remoti.
Proprio per questo motivo, molti aspetti sono stati affrontati anche in maniera
generale, potendo essere d'aiuto a chi avesse necessità o problemi diversi.
Altri aspetti correlati invece sono stati solamente accennati e brevemente descritti in
quanto complementari a questo lavoro di tesi oppure già affrontati in altri lavori.
Si è infatti detto che l'applicazione Nagios è stata inserita all'interno di una portlet, di
un portale liferay. Le problematiche relative all'installazione del portale e
all'integrazione di applicazioni all'interno delle portlet sono ampiamente affrontare in
un altro lavoro di tesi fatto in questo laboratorio.
Se ci fosse quindi il bisogno di ampliare il lavoro ad un EIP aziendale si può integrare
quanto scritto qui, con il lavoro svolto in quest'altra tesi che prende il nome di: “Un
Pagina 107 di 148
Sistema di Monitoraggio per il Tier2-ATLAS dell' INFN”.
Così come questo lavoro di tesi può essere considerato il continuo di un altro lavoro, è
da considerarsi a sua volta una base per lavori futuri facendo parte di un progetto più
ampio. Il prossimo passo infatti, già in corso, è quello di sviluppare ulteriormente il
lato che riguarda la Web Management introducendo, per esempio, la possibilità di un
Single Sign On. Attualmente infatti ci si deve autenticare più volte. Una volta
all'ingresso del portale e ogni volta che si vuole accedere all'interfaccia grafica della
Web Mangement di un apparato. Con il SSO invece ci si autenticherà solo una volta al
portale e, in base ai permessi sul proprio profilo, si potrà direttamente accedere o meno
ad un apparato senza passare di nuovo per l'autenticazione.
Ulteriori sviluppi futuri prevedono anche l'utilizzo dei grafici generati per ogni
servizio e l'aggiunta di nuovi script per il monitoraggio di altre risorse.
Si ricorda inoltre che questo lavoro rientra nell'ambito del progetto ATLAS a Napoli.
È stato anche presentato alla Conferenza del GARR che si è svolta a Torino dal 26 al
28 Ottobre 2010 come parte di un portale di monitoraggio centralizzato per i centri di
calcolo distribuito.
Pagina 108 di 148
8. Appendice
8.1. File di Configurazione delle Mappe
define global {
iconset=std_medium
map_image=ATLASv2n800_legenda.png
}
define hostgroup {
url=index.php?map=Tier2_INFN_CMC
iconset=std_small
hostgroup_name=CMC_atlas
x=523
y=356
}
define hostgroup {
url=index.php?map=Tier2_INFN_WN
iconset=std_small
hostgroup_name=Atlas_Worker_Nodes
x=700
y=172
}
define hostgroup {
url=index.php?map=Tier2_INFN_SW
iconset=std_small
hostgroup_name=Atlas_Switchs
x=610
y=313
}
define host {
iconset=std_small
host_name=upsmonatlas01.na.infn.it
x=190
y=146
url=
}
define host {
iconset=std_small
host_name=upsmonatlas02.na.infn.it
x=269
y=146
Pagina 109 di 148
url=
}
define host {
url_target=_blank
url=http://tier2-nagios.na.infn.it/checkaccess.php?
address=upsmon250.na.infn.it
iconset=std_small
host_name=upsmon250.na.infn.it
x=72
y=147
}
define host {
url_target=_blank
address=upsmon400a.na.infn.it
iconset=std_small
host_name=upsmon400a.na.infn.it
x=144
y=266
}
define host {
url_target=_blank
address=upsmon400b.na.infn.it
iconset=std_small
host_name=upsmon400b.na.infn.it
x=221
y=276
}
define map {
iconset=std_small
map_name=atlas
x=347
y=31
url=
}
define hostgroup {
url=/nagios/nagvis/nagvis/index.php?map=Tier2_INFN-900
hostgroup_name=Atlas_Device
x=395
y=503
iconset=std_small
}
define hostgroup {
Pagina 110 di 148
url=index.php?map=Tier2_SCOPE_WN
hostgroup_name=Scope_Worker_Nodes
x=729
y=172
iconset=std_small
}
define hostgroup {
url=/nagios/nagvis/nagvis/index.php?map=Tier2_SCOPE_1-900
hostgroup_name=Scope_Device
x=395
y=522
iconset=std_small
}
define hostgroup {
url=index.php?map=Tier2_INFN_SN
hostgroup_name=Service_Nodes
x=641
y=222
iconset=std_small
}
define hostgroup {
url=index.php?map=Tier2_INFN_Router
hostgroup_name=Cisco_routers
x=594
y=462
iconset=std_small
}
define hostgroup {
url=index.php?map=Tier2_SCOPE_SW
hostgroup_name=Scope_Switchs
x=639
y=313
iconset=std_small
}
define hostgroup {
url=index.php?map=Tier2_SCOPE_CMC
hostgroup_name=CMC_scope
x=552
y=356
iconset=std_small
}
define hostgroup {
url=index.php?map=Tier2_INFN_SE
hostgroup_name=Atlas_Storage_Elements
Pagina 111 di 148
x=436
y=173
iconset=std_small
}
define hostgroup {
url=index.php?map=Tier2_SCOPE_SE
hostgroup_name=Scope_SE_DBoxController
x=465
y=173
iconset=std_small
}
define global {
iconset=std_medium
map_image=Tier2_INFN_Router.png
}
define host {
url_target=_blank
url=http://router-atlas.na.infn.it
host_name=router-atlas.na.infn.it
x=438
y=189
iconset=std_mini
}
define shape {
icon=B-dietro.png
x=680
y=5
}
define global {
iconset=std_medium
map_image=Tier2_INFN_SE.png
}
define host {
url_target=_blank
Pagina 112 di 148
address=http://atlasse03.na.infn.it
host_name=atlasse03.na.infn.it
x=292
y=326
iconset=std_mini
}
define host {
url_target=_blank
address=http://atlasse02.na.infn.it
x=292
y=339
iconset=std_mini
}
define host {
url_target=_blank
address=http://ipmi-atlasse06.na.infn.it
x=583
y=230
iconset=std_mini
}
define host {
url_target=_blank
x=583
y=243
iconset=std_mini
}
define shape {
icon=B-dietro.png
x=709
y=5
}
define host {
url_target=_blank
x=583
Pagina 113 di 148
y=324
iconset=std_mini
}
define host {
url_target=_blank
x=583
y=336
iconset=std_mini
}
define host {
url_target=_blank
address=http://t2-dpm-01.na.infn.it
host_name=t2-dpm-01.na.infn.it
x=583
y=206
iconset=std_mini
}
define global {
iconset=std_medium
map_image=Tier2_SCOPE_CMC.png
}
define host {
url_target=_blank
address=http://172.21.0.76
host_name=rack26scope
x=478
y=371
iconset=std_mini
}
define host {
url_target=_blank
host_name=cmcRack27scope
x=477
Pagina 114 di 148
y=318
iconset=std_mini
}
define host {
url_target=_blank
x=476
y=262
iconset=std_mini
}
define host {
url_target=_blank
x=753
y=318
iconset=std_mini
}
define host {
url_target=_blank
x=752
y=261
iconset=std_mini
}
define host {
url_target=_blank
x=753
y=207
iconset=std_mini
}
define shape {
icon=B-dietro.png
x=686
y=5
}
Pagina 115 di 148
define global {
iconset=std_medium
map_image=Tier2_INFN_SN.png
}
define host {
url_target=_blank
address=http://monitor.na.infn.it
host_name=monitor.na.infn.it
x=293
y=216
iconset=std_mini
}
define host {
url_target=_blank
address=http://t2-hlr-01.na.infn.it
host_name=t2-hlr-01.na.infn.it
x=293
y=233
iconset=std_mini
}
define host {
url_target=_blank
address=http://atlasui01.na.infn.it
host_name=atlasui01.na.infn.it
x=293
y=257
iconset=std_mini
}
define host {
url_target=_blank
address=http://atlasui02.na.infn.it
host_name=atlasui02.na.infn.it
x=293
y=275
iconset=std_mini
}
Pagina 116 di 148
define host {
url_target=_blank
address=http://atlas-squid.na.infn.it
host_name=atlas-squid.na.infn.it
x=586
y=242
iconset=std_mini
}
define host {
address=http://ipmi-atlasce01.na.infn.it
url_target=_blank
host_name=atlasce01.na.infn.it
x=592
y=320
iconset=std_mini
}
define shape {
icon=B-dietro.png
x=677
y=5
}
define global {
iconset=std_medium
map_image=Tier2_SCOPE_SE.png
}
define host {
url_target=_blank
x=185
y=202
iconset=std_mini
}
define host {
url_target=_blank
Pagina 117 di 148
x=185
y=216
iconset=std_mini
}
define host {
url_target=_blank
address=http://atlas-e4-03a.na.infn.it
host_name=atlas-e4-03a
x=185
y=247
iconset=std_mini
}
define host {
url_target=_blank
address=http://atlas-e4-03b.na.infn.it
host_name=atlas-e4-03b
x=185
y=261
iconset=std_mini
}
define host {
url_target=_blank
x=437
y=264
iconset=std_mini
}
define host {
url_target=_blank
x=437
y=276
iconset=std_mini
}
define host {
url_target=_blank
address=http://atlas-e4-04a.na.infn.it
host_name=atlas-e4-04a
Pagina 118 di 148
x=437
y=304
iconset=std_mini
}
define host {
url_target=_blank
address=http://atlas-e4-04b.na.infn.it
host_name=atlas-e4-04b
x=437
y=318
iconset=std_mini
}
define host {
url_target=_blank
x=687
y=329
iconset=std_mini
}
define host {
url_target=_blank
x=687
y=344
iconset=std_mini
}
define host {
url_target=_blank
x=687
y=358
iconset=std_mini
}
define host {
url_target=_blank
Pagina 119 di 148
x=687
y=372
iconset=std_mini
}
define shape {
icon=B-dietro.png
x=823
y=5
}
define global {
iconset=std_medium
map_image=Tier2_INFN_SW.png
}
define host {
url_target=_blank
address=http://sw3com-atlas01.na.infn.it
host_name=sw3com-atlas01
x=81
y=137
iconset=std_mini
}
define host {
url_target=_blank
x=351
y=155
iconset=std_mini
}
define host {
url_target=_blank
address=http://swlinksys-cs.na.infn.it
host_name=swlinksys-cs
x=581
y=133
iconset=std_mini
Pagina 120 di 148
}
define host {
url_target=_blank
address=http://swdell-scope01.na.infn.it
host_name=swdell-scope01
x=581
y=147
iconset=std_mini
}
define host {
url_target=_blank
x=797
y=132
iconset=std_mini
}
define shape {
icon=B-dietro.png
x=618
y=5
}
define global {
iconset=std_medium
map_image=Tier2_SCOPE_SW.png
}
define host {
url_target=_blank
address=http://cat2960-atlas01.na.infn.it
host_name=cat2960-atlas01
x=432
y=203
iconset=std_mini
}
define host {
url_target=_blank
Pagina 121 di 148
address=http://swdell-atlas01.na.infn.it
host_name=swdell-atlas01
x=432
y=235
iconset=std_mini
}
define host {
url_target=_blank
address=http://swdell-atlas02.na.infn.it
host_name=swdell-atlas02
x=432
y=292
iconset=std_mini
}
define host {
url_target=_blank
x=432
y=345
iconset=std_mini
}
define shape {
icon=B-dietro.png
x=724
y=5
}
define global {
iconset=std_medium
map_image=Tier2_INFN_WN.png
}
define host {
url_target=_blank
url=http://ipmi-atlaswn09.na.infn.it
host_name=atlaswn09.na.infn.it
x=445
y=343
Pagina 122 di 148
iconset=std_mini
}
define host {
url_target=_blank
x=445
y=356
iconset=std_mini
}
define host {
url_target=_blank
x=445
y=369
iconset=std_mini
}
define host {
url_target=_blank
x=445
y=381
iconset=std_mini
}
define host {
url_target=_blank
x=445
y=394
iconset=std_mini
}
define host {
url_target=_blank
x=445
y=406
iconset=std_mini
}
define host {
url_target=_blank
Pagina 123 di 148
x=445
y=419
iconset=std_mini
}
define host {
url_target=_blank
x=445
y=431
iconset=std_mini
}
define host {
url_target=_blank
x=445
y=444
iconset=std_mini
}
define shape {
icon=B-dietro.png
x=674
y=5
}
define global {
iconset=std_medium
map_image=Tier2_SCOPE_WN.png
}
define host {
url_target=_blank
address=http://ipmi-atlaswn44.na.infn.it
x=289
y=196
iconset=std_mini
}
Pagina 124 di 148
define host {
url_target=_blank
x=289
y=209
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=223
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=237
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=267
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=280
iconset=std_mini
}
Pagina 125 di 148
define host {
url_target=_blank
x=289
y=294
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=307
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=321
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=335
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=348
iconset=std_mini
Pagina 126 di 148
}
define host {
url_target=_blank
x=289
y=362
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=392
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=405
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=419
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=433
Pagina 127 di 148
iconset=std_mini
}
define host {
url_target=_blank
x=289
y=446
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=195
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=208
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=222
iconset=std_mini
}
define host {
url_target=_blank
x=415
Pagina 128 di 148
y=237
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=266
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=279
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=293
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=307
iconset=std_mini
}
define host {
url_target=_blank
Pagina 129 di 148
x=415
y=320
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=333
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=347
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=361
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=392
iconset=std_mini
}
define host {
url_target=_blank
Pagina 130 di 148
x=415
y=404
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=418
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=446
iconset=std_mini
}
define host {
url_target=_blank
x=587
y=381
iconset=std_mini
}
define host {
url_target=_blank
x=587
y=394
iconset=std_mini
}
Pagina 131 di 148
define host {
url_target=_blank
x=587
y=407
iconset=std_mini
}
define host {
url_target=_blank
x=587
y=420
iconset=std_mini
}
define host {
url_target=_blank
x=415
y=432
iconset=std_mini
}
define host {
url_target=_blank
x=587
y=341
iconset=std_mini
}
define host {
url_target=_blank
x=587
y=355
Pagina 132 di 148
iconset=std_mini
}
define host {
url_target=_blank
x=587
y=368
iconset=std_mini
}
define host {
url_target=_blank
x=587
y=433
iconset=std_mini
}
define host {
url_target=_blank
x=710
y=341
iconset=std_mini
}
define host {
url_target=_blank
x=710
y=355
iconset=std_mini
}
define host {
url_target=_blank
x=710
y=367
Pagina 133 di 148
iconset=std_mini
}
define host {
url_target=_blank
x=710
y=381
iconset=std_mini
}
define host {
url_target=_blank
x=710
y=394
iconset=std_mini
}
define host {
url_target=_blank
x=710
y=407
iconset=std_mini
}
define host {
url_target=_blank
x=710
y=420
iconset=std_mini
}
define host {
url_target=_blank
x=710
y=433
Pagina 134 di 148
iconset=std_mini
}
define shape {
icon=B-dietro.png
x=805
y=5
}
define global {
iconset=std_medium
map_image=Tier2_INFN_CMC.png
}
define host {
url_target=_blank
address=http://cmc1atlas.na.infn.it
host_name=cmc1atlas
x=221
y=313
iconset=std_mini
}
define host {
url_target=_blank
host_name=cmc2atlas
x=391
y=312
iconset=std_mini
}
define host {
url_target=_blank
host_name=cmc3atlas
x=554
y=312
iconset=std_mini
}
Pagina 135 di 148
define host {
url_target=_blank
host_name=cmc4atlas
x=720
y=312
iconset=std_mini
}
define shape {
icon=B-dietro.png
x=609
y=5
}
Pagina 136 di 148
8.2. Mappe
Pagina 137 di 148
Pagina 138 di 148
Pagina 139 di 148
Pagina 140 di 148
Pagina 141 di 148
Pagina 142 di 148
Pagina 143 di 148
Pagina 144 di 148
Pagina 145 di 148
Pagina 146 di 148
Pagina 147 di 148
Bibliografia
Centreon http://www.centreon.com/
Nagios http://www.nagios.org
Liferay http://www.liferay.com/
Nagios Plugin http://nagiosplugins.org/
Nagios and Nrpe Documentation http://nagios.sourceforge.net/docs/3_0/toc.html
ATLASItalia https://t2-wn-51.roma1.infn.it/
Guida PHP di base http://php.html.it/guide/leggi/99/guida-php-di-base/
Pagina 148 di 148

Il monitoraggio di un DataCenter - SCoPE

Transcript

Documenti analoghi

COMUNICATO STAMPA L`arte del viaggio: insieme a - press-goup

Orologi di Classe Journalist Date 17.06.2014 Type of media Blog

Eufranio Massi - Il Lavoratore | del pubblico impiego Blog

Risposte quiz_20-07-2015

Circolare_n279 - liceo benedetti

verso un`edizione da record - Host

Scheda Prodotto (formato PDF - 125 KB)

Gruppi linux, spazi web e database

Selezione per l`assegnazione di n. 10 Borse di Studio GARR "Orio