Pianificazione della capacità del disco per Whisper / Graphite

Qualcuno ha delle formule o forse alcuni dati di esempio dal loro ambiente che possono aiutarmi a stimare quanto spazio su disco verrà utilizzato dalla grafite per punto dati?

whisper-info.py ti dà molte informazioni su cosa e come ogni file è aggregato, inclusa la dimensione del file.

Tuttavia è utile solo per i file di sussurri esistenti.

Quando vuoi vedere il dimensionamento predittivo di uno schema prima di metterlo in atto, prova un Whisper Calculator, come quello disponibile su https://gist.github.com/jjmaestro/5774063

MODIFICARE:

Alla domanda per un esempio ...

storage_schema:

{
    :catchall => {
      :priority   => "100",
      :pattern    => "^\.*",
      :retentions => "1m:31d,15m:1y,1h:5y"
    }
}

Guardando il mio file applied-in-last-hour.wsp, i ls -lrendimenti

-rwxr-xr-x 1 root root 4415092 Sep 16 08:26 applied-in-last-hour.wsp

e whisper-info.py ./applied-in-last-hour.wsprese

maxRetention: 157680000
xFilesFactor: 0.300000011921
aggregationMethod: average
fileSize: 4415092

Archive 0
retention: 604800
secondsPerPoint: 10
points: 60480
size: 725760
offset: 52

Archive 1
retention: 2678400
secondsPerPoint: 60
points: 44640
size: 535680
offset: 725812

Archive 2
retention: 157680000
secondsPerPoint: 600
points: 262800
size: 3153600
offset: 1261492

Quindi, fondamentalmente, combini i tuoi host per corrispondenza di conservazione per segmento di periodo di conservazione per stat, moltiplicando per un fattore di sistemi che intendi applicare anche questo, fattore per il numero di nuove statistiche che seguirai. Quindi prendi qualsiasi quantità di spazio di archiviazione che sia e almeno il doppio (perché stiamo acquistando spazio di archiviazione e sappiamo che lo useremo ...)

Nella documentazione di statsd forniscono un esempio di una politica di conservazione dei dati.

Le ritenzioni sono 10s:6h,1min:7d,10min:5y2160 + 10080 + 262800 = 275040 punti dati e danno una dimensione dell'archivio di 3,2 MiB .

Supponendo una relazione lineare, si tratterebbe di circa 12,2 byte per punto dati .

Nessuna esperienza diretta con la grafite, ma immagino che si applicherebbe la stessa logica che abbiamo usato per Cacti o qualsiasi altra cosa RRD o time-rollover guidato (Graphite non utilizza più RRD internamente ma la logica di archiviazione sembra comparabile).

La risposta rapida è "Probabilmente non tanto spazio quanto pensi di aver bisogno."

La lunga risposta riguarda alcuni calcoli matematici specifici del sito. Per il nostro sistema di monitoraggio (InterMapper) capisco i periodi di conservazione, le risoluzioni e le dimensioni del punto dati, eseguo alcuni passaggi e aggiungo un overhead.

Ad esempio, userò lo spazio su disco: memorizziamo cifre con una precisione di 5 minuti per 30 giorni, una precisione di 15 minuti per altri 60 giorni e quindi una precisione oraria per altri 300 giorni e stiamo usando un 64 -bit (8 byte) intero per memorizzarlo:

• 21600 campioni totali, suddivisi come:
  • 8640 campioni per la precisione di 5 minuti in 30 giorni
  • 5760 campioni per la precisione di 15 giorni in 60 giorni
  • 7200 campioni per la precisione di 1 ora di 300 giorni

A 8 byte per campione pari a circa 173 KB, oltre a un sovraccarico salutare per l'indicizzazione dello storage e simili lo porta a circa 200 KB per i dati di utilizzo del disco di una partizione (qualsiasi errore tendente alla sovrastima).

Dalle metriche di base sono in grado di calcolare una dimensione media "per macchina" (10 partizioni del disco, spazio di scambio, RAM, media del carico, trasferimento di rete e poche altre cose) - funziona a circa 5 MB per macchina.

Aggiungo anche un sano 10% sopra il numero finale e arrotondando per eccesso, quindi ridimensiono le cose a 6 MB per macchina.

Quindi guardo 1 TB di spazio che ho in giro per l'archiviazione dei dati delle metriche per la creazione di grafici e dico "Sì, probabilmente non esaurirò la memoria nella mia vita a meno che non cresciamo molto!" :-)

Ho 70 nodi che generano molti dati. Usando Carbon / Whisper, un nodo ha creato solo 91k file (il nodo genera più schemi ciascuno con più contatori e campi variabili che devono essere selezionabili, ad esempio: (nodename). (Schema). (Counter). (Subcounter). (Ecc. )....e così via).

Ciò ha fornito la granularità di cui avevo bisogno per tracciare qualsiasi grafico che desidero. Dopo aver eseguito lo script per popolare i rimanenti 69 nodi, avevo 1,3 TB di dati sul disco. E questo è solo 6 ore di dati / nodo. Quello che mi prende è il file CSV piatto effettivo per 6 ore di dati è di circa 230 Mb / nodo. 70 nodi sono ~ 16Gb di dati. Il mio schema di archiviazione era 120s: 365d.

Sono relativamente nuovo nei database, quindi potrei fare qualcosa di sbagliato, ma suppongo che sia il sovraccarico per ogni campione.

Quindi è stato un esperimento divertente, ma non credo abbia senso usare il sussurro per il tipo di dati che sto archiviando. MongoDB sembra un soluton migliore, ma devo capire come usarlo come backend per Grafana.