Ganglia e Nagios Strumenti di monitor per la Cloud Attilio Santocchia Dipartimento di Fisica – UNIPG 4 aprile 2013 A. Santocchia - Ancona

Perché Nagios e Ganglia Richieste Monitoring delle performance Sistema di allarmi Logging Interfaccia user-friendly Espandibilità Supporto di ambienti multi SO (linux, windos) Necessità di monitorare l’infrastruttura cloud … e le applicazioni A. Santocchia - Ancona

Perché Nagios e Ganglia Performance monitor User friendly AllarmiLogging monitor Windows support Plugin for openstack Popularity Collectd ★★★★ Ganglia ★★★★★ Nagios ★★★★★★ Zenoss ★★★★★★ A. Santocchia - Ancona

Perché Nagios e Ganglia Performance monitor User friendly AllarmiLogging monitor Windows support Plugin for openstack Popularity Collectd ★★★★ Ganglia ★★★★★ Nagios ★★★★★★ Zenoss ★★★★★★ A. Santocchia - Ancona

Perché Nagios e Ganglia Performance monitor User friendly AllarmiLogging monitor Windows support Plugin for openstack Popularity Collectd ★★★★ Ganglia ★★★★★ Nagios ★★★★★★ Zenoss ★★★★★★ Non maturo per un ambiente di produzione A. Santocchia - Ancona

Perché Nagios e Ganglia Ganglia + Nagios permettono di sviluppare un ambiente di monitor completo e configurabile per OpenStack A. Santocchia - Ancona

Perché Nagios e Ganglia Nagios è perfetto per il monitoring e la gestione degli allarmi per i sistemi e i servizi… Ma dove runnano questi servizi? In una infrastruttura cloud dobbiamo monitorare: Le macchine reali dell’infrastruttura I controller dell’infrastruttura Le istanze accese (dinamicamente!) Nagios non è pronto a monitorare istanze che si accendono/spengono dinamicamente A. Santocchia - Ancona

Perché Nagios e Ganglia Soluzione ad hoc per ovviare al problema esistono Nagios è usato per il monitoring dell’infrastruttura di rete di Call of Duty (12 milioni di utenti di cui 2.3 milioni premium) Come faccio ad adeguare la mia infrastruttura di monitor ad un ambiente dove accendo e spengo centinaia di server in funzione del numero di utenti attivi? Il problema principale non è quando accendo nuovi server… Ma quando li spengo! Noi abbiamo sviluppato un sistema analogo A. Santocchia - Ancona

Nagios Nagios e ̀ una applicazione per monitorare: servizi di network (SMTP, POP3, HTTP, NNTP…) risorse dei server (carico della CPU, uso dei dischi…) raggiungibilità (ping) Permette di avere sotto controllo la situazione senza perdere troppo tempo inutilmente A. Santocchia - Ancona

Nagios GUI intuitiva e visibilità immediata dei problemi Training semplice e veloce Possibile realizzare grafici delle performance Cruscotto (dashboard) e Reports configurabili Scalabile e adatto a sistemi complessi e distribuiti Sistema di monitor 24/7 Sistema open-source e con una vasta comunità di utenti A. Santocchia - Ancona

Nagios Modulare e espandibile Una struttura centrale che schedula e coordina Per ogni servizio/sistema si utilizza un plugin specifico Vasta libreria di plugin esistenti già pronti all’uso Possibile sviluppare nuovi plugin in autonomia Controllabile da remoto tramite interfaccia WEB Può interagire con altre applicazioni per gestire allarmi e cambiamenti di stato A. Santocchia - Ancona

Nagios: il core Nagios coordina… Schedula il check dei servizi I controlli sono eseguiti da plugin Gestisce le informazioni passate ai plugin I plugin eseguono le misure e restituiscono i risultati …ed esegue valutazioni di stato, gestione dei logs, sa chi, come e perché contattare in caso di problemi E’ possibile modificare i parametri di configurazione senza riavviare il servizio di monitoring A. Santocchia - Ancona

Nagios: i plugin A. Santocchia - Ancona

Nagios: i plugin Esiste uno standard per lo sviluppo dei plugin Utilizzo di una sintassi consistente di passaggio dei parametri Soglie di attenzione (warning) e criticità Utilizzo di uno stesso plugin per controlli parametrizzati spazio su disco ping di hosts larghezza di banda A. Santocchia - Ancona

