2009-03-03 15 views
7

Sono interessato a sapere se esiste un'alternativa a rrdtool per la registrazione dei dati delle serie temporali. Sto guardando qualcosa che può scalare per un gran numero di dispositivi da monitorare.alternativa strumento rrd per volume elevato

Da ciò che ho letto su questo argomento, rrdtool è legato all'I/O quando lo si colpisce con grandi quantità di dati. Dal momento che immagino che questo riduca a un numero molto grande di dispositivi da monitorare, sono curioso di sapere se esiste un'alternativa che non si possa strozzare con I/O. Preferibile basato su SQL, ma non necessariamente.

Grazie

+0

Se si tratta di I/O bound, non vorrei che essere buono? Significa che puoi prendere una soluzione hardware, come RAID, dischi a stato solido e più macchine per tracciare dati non correlati? – JasonSmith

+0

anche il mio punto ... la domanda è quanto bene sia usato l'HW ... la rrdcached l'uso è abbastanza ottimale ... un database (alla fine della giornata) deve anche scrivere cose su disco, ma dal momento che è molto più generale, dubito che sarà in grado di farlo in modo efficiente come rrdtool ... –

risposta

4

Se le prestazioni di I/O sono la preoccupazione principale, si desidera esaminare qualcosa come rrdcached che è disponibile nella versione corrente (1.4) di RRDTools.

L'overhead di I/O non è una funzione dei dati in corso di scrittura, dopo ogni valore di 8 byte per origine dati. La larghezza di banda I/O deriva dal fatto che un intero settore (tipicamente 4k) deve essere letto prima di essere scritto. Improvvisamente per scrivere 8 byte hai letto/scritto 8k byte.

La rrdcached raggruppa tutte queste scritture insieme, quindi quando viene aggiornato un RRD il rapporto tra dati utili (valori DS effettivi) e dati sprecati (i byte di riserva nel settore) viene ridotto.

Tutti i RRDTools funzioneranno automaticamente con rrdcached quando lo rilevano in esecuzione (tramite una variabile di ambiente). Ciò consente loro di attivare flussi quando necessario, ad esempio quando si genera un grafico dai dati.

Mentre passare a una soluzione basata su SQL può aiutare a considerare l'I/O aggiuntivo che sarà necessario per supportare SQL. Considerando che non si tende ad utilizzare i dati RRD in quel tipo di pattern di accesso casuale, un database è un po 'un martello per il problema. Mentre si attacca a RRDTool manterrà l'accesso a tutti gli ecosistemi di strumenti che comprendono e possono funzionare con i file, il che è utile soprattutto se si è già familiari con esso.

2

Un mio amico ha fatto un certo lavoro qualche tempo fa su un back-end SQL per memorizzare i dati di turno robin: http://rrs.decibel.org

Tuttavia, ho il sospetto che da quando si sta chiedendo di "dispositivi per il monitoraggio" , potresti essere alla ricerca di una soluzione più completa.

+0

L'ho trovato nella mia ricerca. Non ho cercato di essere mantenuto, quindi ero un po 'riluttante a considerarlo. – SorinV

+0

L'ho appena scoperto, sembra che l'ultimo aggiornamento sia stato il 2005. Non significa che non funzionerebbe ora, ma non ho avuto il tempo di estrarre il tarball. : - / –

5

Ci sono alcuni database di serie temporali che hanno alta disponibilità e/o scalabilità come obiettivi.

Forse uno sguardo al

  • rrdcached, uno strato di caching in cima RRD
  • whisper, il motore di database dietro graphite
  • opentsdb è un distribuita, scalabile Database Time Series (TSDB) scritto sopra HBase
  • reconnoiter anche se il suo focus è più sul monitoraggio
1

Se le operazioni di I/O al secondo sono il collo di bottiglia principale e si sta utilizzando Linux, c'è un attacco facile che ti costa solo memoria. Utilizzare un mount tmpfs per mettere in scena le scritture RRD.

Tutte le operazioni di I/O verranno eseguite in memoria e non si verificheranno i colli di bottiglia riscontrati nell'operazione di I/O del disco (questo è ancora più veloce rispetto all'utilizzo dei dischi a stato solido).È quindi possibile utilizzare un cron job e rsync per copiare solo i RRD modificati su disco una volta ogni pochi minuti.


Creare le directory

bash-4.2# mkdir /mnt/rrd-reads 
bash-4.2# mkdir /mnt/rrd-writes 

Creare un filesystem RAM 500 MB-massimo con le opzioni appropriate

bash-4.2# mount -t tmpfs -o size=500m,mode=0750,uid=collectd,gid=collectd none /mnt/rrd-writes 
bash-4.2# echo "none /mnt/rrd-writes tmpfs size=500m,mode=0750,uid=collectd,gid=collectd 1 2" >> /etc/fstab 

Copiare i file vecchi RRD nel nuovo punto di montaggio

bash-4.2# cp -a /var/lib/collectd/rrd/* /mnt/rrd-writes 

Configurare l'applicazione RRD-scrittura di scrivere il nuovo punto di montaggio

bash-4.2# sed -i -e 's/DataDir "\/var\/lib\/collectd\/rrd"/DataDir "\/mnt\/rrd-writes"/' /etc/collectd/collectd.conf 

Impostare un job cron per sincronizzare solo i RRD modificati su disco una volta ogni 2 minuti

bash-4.2# echo "*/2 * * * * collectd rsync -a /mnt/rrd-writes/* /mnt/rrd-reads/ ; sync" > /etc/cron.d/rrd-sync 

Non dimenticare di copiare il file RRD salvato es nel punto di montaggio prima dello si avvia l'applicazione di scrittura rrd! Potrebbe essere necessario modificare lo script di init per quel servizio per assicurarsi che i file ci siano prima che inizi. Se si avvia senza i file, verranno creati nuovi file nudi e sarai molto confuso quando la directory di lettura verrà sovrascritta con RRD vuoti.

Se ad un certo punto è necessario ridimensionare la montatura tmpfs, si può fare al volo:

bash-4.2# mount -t tmpfs -o remount,size=850m /mnt/rrd-writes