Liberare risorse mentaligestendo criticità in maniera efficiente

Relatore: Dott. Massimiliano Dal CeroSocio Fondatore Associazione DEFTCTO presso Tesla Consulting srls

@mdalcero m.dalcero@teslaconsulting.it

HOUSTON, ABBIAMO UN PROBLEMANUOVE REALTÀ, STESSE SITUAZIONI

In molteplici casi, chi gestisce l’infrastruttura IT “perde” (e non investe) molto del suo tempo a visionare che tutto fili liscio e ad applicare soluzioni molto spesso simili a se stesse.

Viene “rubato” tempo ad altre attività (implementazione di nuove soluzioni, riunioni, tempo libero), interrompendole per arginare le problematiche

IL MULTITASKING LASCIAMOLO ALLE MACCHINE

L’uomo è mono-core, e quando è stato progettato non è stata prevista l’installazione di un sistema con un efficiente

kernel pre-emtive.

Il context-switch è un processo mentale molto critico

UN GIRO IN BARCA

Nelle barche a vela, c’è un momento magico in cui la velocità è sufficiente a sollevare la barca sopra la sua stessa scia, toccando appena il pelo dell’acqua, così da riuscire a toccare velocità elevatissime. Avviene in maniera improvvisa ed è (dicono) una sensazione esilarante. Tuttavia è anche un momento fragilissimo, poiché basta una manovra goffa per tornare giù nell’acqua e fermarsi come contro un muro. Gli esseri umani hanno similmente uno stato psicologico chiamato “flusso”, che si attiva improvvisamente quando ci concentriamo su un task. Il “flusso” è definito come un “coinvolgimento profondo e quasi meditativo” sul task da realizzare, e induce spesso una “gentile sensazione di euforia”, ed una sostanziale perdita di senso del tempo. In stato di flusso, le persone sono molto produttive, specialmente per attività creative o progettuali. Come per le barche a vela, anche per gli esseri umani il flusso è uno stato magico e fragilissimo. E’ necessario evitare che distrazioni evitabili, possano interromperlo. Una volta fuori dal flusso, è difficile e lento riportarcisi.

Un articolo pubblicato sulla Harvard Business Review sostiene che il multitasking generi un crollo del 40% della

produttività e un aumento dello stress: impieghiamo il doppio del tempo per fare qualsiasi cosa, la possibilità di

commettere errori aumenta del 50%. E secondo uno studio della University of London, si riduce il quoziente

intellettivo fino a 10 punti.

LIMITIAMO LA “STUPIDITÀ” INDOTTA

INVESTIRE È QUINDI IMPORTANTE

Risulta quindi fondamentale investire risorse aziendali per ridurre al minimo le distrazioni e i vari casi di “context-swithing”

Nel nostro caso faremo due chiacchere su uno strumento utile per chi ha a che fare con i sistemi IT:

• Sistema (modulare ed estendibile) proattivo di monitorizzazione di servizi, host e risorse (spazio disco, carico della CPU, esistenza di processi, ...)

• Controlli paralleli

• Monitoraggio ed esecuzione di comandi remoti

• Estendibile tramite plugin ( facilmente sviluppabili in qualsiasi linguaggio )

• Ricco di plugin già pronti per una marea di esigenze

• Interfaccia Web di monitorizzazione (esistono anche extension per firefox e/o chrome che si possono interfacciare)

• Documentazione ufficiale completa ed esaustiva, e pieno di documentazione di terze parti

• Software Libero sotto licenza GPL

Panoramica

Senza un software come Nagios la situazione sarebbe circa la seguente:

•per la gestione dell’esecuzione bisognerebbe basarsi su crond, privandoci quindi della paralelizzazione, della granularità degli intervalli di check, delle soglie di avvertimento

•le modalità di invio degli alert sarebbero a discrezioni di ogni script check

•l’esecuzione di check remoti sarebbe alla mercé della fantasia dei singoli implementatori

•la manutenibilità è un aspetto critico e senza un direttore di orchestra centralizzato sarebbe decisamente ardua

Senza di lui

• Conoscere i problemi non solo prima che sia “chi non dovrebbe” a segnalarlo, ma possibilmente prevenirli prima che si verifichino:

• lo spazio disco sta finendo ?• la posta funziona ?• il database ha un carico tendente al limite ?• la porta “x” accetta le connessioni ?• l’host ha una risposta troppo lenta ?• la pagina ha codice malevolo sospetto ?

prendetevi il vantaggio

• Evita di realizzare soluzioni ad hoc per ogni servizio nuovo della rete

• Nagios è un sistema largamente utilizzato (e quindi testato) avente un core altamente configurabile, ricco di “fine tuning”, di “contatori interni”

• Permette di concentrarsi sull’organizzazione dei test e non dell’infrastruttura per far girare i test stessi (ovviamente, una volta configurato e a regime)