Nagios: i servizi Oggetto delle misure Controllati ad intervalli di tempo regolare Possono essere controllati in parallelo Possiamo scrivere un plugin per controllare un nostro servizio Possiamo impostare regole ad hoc per ogni servizio A. Santocchia - Ancona

Nagios: stati ed eventi A. Santocchia - Ancona

Nagios: gli Host Nel nostro caso macchine reali o istanze virtuali Se un servizio fallisce si controlla l'host se il controllo fallisce si fermano le notifiche e si procede alla verifica della rete testando l'host collegato logicamente come padre Tre stati UP – DOWN – UNREACHABLE Perché un host è down? Reale problema o istanza chiusa? A. Santocchia - Ancona

Nagios: gli Host Se un host non risponde possono esserci molteplici cause: Problema dell’istanza Problema di rete Istanza chiusa A. Santocchia - Ancona

Nagios: gli Host Se un host non risponde possono esserci molteplici cause: Problema dell’istanza Problema di rete Istanza chiusa A. Santocchia - Ancona Notifiche Fuori linea schedulato Fluttuazioni di stato (flap)

Nagios: gli Host Se un host non risponde possono esserci molteplici cause: Problema dell’istanza Problema di rete Istanza chiusa A. Santocchia - Ancona Notifiche Fuori linea schedulato Fluttuazioni di stato (flap) Nulla da fare Nessun allarme

Nagios: Notifiche Posso generare una notifica (allarme) Alla prima occorrenza di un problema Ogni X minuti se il problema persiste Per un cambiamento di stato In conseguenza di un flap A chi vengono inoltrate e come Ad un singolo utente e/o servizio Tramite , sms, piccione viaggiatore… Escalation: è possibile implementare un meccanismo automatico se il problema non viene risolto Entro un tempo prefissato Se l’errore si ripresenta A. Santocchia - Ancona

Nagios: Notifiche E’ fondamentale prevenire i falsi allarmi Nagios permette di considerare i periodi di downtime schedulati  Fixed, Flexible, Triggered E’ fondamentale gestire i flap (fluttuazione rapida e imprevedibile di un host o di un servizio) Nagios permette di spedire una sola notifica all’inizio e alla fine del periodo di flapping (tramite algoritmi decisionali specifici) A. Santocchia - Ancona

Nagios: gli eventi E’ possibile eseguire dei comandi/programmi esterni durante i cambiamenti di stato Dopo ogni controllo di un servizio o di un host è possibile inviare ad applicazioni esterne il risultato del controllo Utile per implementare la ridondanza dei servizi Utile per la realizzazioni di grafici e report A. Santocchia - Ancona

Nagios e la rete Posso distribuire il monitoring su più server Posso monitorare servizi e host su tronconi di rete nascosti da firewall (utile in ambiente cloud) E usare un unico controller centrale (eventualmente ridondato) Due server master and slave (se il master fallisce lo slave prende il suo posto) Che raccogli i dati inoltrati dai diversi server di monitoring collocati nei diversi sotto-rami di rete A. Santocchia - Ancona

Nagios: parallelismo Posso parallelizzare l’esecuzione dei plugin e il controllo dei servizi/host Non posso parallelizzare L’event handler: solo un singolo gestore può decidere di provare a far ripartire un servizio e/o mandare una notifica Il gestore delle notifiche: non voglio mandare notifiche inutili o multiple A. Santocchia - Ancona

Ganglia E’ un altro esempio di applicazione per il monitoring largamente usate e con una vastissima comunità di utenti Permette nativamente di monitorare ambienti distribuiti Sviluppata su standard open Si basa su un protocollo multi-cast e listen/announce A. Santocchia - Ancona

Ganglia: l’architettura gmond : è l’agente istallato su tutte le macchine da monitorare e trasmette i dati al controllore In una infrastruttura cloud tutte le VM istanziate possono includere Gmond e permettere quindi l’immediata fotografia dello stato della cloud gmetad : è l’agente istallato su uno o più server per la raccolta dei dati e l’elaborazione delle metriche scelte Apache Web Front-end : è il server web che permette l’analisi e la presentazione dei dati monitorati A. Santocchia - Ancona

