Come riportato nel precedente testo “La notifica che fa la differenza”, l’installazione e la configurazione di un sistema di monitoring della propria infrastruttura è ormai una prassi consolidata di ogni amministratore che non solo vuole dormire sonni tranquilli, ma passare anche giornate serene al lavoro.
Tutto si rompe, l’importante è sapere quando. Ricevere un avviso quando si predispone una situazione potenzialmente pericolosa può essere un passo fondamentale, ma abbiamo la possibilità di fare di più e di analizzare in modo dettagliato le prestazioni dei nostri sistemi.
Quali sono le nostre aspettative dal sistema di monitoring della nostra infrastruttura?
Analisi dello stato di salute
Come per un paziente di cui stiamo rilevando la frequenza del battito cardiaco, il livello di ossigenazione e la pressione sanguinea, anche per i nostri dispositivi è utile avere un sistema di analisi sempre attivo.
I livelli di occupazione di cpu, ram e disco, in un determinato intervallo di tempo di una virtual machine, rappresentano gli indici principali per definire l’efficienza operativa di quella macchina e dei servizi che deve erogare.
Questa funzione va svolta per 2 principali motivi: invio automatico di alert per segnalare valori impropri di queste variabili, ma anche la registrazione dell’andamento giornaliero/settimanale dei nostri sistemi.
Così come l’analisi di un tracciato di un elettrocardiogramma effettuato sotto sforzo può darci importanti indicazioni, in egual modo l’analisi dell’andamento delle variabili principali di una virtual machine può indicarci che un determinato applicativo svolge determinate attività che mettono a dura prova il sistema.
La fatturazione massiva in automatico è un processo particolarmente lento? In questo caso dobbiamo semplicemente aumentare le risorse (quante volte gli sviluppatori o i consulenti applicativi ci chiedono di estendere la RAM).
Ci sono particolari fasce orarie in cui i nostri utenti lamentano prestazioni non accettabili per determinati servizi? Forse abbiamo processi del sistema antivirus o del sistema di backup che appesantiscono i device durante la loro esecuzione, per cui è importante che il nostro sistema di monitoring sia parametrizzabile per seguire nello specifico l’andamento di questi applicativi.
Non mi rispondi più, tutto bene?
Quante volte la mancanza di comunicazione da parte di un amico importante, ci pone il dubbio che possa avere qualche grave problema.
Allo stesso modo il nostro sistema di monitoring deve contattare programmaticamente sistemi, applicativi e servizi per valutare quanto questi siano ancora funzionanti.
Su questo c’è una storica scelta di campo: mi chiami tu o ti chiamo io?
È il monitoraggio ad inviare le richieste di contatto o sono i sistemi a comunicargli la loro disponibilità?
La risposta corretta è che dipende dalla posizione di entrambe le parti. Se i nostri sistemi sono geograficamente distribuiti ed il monitoraggio è interno alla nostra rete, è indispensabile che sia quest’ultimo ad effettuare il controllo.
Risulta ottimale un sistema di monitoraggio che permette entrambe la modalità, in modo che possa essere configurato opportunamente in funzione della necessità.
E se il device non risponde? Siamo abituati a pensare che è sufficiente verificare costantemente la disponibilità di device di rete, di macchine virtuali, ma sempre più risulta utile anche la verifica di determinati processi.
Il backup non è stato completato? Forse è solo l’agente sul client che non è attivo. Potevo monitorarlo specificatamente.
Funziona, ma potrebbe andare meglio
Almeno una volta abbiamo ricevuto questa segnalazione dai nostri utenti relativamente alle prestazioni di un determinato applicativo e non sempre la risoluzione è stata semplice.
Sarà il database o sarà l’application server? Più precisamente cosa dobbiamo configurare in modo diverso per migliorare le prestazioni?
La maggior parte dei sistemi di monitoraggio permettono l’installazione di moduli specifici sia per i database che per i contesti degli applicativi web.
L’analisi del tracciato ci indica la normale modalità operativa, ci permette di inserire alert specifici e di di ricevere segnalazioni quando abbiamo livelli operativi fuori dalla norma.
Il nostro database ha un numero di transazioni in coda troppo elevato? La scrittura dei log è troppo rallentata?
Il garbage collector non lavora in modo adeguato? Thread e heap memory non sono sempre banali da monitorare, ma se avessimo una dashboard con i flussi delle variabili principali, potremmo capire se il motore del nostro applicativo sta lavorando in modo ottimale o meno.
E’ sembrato anche a te di vedere qualcosa di strano?
“Te l’avevo detto”, comincia così la frase di un amico complottista che ha finalmente la dimostrazione che una sua teoria ritenuta tanto assurda, è invece la triste realtà.
Importante sapere cosa monitorare, utile tenere un occhio aperto sul resto. Facile a dirsi, più complicato da mettere in pratica, perché se non lo sappiamo a priori, non sappiamo specificatamente cosa cercare.
Il traffico rete di una azienda ha determinati flussi in entrata ed in uscita piuttosto costanti in funzione del giorno e della fascia oraria.
Un numero elevato di richieste al fileserver in orario notturno di un giorno festivo, deve sicuramente farci venire qualche ragionevole dubbio.
Continui tentativi di accesso ad un nostro applicativo web pubblicato su Internet da parte di IP geolocalizzati molto lontani da noi, deve attivare sistemi automatici di mitigazione prima e di negazione della comunicazione poi.
Molti sistemi, purtroppo spesso con costi tutt’altro che irrisori, analizzando costantemente il traffico di rete e i log dei nostri sistemi costruiscono basi di dati di veri e propri sistemi di intelligenza artificiale che ci segnalano anomalie o situazioni non standard.
Queste analisi si confrontano con una serie di best practies che indicano le configurazioni non ottimali, quelle potenzialmente pericolose e suggeriscono anche gli interventi correttivi da mettere in campo.
Può sembrare l’amico saputello che ne sa più di te e non manca di dimostrartelo, ma tutto questo porta l’amministratore di sistema ad essere più conscio dello stato generale della propria infrastruttura.
D’altronde un famoso detto recita: “prevenire è meglio che curare”
