Camiciusonline

Continua la nostra carrellata sull’utilizzo di Nagios.

Ogni controllo fatto su un host, è fatto (di solito, ma non obbligatoriamente) da un plugin di Nagios. Questi non sono altro che file eseguibili (alcuni sono script di shell o perl) con alcune caratteristiche:

• il valore di ritorno è 0 se il valore è ok, 1 se è warning, 2 se è critical, 3 se è unknown
• stampano su stdout una riga che esplichi qualche valore extra (magari che spieghi il motivo della condizione di errore, se c’è

Ovviamente la cosa migliore è che siano un minimo configurabili (ovviamente una condizione che per noi è critica in altre situazioni potrebbe essere accettabile, o solo warning. Maggiori informazioni qui.

Per reference mia, per capire se mi è scappato qualcosa che mi potrebbe essere utile, ho installato tutti i pluginche Fedora 8 mette a disposizione, e quindi ne faccio un elenco.

• check_apt: utile solo per le distribuzioni debian-based o con apt-get configurato e funzionante. Fa l’upgrade automatico di queste distribuzioni. ritorna warning se è stato fatto un upgrade. Ritorna critical se vengono aggiornati dei pacchetti selezionabili via REGEXP
• check_breeze: controlla la potenza del segnale di un apparecchi wireless Breezecom
• check_by_ssh: esegue comandi su un host remoto. Utile per installare solo i plugin sui server remoti e controllare tutto da un singolo host di monitoraggio
• check_clamd: testa l’attività di un server clamd
• check_cluster: controlla la salute di un cluster
• check_dhcp: controlla la presenza del server DHCP
• check_dig: controlla le risposte di un server DNS utilizzando dig. Eventualmente controlla anche la correttezza delle risposte
• check_disk: controlla lo spazio disco usato su un filesystem montato (controlla sia lo spazio che gli inode, e si possono utilizzare sia soglie assolute che percentuali). Si possono ignorare filesystem sia per tipo (che ne so, ISO9660) che per mountpoint
• check_disk_smb: controlla lo spazio su share di rete SMB
• check_dns: come check_dig ma utilizza nslookup
• check_dummy: check finto: ritorna lo stato indicato nella riga di comando
• check_file_age: verifica che un file non sia vuoto e/o che sia stato acceduto-scritto da un tempo prefissato
• check_flexlm:controlla la presenza di uno (o tre) Flexlm licence manager
• check_fping: usa fping per un controllo veloce dell’host
• check_ftp: testa l’attività del server FTP, passandouna stringa e controllando che ritorni quella corretta
• check_game: utilizza qstat per controllare un game server
• check_hpjd: controlla lo stato di una stampante che utilizza una scheda JetDirect
• check_http:controlla un server http (o https), segue i redirect, e contorlla stringhe e regexp su quanto ritornato
• check_icmp:esegue un ping (pacchetto ICMP) con opzioni avanzate (Tipicamente TTL)
• check_ide_smart: contorlla lo stato di un hard disk ide usando SMART
• check_ifoperstatus: controlla lo stato di una particolare interfaccia di rete sull’host usando snmp
• check_ifstatus: idem come sopra, ma le controlla tutte
• check_imap: testa le connesioni IMAP, eventualmente tentando una autenticazione.
• check_ircd:controlla un server irc
• check_jabber:controlla un server Jabber
• check_ldap:controlla un server ldap, tendando una query su un basedn
• check_ldaps:lo stesso di cui sopra, ma usando TLS
• check_linux_raid:
• check_load: contorlla il carico di sistema corrente
• check_log: controlla il file di log per un pattern conosciuto
• check_mailq: controlla la lunghezza nella coda delle email (supporta sendmail, qmail)
• check_mrtg: controlla il valore medio o il massimo di una delle due variabili memorizzate in un log file MRTG
• check_mrtgtraf:  controlla i transfer rates di un router, switch ecc. registrati in un log MRTG
• check_mysql: testa la connessione su un database server MySql
• check_mysql_query: testa la connessione su un database server MySql effettuando una query e valutando i risultati
• check_nagios: controlla il processo nagios
• check_nntp: controlla una connessione NNTP
• check_nntps: controlla una connessione NNTPS
• check_nrpe: controlla che tu abbia un demone NRPE sull’host remoto
• check_nt: raccoglie dati su un servizio NSClient su un server Windows NT/2000/XP/2003
• check_ntp: controlla il server ntp
• check_ntp_peer: controlla il server ntp
• check_ntp_time: controlla l’offset tra l’ora del server e quella data da NTP
• check_nwstat: cerca di contattare il MRTGEXT NLM di un server Novell per raccogliere informazioni (le più svariate, carico, processi, uptime, file aperti, spazio libero-usato ecc. ecc. ecc.)
• check_oracle: tenta l’autenticazione su un server Oracle
• check_overcr: cerca di contattare il collector daemon OverCR
• check_pgsql: contatta un server PostgreSQL. Tenta autenticazione, ed eventualmente query
• check_ping: usa ping per generare statistiche sulla connessione di un host remoto
• check_pop: controlla connessioni pop3
• check_procs: controlla i processi che girano su un host. Ritorna Warning e Critical in base a metriche selezionabili
• check_radius: contorlla che il server radius accetti connessioni
• check_real: controlla il servizio REAL sull’host specificato
• check_rpc: controlla che ci sia un servizio RPC registrato e attivo sul server remoto
• check_sensors: controlla lo stato dell’hardware utilizzando lm_sensors
• check_simap: controlla connessioni simap
• check_smtp:cerca di aprire una connession smtp con l’host
• check_snmp: ottiene informazioni su una macchina remota via snmp
• check_snmp_disk: cerca di ottenere informazioni sul disco via snmp
• check_snmp_proc: cerca di ottenere informazioni sui processi via snmp
• check_spop: controlla connesioni SPOP
• check_ssh: tenta una connessione a un server SSH
• check_ssmtp: controlla connesioni SSMTP
• check_swap: controlla lo spazio swap sulla macchina locale
• check_tcp: testa una connessione TCP su un host specificato
• check_time: controlla l’ora sull’host specificato
• check_udp: testa una connessione UDP su un host specificato
• check_ups: controlla lo stato dell’UPS controllato via NUT
• check_users:controlla il numero di utenti loggati
• check_wave: controlla la forza del segnale ricevuto (da chi?)

i plugin in grassetto sono plugin locali, quindi controllano i dati sull’host dove gira il processo nagios, oppure sono invocati usando check_by_ssh (che funziona benissimo).

… configurato via ldap.

Nagios è una nota applicazione open source per il monitoraggio di computer e risorse di rete. La sua funzione base è quella di controllare nodi, reti e servizi specificati, avvertendo quando questi non garantiscono il loro servizio o quando ritornano attivi. Il tutto abitualmente è gestito attraverso una pletora di files di configurazione che definiscono tutti gli oggetti che servono alla configurazione di questo prodotto.

Gli oggetti definiti sono:

• command: definizione dei comandi per la scansione di qualunque cosa
• contact: i contatti ai quali bussare se qualcosa va male
• timeperiods: intervalli di tempo nei quali un servizio (o una notifica) è attivo [1]
• host: ovvero il server che viene monitorato
• hostgroup: sono un raggruppamento mnemonico dei server. In realtà via Ldap non si possono usare
• service: sono i servizi che vengono monitorati: per esempio webserver, db server, dns ecc..
• servicegroup: sono un raggruppamento mnemonico dei servizi. In realtà via Ldap non si possono usare

La configurazione via file di testo è abbastanza scomoda, soprattutto se ci sono una fila di amministratori che devono gestirla e la cosa è in rapido divenire: una macchina che viene spenta intenzionalmente senza che venga tolta dal controllo Nagios, rischia di generare una serie di alert inutili e quindi di fare correre persone ecc. ecc.

Inoltre se si vogliono, per ridondanza, mettere più di un server Nagios, ogni modifica va replicata su tutte le macchine. Se si abbina alla cosa la possibile concorrenza delle modifiche si capisce come il mix rischi di diventare esplosivo.

La soluzione ldap, “regala” senza troppa fatica, una configurazione in un singolo punto, concorrenza nelle modifiche, consistenza con il resto dell’infrastruttura.

Questa soluzione è stata implementata da un personaggio che ha un sito dal nome buffo, e che ha provato (a quanto ho capito) a committare il tutto nel master branch, in realtà senza riuscirci. Nel post qui sopra, ci sono gli rpm che ha creato con il binario, la patch da applicare e un po’ di altre amenità.

Fortunatamente il mio server di monitoraggio (che poi è il mio desktop) era una macchina Fedora, quindi i due file RPM (quello di Nagios in sé e quello dell’interfaccia web) si sono installati senza il minimo problema.

Riavviato il server web (e risolti alcuni problemini alla configurazione e all’autenticazione), alla pagina http://localhost/nagios/ rispondeva allegramente l’interfaccia, che monitora di default localhost.

In generale per riavviare il servizio Nagios, si usa il comando

service nagios restart

Prima del riavvio è bene controllare la configurazione utilizzando il comando

nagios -v /etc/nagios/nagios.cfg
A questo punto, nel file /etc/nagios/nagios.cfg si commenta la riga

cfg_file=/etc/nagios/objects/localhost.cfg

e si aggiunge la riga che chiama l’albero ldap dove sono messi tutti gli oggetti.

ldap_server=ldap://ldap.localnet/name=Nagios,o=Qccv

Il comando di controllo della configurazione si lamenterà che non è possibile aggiungere nessun servizio, e quindi uscirà con errore.

A questo punto bisogna mettere host e servizi dentro LDAP.

Si introduce un nuovo concetto (che è implicito nella configurazione testuale) ovvero quello di monitorGroup.

Un monitorGroup è sostanzialmente un server di monitoraggio. Serve per mantenere in un solo ldap i dati di più server di monitoraggio. L’oggetto LDAP deve avere objectClass monitorgroup e deve contenere nell’attributo monitorFQDN l’hostname completo del server di monitoraggio.

Per come la cosa è costruita, il programma scandaglia un sottoramo dell’albero, cercando tutti gli oggetti che rispondono alle caratteristiche di host, di service e di monitorGroup.

Gli host sono definiti con queste classi e questi attributi:

• objectClass monitorHost
  da compilare cn, ipHostNumber, relativeDomainName, uguali a quelli sopra. Inoltre è da compilare il campo monitorGroup, con il nome completo di percorso del monitorGroup (o dei monitorGroup) che monitorizzano l’host. Inoltre qua si riscrive la descrizione, e il template che l’host estende.
• objectClass top

più una structural class, che può essere Host, ipHost, o qualcos’altro (da testare. La structural class in generale può essere quella della struttura preesistente).

I servizi invece sono così definiti:

• objectClass monitoredService
  obbligatori cn, hostName (o una lista di hostName) e monitorGroup. Ovviamente utili check-command  e nagius-use, che è il template di servizio. check-command è opzionale perchè potrebbe essere già definito nel template. È invece obbligatoria la descrizione. Senza questa il servizio non viene riconosciuto.
• objectClass top

Se tutto funziona al riavvio del servizio (service nagios restart, come root) oppure al controllo dei file di configurazione (nagios -v /etc/nagios/nagios.cfg) vengono rilevati i host e servizi relativi al monitorGroup sul quale stiamo lavorando.

A questo punto c’è solo da sbizzarrirsi: la definizione di host e servizi diventa un gioco, centralizzato, replicabile, protetto contro le modifiche concorrenti, integrabile con la infrastruttura ldap esistente.

[1] utile per esempio se il sistemista si può allertare via sms, pager o mail in orari diversi