c’è proprio bisogno di lui ?

piccolo schema

Nagios 3

Interfaccia Web Free

Nagios XI

Evoluzione di Nagio3, ma closed.( sviluppata da nagios.com)

Altro

Per lo più implementazioni commerciali (NetEye, Wurth)

Nagios Core

Cuore Free che racchiude tutte le funzionalità del prodotto, sviluppata da nagios.com e dalla community nagios.org

Nagios Plugin

il core

• il cuore di Nagios svolge pochi compiti:

• schedulazione con paralelizzazione dei check:

• esegue e gestisce i parametri da passare ai plugin

• gestione degli stati dei singoli servizi/host e invio di alert

• gestione delle informazioni, le quali verranno poi date in pasto all’interfaccia utente di monitorizzazione

• comunica con gli host NRPE ( Nagios Remore Plugin Executor )

il compito dei check è tutto in mano ai plugin, i quali eseguono i controlli e e comunicano il risultato a nagios.il compito delle contro-misure è compito di script esterni e vengono eseguiti in base a quanto ritornato dai plugin

NagiosServer

NRPE

NRPE

NRPE

NagiosRemotePluginExecutor

Nagios check_nrpeSSL

Monitoring Host Remote Host

NRPEcheck_load

check_DB

Local resource/service

nota: i servizi si possono monitorare anche su host privi di un agente NRPE

check, status e soglie

• ci sono 3 eventi di status: OK, Warning, Critical

• ci sono 2 soglie: HARD e SOFT

• check ad intervalli dipendenti dalla situazione

check dell’host: problema di routing o down ?

Un host può non rispondere o perchè è DOWN o perchè c’è un problema sulla rete (router danneggiato, configurazioni di instradamento sbagliate, ...)

Nagios esegue una verifica del routing per individuare la vera causa del DOWN

plugin

• i plugin sono eseguibili o script esterni, nulla di hard coded

• sviluppabili in qualsiasi linguaggio o scripting ( Bash, Python, C, Java, Perl, Ruby, ... )

• Nagios passa al plugin i parametri tramite “comand line” ( configurabili nelle impostazioni )

• si interfacciano al core in base all’exit status:

• 0: OK/UP

• 1: Warning

• 2: Critical/Down

• 3: Unknow

alert

• Nagios prevede un sistema di alert interno, altamente configurabile in base alle esigenze (esempio: è facile implementare un sistema di invio di sms)

• Scarica tutto l’onere degli alert dai plugin, ad un sistema centralizzato di notifiche

• Lista contatti prioritaria in base ai ruoli

• Possibilità di scegliere quanto e quando comunicare gli avvisi in base alle ore della giornata o della settimana

ridondanza

Ma se dovesse essere il master controller ad avere problemi ?

• Può esistere un master-slave, adibito a compiere le stesse operazioni del master, ma con il compito aggiuntivo di monitorizzare il master

• Lo slave funziona quindi come il master, ma non lancia alert

• Se il master fallisce, un event-handler invia il comando allo slave per eleggerlo come nuovo master

• Quando il master torna operativo, un nuovo event-handler ristabilità la situazione

interfaccia web

L’interfaccia web permette di monitorare lo stato dei ser vizi, di visualizzarne il trend temporale , di interrompere gli alert, di visionare lo stato degli host ...

interfaccia web

interfaccia web

interfaccia web

interfaccia web

configurazione

•La prima configurazione ha u n e l e v a t a c u r v a d i apprendimento

•Non c’è nessuna interfaccia grafica di configurazione, si lavora nel classico “unix style” agendo sui singoli file di configurazione

•Configurazione ad “oggetti” (estendibile)

case study

La versatilità di Nagios è applicabile anche nella IT Security, sfruttando Nagios come sonda per monitorare costantemente lo stato della sicurezza degli host o dei servizi facendo pervenire comunicazione immediata e/o prendere contromisure specifiche.

Nel nostro caso si doveva contrastare una vulnerabilità di una web-app fino a che non fosse stata implementata la soluzione definitiva alla falla di sicurezza.

case study

case study

conclusioni

Ma è veramente tutto così bello ?

Quasi, poichè a fronte di un sistema completo, configurabile, altamente flessibile ci sono alcune criticità da affrontare:

• il rischio di “falsi positivi” inizialmente è molto elevato

• bisogna quindi prevedere un significativo investimento di tempo iniziale per l’apprendimento e la configurazione

• è necessario conoscere bene cosa e come verificare, quindi avere un’ampia conoscenza dei propri sistemi ( applicativi e sistemistici )

• è alto il “rischio” che nel periodo di configurazione e di analisi, si riscontrino criticità nel proprio sistema e che prima non erano mai venute fuori (ma è veramente una cosa negativa ?)