Devo sostituire Munin con qualcosa di più scalabile [chiuso]

Ho usato munin su più server per molti anni con grande successo, tuttavia con più di 100 nodi munin e quando c'è carico sui client, l'elaborazione sta scadendo.

Ho apportato alcune modifiche al ridimensionamento del processo cron e al numero di processi client e ridotto il numero di plugin in esecuzione ecc., Ma ho deciso di cercare un'alternativa con un'architettura più scalabile.

Eventuali suggerimenti o esperienze sarebbero i benvenuti. Sono sostanzialmente interessato alle metriche del server che possono essere utilizzate per pianificare la capacità e diagnosticare l'utilizzo delle risorse. (abbiamo nagios per avvisare)

Sembra che potresti avere due problemi

1. Sul tuo server di monitoraggio, la registrazione delle metriche per molti server richiede più I / O casuali di quelli che la tua memoria può fornire. Anche se tutte le metriche vengono scritte su disco, il server potrebbe essere troppo sovraccarico per generare effettivamente dei grafici da esse.
2. Quando i tuoi client vengono monitorati, i plug-in che raccolgono le metriche richiedono troppo CPU e memoria e non finiscono di raccogliere i dati in tempo quando i client hanno un carico pesante.

Ho usato Munin in passato, ma attualmente sto usando collectd . Gli autori di collectd hanno dedicato molta attenzione e impegno alla soluzione di questi problemi. Hanno un sistema ben progettato per scrivere i dati in file RRD che ti assicura di non perdere i dati e di generare grafici aggiornati. C'è anche il supporto per RRDCacheD. Il demone e i plugin ufficiali sono scritti in C, quindi usano poca memoria o tempo della CPU. Sui sistemi client utilizza meno di 2 MB di RAM e circa un quarto di secondo della CPU ogni minuto. Sul mio server di monitoraggio utilizza ogni giorno 20 MB di RAM e due terzi di secondo della CPU. Tieni presente che tutte le mie metriche vengono raccolte e inviate al mio server di monitoraggio ogni dieci secondi, anziché a intervalli di minuti come Munin.

Sebbene siano ottimi strumenti, Munin e altri frontend RRDTool (come Cacti o Ganglia) hanno problemi di I / O noti e sono difficili da ridimensionare quando si monitorano centinaia di nodi.

Ci sono alcune tecniche per affrontare questo collo di bottiglia di I / o. Una di queste tecniche è quella di diffondere le scritture su un gran numero di dischi per ridurre l'I / O in ciascun disco. D'altra parte, molti amministratori di sistema usano i filesystem tmpfs per affrontare questo problema. RRDCached è anche un'opzione recente e buona per affrontarlo e ti consiglio di dare un'occhiata a queste diapositive .

Non ho molta familiarità con Munin, ma Cacti ha un plugin Boost . Questo plugin memorizza nella cache i dati in memoria ed esegue aggiornamenti di massa e su richiesta sul disco, anziché le singole scritture, riducendo così gli I / O. Sono abbastanza sicuro che anche Munin abbia qualcosa del genere.

Se puoi permetterli, anche i dischi SSD sono buone opzioni.

Ultimo ma non meno importante, puoi anche dare un'occhiata a Reconnoiter . Recconoiter è un nuovissimo strumento di rilevazione guasti e rappresentazione grafica / trend. A differenza della maggior parte degli strumenti di tendenza, Reconnoiter non è basato su RRDTool e cerca di risolvere questo problema specifico. Non sto usando Reconnoiter in produzione, ma ho fatto alcuni test e, nonostante sia ancora un po '"verde", sembra davvero promettente, soprattutto per quanto riguarda la sua scalabilità.

Spero che sia di aiuto!

Dai un'occhiata a Zabbix . È uno dei migliori strumenti di monitoraggio delle prestazioni Open Source in circolazione. Si adatta bene ed è stato utilizzato in ambienti con migliaia di computer.

Marco Ramos dà alcuni solidi consigli. Voglio aggiungere alcuni chiarimenti, tuttavia: il grosso problema con Munin è che è fissato un programma di raccolta di 5 minuti. Se tutti i nodi non restituiscono risultati entro la finestra di 5 minuti, inizi a ricevere i dropout. Questo è il problema più grande con Munin.

Altri strumenti basati su rrdtool come Ganglia non sono bloccati nella stessa finestra di aggiornamento di 5 minuti perché non eseguono il polling di tutte le origini dati nello stesso modo sequenziale di Munin.

Ti consiglierei di guardare Ganglia perché in genere sembra ridimensionare bene (anche se è necessario disattivare la raccolta dati multicast per un'installazione di ganglia di grandi dimensioni). Ho il sospetto che tu possa fare molta strada con i gangli prima che tu debba iniziare a preoccuparti che rrdtool sia il punto di strozzamento. A quel punto puoi fare il genere di cose che Marco suggerisce, come usare le unità SSD.

Sto sostituendo Munin con Ganglia, Munin uccide il mio server quindi proverò Ganglia a vedere come si ridimensiona.