Ganglia: l’architettura Multicast : tutti i nodi con Gmond istallato possono ascoltare e riportare informazioni sullo stato del cluster Failover : gmetad permette di cambiare il nodo da interrogare per ricevere i dati Leggero e non invasivo : gmond e gmetad occupano poca memoria e non caricano i nodi con richieste elevate di risorse Multipiattaforma : Linux e MS windows più altri… A. Santocchia - Ancona

Ganglia: l’architettura A. Santocchia - Ancona

gmond Moduli per metriche standard: CPU, Network I/O, Disk I/O, memoria e parametri di sistema Espandibile: Si possono sviluppare moduli per accedere a dati complessi o metriche multiple In alternativa si possono invocare comandi di sistema o scipt tramite l’utility gmetric. A. Santocchia - Ancona

gmond Scoperta automatica dei nodi Si può aggiungere un nodo da monitorare senza cambiare i file di configurazione (basta che abbia gmond istallato) Ogni nodo è configurato indipendentemente dagli altri Ogni nodo può ascoltare o parlare (multicast) ma, se necessario, può essere configurato in modalità unicast La frequenza di monitoring è ovviamente configurabile A. Santocchia - Ancona

gmond Esiste un file di configurazione globale per tutti le istanze gmond accese Ma è possibile configurare un sotto-insieme di nodi (un cluster) in modo specifico E’ possibile configurare la rete secondo specifici parametri per la modalità di trasmissione dati in trasmissione e ricezione E’ possibile raggruppare le varie metriche in gruppi (collezioni) per specificare diverse modalità di raccoltà dati alcune metriche devono essere raccolte più frequentemente di altre A. Santocchia - Ancona

gmond In sostanza: Esegue in monitoring delle metriche nell’istanza dove è istallato (host) Annuncia i cambiamenti rilevanti Ascolta lo stato degli alti nodi del suo cluster tramite un canale multicast o unicast Risponde alle richiesta del gmetad con lo stato globale del cluster descritto tramite un file XML La trasmissione dei dati avviene: Tramite messaggi UDP tra i nodi del cluster Tramite file XML su connessione TCP con gmetad A. Santocchia - Ancona

gmetad Interroga un cluster (un nodo del cluster) per raccogliere le informazioni su quel cluster …ma può interrogare un altro server (con gmetad istallato) per raccogliere le informazione dei cluster Include un tool grafico e un DB per memorizzare le informazioni raccolte alla massima granularità I grafici possono mostrare differenti gradi di granularità Dimensione fissata (non mantiene lo storico indefinitamente)  Round Robin DB A. Santocchia - Ancona

gmetad In sostanza: Interroga periodicamente i diversi cluster Esegue il parsing dei file XML che riceve Riempe il DB con i dati raccolti Esporta il file XML aggregato ai client (web GUI front- end ad esempio) A. Santocchia - Ancona

Il flusso dati di Ganglia A. Santocchia - Ancona /etc/gmond.conf /etc/gmetad.conf PHP Script Apache+PHP File access Network Web

Nagios + Ganglia considerazioni finali Domande da porsi quando di progetta un sistema di monitor: Quanti sistemi dobbiamo monitorare? Quanti servizi vengono offerti dai sistemi? Quali sono i processi critici da monitorare? Chi gestisce e controlla e sistemi e i servizi offerti? Quali sono i report che servono per la gestione del sistema e chi li deve visionare? A. Santocchia - Ancona

Nagios + Ganglia considerazioni finali Occorre stabilire inizialmente i ruoli e le responsabilità… Chi segue il report X (o il cruscotto Y)? E’ un servizio 24/7 o no? Occorre organizzare un team di persone in grado di gestire le problematiche… In che tempi? Decidere inizialmente i tempi di risposta (SLA) A. Santocchia - Ancona

Nagios + Ganglia la fase progettuale I costi principali di un sistema di monitor che funziona non è mai il sistema di monitor Sono le persone che operano quando il sistema accede un allarme Un sistema di monitor può crescere nel tempo e diventare molto sofisticato… E funzionare molto male se la responsabilità del sistema di monitoring non è chiara e ben definita A. Santocchia - Ancona