Ottenere statistiche grafite accurate_counts

Question

Abbiamo un'applicazione di nodo etsy/statsd in esecuzione che scarica le statistiche in carbonio/sussurro ogni 10 secondi. Se si invia incrementi di 100 (conteggi), nei primi 10 secondi, grafite li visualizza correttamente, come:

localhost:3000/render?from=-20min&target=stats_counts.test.count&format=json 

[{"target": "stats_counts.test.count", "datapoints": [ 
[0.0, 1372951380], [0.0, 1372951440], ... 
[0.0, 1372952460], [100.0, 1372952520]]}] 

Tuttavia, dopo 10 secondi, e questo numero scende a 0, nulla e o 33.3. Alla fine si assesta a un valore 1/6 del numero iniziale di incrementi, in questo caso 16.6.

/opt/graphite/conf/storage-schemas.conf è:

[sixty_secs_for_1_days_then_15m_for_a_month] 
pattern = .* 
retentions = 10s:10m,1m:1d,15m:30d 

Vorrei ottenere i conteggi precisi, è la grafite la media dei dati nel corso dei 60 secondi finestre piuttosto che sommando forse? Utilizzando la funzione integrale, dopo qualche tempo è passato, dà ovviamente:

localhost:3000/render?from=-20min&target=integral(stats_counts.test.count)&format=json 

[{"target": "stats_counts.test.count", "datapoints": [ 
[0.0, 1372951380], [16.6, 1372951440], ... 
[16.6, 1372952460], [16.6, 1372952520]]}] 

Answer 1

Graphite data storage

Graphite gestisce la conservazione dei dati utilizzando una combinazione delle impostazioni memorizzate in storage schemas.conf e stoccaggio -aggregation.conf. Vedo che il criterio di conservazione (lo snippet dal tuo storage-schemas.conf) sta dicendo a Graphite di archiviare solo 1 punto dati per la sua massima risoluzione (es. 10s:10m) e che dovrebbe gestire l'aggregazione di quei punti dati quando i dati invecchiano e si sposta negli intervalli più vecchi (con la risoluzione inferiore definita, ad esempio 1m:1d). Nel tuo caso, i dati attraversano il successivo intervallo di conservazione a 10 minuti e dopo 10 minuti i dati verranno riavvolti secondo le impostazioni in storage-aggregation.conf.

Aggregation/Downsampling

aggregazione/sottocampionamento accade quando i dati età e cade in un intervallo di tempo che ha ritenzione risoluzione inferiore specificato. Nel tuo caso, avrai archiviato 1 punto dati per ogni intervallo di 10 secondi ma una volta che i dati superano i 10 minuti, la vecchia grafite ora memorizzerà i dati come 1 punto dati per un intervallo di 1 minuto. Ciò significa che devi dire alla grafite come impiegare i 10 secondi di dati (di cui hai 6 per minuto) e aggregarli in 1 punto dati per l'intero minuto. Dovrebbe media? Dovrebbe sommarsi? A seconda del tipo di dati (ad es. Tempi, contatore) questo può fare una grande differenza, come hai accennato nel tuo post.

Per impostazione predefinita, la grafite media i dati mentre vengono aggregati in dati a bassa risoluzione. Usare la media per eseguire l'aggregazione ha senso quando viene applicato ai dati del timer (e persino del calibro). Detto questo, hai a che fare con i contatori, quindi vorrai la somma .

Ad esempio, in storage aggregation.conf:

[count] 
pattern = \.count$ 
xFilesFactor = 0 
aggregationMethod = sum 

UI (e dati grezzi) aggregazione/sottocampionamento

E 'anche importante capire come i dati aggregati/ricampionate è rappresentato quando si visualizza un grafico o si guardano dati grezzi (json) per periodi di tempo diversi, poiché le soglie dello schema di conservazione dei dati influiscono direttamente sui grafici. Nel tuo caso stai interrogando render?from=-20min che attraversa il tuo limite di 10s: 10m.

La grafite visualizza (ed esegue il downsampling in tempo reale di) i dati in base alla precisione con la risoluzione più bassa definita.Detto in altro modo, significa che se si tracciano dati che si estendono su uno o più intervalli di conservazione, si otterranno i rollup di conseguenza. Un esempio può essere d'aiuto (assumendo la conservazione di: ritenzioni = 10s: 10m, 1m: 1d, 15m: 30d)

Qualsiasi grafico con dati non più vecchi degli ultimi 10 minuti visualizzerà aggregazioni di 10 secondi. Quando superi la soglia dei 10 minuti, inizierai a visualizzare i dati del conteggio di 1 minuto arrotolati secondo la policy impostata in storage-aggregation.conf.

Riepilogo/tldr;

perché sei di grafica/query per 20 minuti di dati (ad esempio render?from=-20min) si sono sicuramente cadere in una posizione più bassa stoccaggio precisione (cioè 10s: 10m, 1m: 1d, 15m: 30d) che significa che L'aggregazione si sta verificando in base alla politica di aggregazione. È necessario confermare che si sta utilizzando sum per lo schema corretto nel file storage-aggregation.conf. Inoltre, è possibile ridurre l'intervallo di tempo del grafico/query a meno di 10 minuti, evitando così il rollup dinamico.