JAVA,  Programmazione,  System Administration

Realizziamo un tool di services monitoring multipiattaforma, puntata 1

Puntata 1

  • Introduzione

  • Requisiti del Software

  • Le Specifiche Funzionali

Introduzione

Con questa prima puntata iniziamo una serie di articoli la cui conclusione ci porterà alla realizzazione di un tool di monitoraggio multi-piattaforma e multi-servizio, distribuito e ridondato, qualcuno di voi penserà, ma farà anche il caffè?, vedremo…

Requisiti del software

Cominciamo innanzitutto con lo stabilire quali devono essere i requisiti per l’oggetto software che andremo a costruire, innanzitutto lo strumento che svilupperemo sarà multi piattaforma, affidabile, estendibile e modulare, possibilmente semplice da installare, configurare e gestire.
Per quanto riguarda il requisito “multi piattaforma”, per realizzarlo come non pensare a JAVA, linguaggio che io in particolare apprezzo, e che ho quindi scelto come linguaggio per lo sviluppo di questo progetto, visto appunto la sua caratteristica principale riassunta in un famoso slogan “write once, runs everywhere”.

Le Specifiche Funzionali

Ora è il momento di stabilire cosa vogliamo che il nostro strumento di monitoraggio faccia per noi, “ora o mai più!!”, vabbeh più o meno… a parte battute varie, innanzitutto cominciamo con il definire di che tipologia di oggetto stiamo parlando e cioè di un agent di monitoraggio e quindi dovendo essere uno strumento di monitoraggio per servizi in generale, dovrà inviare avvisi ad un amministratore o comunque ad uno o più destinatari che siano essi delle persone fisiche o ad esempio altri sistemi, quindi diciamo che il tool dovrà inviare avvisi attraverso vari canali, attivabili o disattivabili selettivamente, il canale principale naturalmente sarà la posta elettronica, per quanto riguarda gli avvisi a destinatari umani, mentre per gli avvisi ad altri sistemi verranno inviati messaggi XML o JSON, via protocollo HTTP, i messaggi di posta elettronica che vengono inviati possono avere in allegato il file di log del servizio che è andato in fail o il tail delle ultime n righe.
Abbiamo anche detto che il tool dovrà offre una certa affidabilità quindi fornirà sistemi di auto monitoraggio, implementando, un meccanismo di heart-beating interno, funzionante se, naturalmente gli agents in esecuzione sono due o più, questo consentirà al singolo agent di monitorare gli altri facenti parte dello stesso “cluster”, se così possiamo definirlo, ogni agent produce su una determinata porta un segnale di heart-beat che consente agli altri di sapere se è “vivo” e nel caso di fail l’evento viene notifica ad uno o più destinatari, anche in questo caso utilizzando i diversi possibili canali a disposizione.
Si è parlato nei requisiti di estendibilità e modularità, infatti un agent, effettua il monitoring dei servizi di cui è responsabile attraverso dei plug-in denominati appunto “monitor”. Un monitor è un oggetto specializzato nel monitoraggio della risorsa per la quale è stato sviluppato. Le funzionalità dell’agent possono essere estese attraverso lo sviluppo di nuovi monitor che gli permettano il controllo di nuove risorse, ad esempio un agent potrebbe monitorare utilizzando gli appositi monitor, oltre che classici servizi come WebServer, FTP Server, etc. anche risorse di sistema, come filesystems, memoria e CPU, o ciò di cui si ha bisogno all’occorrenza, innestando “a caldo” i nuovi “plug-in/monitors”. Sempre in ambito di estendibilità, anche i canali di invio degli avvisi sono implementati mediante plug-in specifici denominati appunto channel.
La gestione dell’agent è possibile attraverso due tipologie di interfaccia, una shell a cui inviare comandi e un mini web server interno che espone una serie di pagine web che consentono mediante i classici controlli HTML, bottoni, campi form, link html di controllare il funzionamento dell’agent stesso, le interfacce di controllo permettono le seguenti operazioni:

  • arrestare l’agent
  • arrestare e riavviare i singoli monitor
  • spegnere e riaccendere il segnale di heart-beat dell’agent
  • fermare il ciclo di interrogazione dei segnali di heart-beat degli altri agents
  • disattivare e riattivare l’interfaccia di controllo WEB
  • disattivare e riattivare i singoli channel manager

Con questo concludo questa prima puntata dandovi appuntamento alla prossima, in cui entreremo più in dettaglio per quanto riguarda le diverse funzionalità, magari inziando a buttare giù qualche riga di codice

A presto

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *