Monitoraggio delle metriche utilizzando StatsD (via etsy) e Graphite, il grafico di grafite non sembra rappresentare graficamente tutti i dati

Question

Abbiamo una metrica che incrementiamo ogni volta che un utente esegue una determinata azione sul nostro sito Web, ma i grafici non lo fanno t sembra essere preciso

Quindi, stavolta da questa impressione, abbiamo investito gli aggiornamenti.log di carbonio e scoperto che l'azione era avvenuta oltre 4 mila volte oggi (usando grep e wc), ma in base al risultato Integrale del grafico restituiva solo 220ish.

Quale potrebbe essere la causa di questo? I dati vengono segnalati a statsd utilizzando la libreria php statsd e chiamando lo statsd::increment('metric'); e come detto sopra, il log conferma che oggi sono passati oltre 4.000 aggiornamenti a questa chiave.

Stiamo utilizzando:

0.9.6 grafite con statsD (Etsy)

Answer 1

Dopo aver postato il mio commento sopra ho trovato Graphite 0.9.9 ha un (nuovo?) File di configurazione, storage-aggregation.conf, in cui si può controllare il metodo di aggregazione per modello. Le opzioni disponibili sono media, somma, min, max e ultimo.

http://readthedocs.org/docs/graphite/en/latest/config-carbon.html#storage-aggregation-conf

Answer 2

Dopo alcune ricerche attraverso la documentazione, e alcune conversazioni con gli altri, ho trovato il problema - e la soluzione.

Il modo in cui è progettato il formato di file bisbiglio, si aspetta che tu (o la tua applicazione) pubblichi gli aggiornamenti non più velocemente dell'intervallo minimo nel tuo file storage-schemas.conf. Questo file viene utilizzato per configurare la quantità di conservazione dei dati che si ha in diverse risoluzioni dell'intervallo di tempo.

Il file storage-schemas.conf è stato impostato con un tempo di ritenzione minimo di 1 minuto. Il demone StatsD predefinito (da etsy) è progettato per l'aggiornamento a Carbon (il demone di grafite) ogni 10 secondi. Il motivo per cui questo è un problema è il seguente: in un periodo di 60 secondi, StatsD segnala 6 volte, ogni scrittura sovrascrive l'ultima (in quell'intervallo di 60 secondi, perché si sta aggiornando più velocemente di una volta al minuto). Ciò produce risultati davvero bizzarri sul grafico perché gli ultimi 10 secondi in un minuto potrebbero essere completamente morti e riportare uno 0 per l'attività durante quel periodo, il che si traduce nel nuotare completamente tutti i dati scritti per quel minuto.

Per risolvere il problema, ho dovuto riconfigurare il file storage-schemas.conf per archiviare i dati con una risoluzione massima di 10 secondi, quindi ogni aggiornamento da StatsD verrebbe salvato nel database di bisbiglio senza essere sovrascritto.

Etsy ha pubblicato la configurazione storage-schemas.conf che stavano usando per la loro installazione di carbonio, che assomiglia a questo:

[stats] 
priority = 110 
pattern = ^stats\..* 
retentions = 10:2160,60:10080,600:262974 

Questo ha un tempo di 10 secondi minimo di ritenzione, e memorizza 6 ore vale la pena di loro. Tuttavia, a causa del mio prossimo problema, ho esteso significativamente i periodi di conservazione.

Mentre raccoglievo questi dati per alcuni giorni, ho notato che era ancora inattivo (ed era in corso di segnalazione). Questo era dovuto a 2 problemi.

1. StatsD (versioni precedenti) ha riportato solo un numero medio di eventi al secondo per ogni periodo di rapporto di 10 secondi. Questo significa che se avessi incrementato una chiave 100 volte in 1 secondo e 0 volte per i successivi 9 secondi, alla fine del 10 ° secondo statsD riporterebbe 10 in grafite, invece che in 100. (100/10 = 10). Questo non è riuscito a riportare il numero totale di eventi per un periodo di 10 secondi (ovviamente).
   
   Le versioni più recenti di statsD risolvono questo problema, in quanto hanno introdotto il bucket stats_counts, che registra il numero totale di eventi per metrica per ogni periodo di 10 secondi (quindi, anziché riportare 10 nell'esempio precedente, riporta 100).
   
   Dopo ho aggiornato StatsD, ho notato che le ultime 6 ore di dati sembrava ottimo, ma come ho guardato al di là delle ultime 6 ore - le cose sembravano strane, e la prossima ragione perché:

2. come negozi di grafite dei dati, sposta i dati dalla ritenzione di alta precisione a una ritenzione di precisione inferiore. Ciò significa che, utilizzando l'esempio di etsy storage-schemas.conf, dopo 6 ore di precisione di 10 secondi, i dati sono stati spostati su una precisione di 60 secondi (1 minuto). Al fine di spostare 6 punti dati dalla precisione 10s a 60s, la grafite fa una media dei 6 punti dati. Quindi prenderebbe il valore totale dei 6 punti dati più vecchi e dividerlo per 6. Ciò fornisce un numero medio di eventi per 10 secondi per quel periodo di 60 secondi (e non il numero totale di eventi, che è ciò che ci interessa circa nello specifico).
   
   Questo è il modo in cui è progettata la grafite e, in alcuni casi, potrebbe essere utile, ma nel nostro caso, non è ciò che volevamo. Per "risolvere" questo problema, ho aumentato il tempo di ritenzione di precisione di 10 secondi a 60 giorni. Oltre i 60 giorni, memorizzo le precisioni minuziose e minime, ma sono essenzialmente lì senza motivo, poiché i dati non ci sono altrettanto utili.

Spero che questo aiuta qualcuno, lo so che mi ha infastidito per qualche giorno - e so che non c'è una grande comunità di persone che utilizzano questo stack di software per questo scopo, quindi è preso un un po 'di ricerca per capire veramente cosa stava succedendo e come ottenere un risultato che volevo.