Monitoraggio Open Source: Icinga e Nagios a confronto
Recentemente un cliente ci ha chiesto di confrontare Nagios Core e Icinga Core, ed abbiamo avuto il permesso di pubblicare i risultati su SOS Open Source.
Alcune informazioni su Nagios ed Icinga.
Nagios – il cui nome è un acronimo ricorsivo (“Nagios Ain’t Gonna Insist On Sainthood”) che si riferisce ironicamente al primo nome del programma NetSaint, sostituito per evitare problemi legati al marchio – è una delle più note piattaforme open source per il monitoraggio di apparati di rete. Durante gli ultimi 11 anni Nagios è stato progettato e sviluppato da Ethan Galstad, che ultimamente ha iniziato a delegare attività di sviluppo e gestione, una transizione da tempo attesa.
Icinga è un “fork” di Nagios avviato poco più di un anno fa, la cui ambizione è quella di creare un progetto orientato alla comunità, anche se non mancano motivazioni di origine economica.
Sostenibilità di Nagios ed Icinga.
La Sostenibilità considera la Maturità (Nagios ha una lunga storia, mentre Icinga è un progetto giovane), la Stabilità (entrambi stabili e manutenuti), la Popularità (Nagios è molto popolare, Icinga sta iniziando a farsi conoscere), la Disponibilità di Libri (sono disponibili molti libri su Nagios, mentre non ne esistono su Icinga), la Dimensione della comunità (Nagios ha un team di oltre 10 committer, ma solo 3 di essi hanno contribuito codice nell’ultimo anno; Icinga ha oltre 10 committer effettivi) ed il Stile di gestione della comunità (Icinga è un progetto di comunità, mentre Nagios da una conduzione basata sul “dittatore benevolente” si sta orientando verso un approccio orientato alla comunità).
Livello di Industrializzazione di Nagios ed Icinga.
Il livello di industrializzazione valuta diversi fattori, tra cui: Formazione (per Nagios sono disponibili in molti paesi servizi formativi, per Icinga solo credativ offre servizi), Supporto commerciale (Nagios è supportato professionalmente anche da realtà diverse da Nagios Enterprise, mentre Icinga è supportato professionalmente solo dalla azienda più attiva nella comunità), Documentazione (documentazione su Nagios è disponibile in molte lingue, per Icinga in tedesco ed inglese), Packaging (Icinga è disponibile anche come virtual appliance). Entrambi i progetti rispondono con prontezza ed efficacia alle segnalazioni di bachi. Per quanto riguarda i Commenti nel codice (Icinga è più commentato rispetto a Nagios), ed infine la Modularità (Nagios è l’unico a rendere disponibili tools per creare estensioni, unitamente ad una piattaforma per la condivisione di progetti relativi a Nagios).
Strategia di Nagios ed Icinga.
La strategia copre gli aspetti riguardanti la Licenza (entrambi rilasciati in GPLv2), la Roadmap (Icinga ha una roadmap dettagliata e rispettata, la roadmap di Nagios Core è poco dettagliata mentre la roadmap relativa ai plug-in risulta più dettagliata), Evolvibilità del codice (Nagios mette a disposizione tools per proporre modifiche, Icinga non ha simili tool o procedure) e gli Sponsor (Nagios Enterprise sponsorizza lo sviluppo di Nagios, Icinga è sponsorizzato da una comunità eterogenea).
Conoscere la storia recente di Nagios ed Icinga è utile per comprendere al meglio le dinamiche che sottointendono al loro sviluppo. Da quando il “fork” Icinga è nato, oltre 18 mesi fa, Nagios ha sviluppato un diverso approccio allo sviluppo e verso la comunità. Ad esempio rendendo disponibile una unica interfaccia per tutte le segnalazioni di bachi, ma anche altri utili strumenti atti a estendere la partecipazione. Nel frattempo la Icinga è cresciuto più velocemente, ma la comunità ancora non dispone di strumenti che semplifichino la partecipazione. In sintesi, entrambi i progetti stanno lavorando per rafforzare le loro comunità ed incoraggiare lo sviluppo collaborativo.
Aziende ed organizzazioni interessate a selezionare uno di questi progetti devono tener conto delle loro specifiche esigenze. Ad esempio realtà interessate ad una alternativa open source per il monitoraggio di sistemi pronta per l’uso preferiranno programmi facili da provare, installare e configurare. La disponibilità di plug-in, estensioni ed altri add-on costituiscono altri importanti elementi di valutazione.
System integrator e chi utilizza componenti open per costruire la proprio offerta, dovrebbero invece valutare quale progetto si adegui meglio al loro stile (commensalistico o simbiotico) e tipo di contribuzione (codice, documentazione, plug-in, estensioni, ecc).
VAR e solution providers sono probabilmente più interessati ai partner program, i programmi di certificazione e le certificazioni di compatibilità, ed altri strumenti similari.
Qualunque sia la vostra motivazione per scegliere una o l’altra opzione, la presenza di due piattaforme open source per il monitoraggio che competono partendo dalla stessa base di codice può favorire una maggiore innovazione.
