2013-07-04 31 views
15

我們已經運行了etsy/statsd節點應用程序,每10秒將統計信息刷新爲碳/耳語。如果你送100度的增量(計數),在第10秒,石墨顯示它們正確,如:獲得準確的石墨統計信息

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]]}] 

然而,10秒之後,這個數字下降到0,空,或33.3。最終它以初始增量數的1/6定值,在這種情況下爲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 

我想獲得準確計數,是石墨超過60秒窗口均數據,而不是也許總結呢?使用積分功能,一段時間過後,顯然給:

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]]}] 

回答

27

Graphite data storage

石墨使用存儲在存儲schemas.conf存儲的設置組合管理數據保留-aggregation.conf。我發現您的保留策略(來自storage-schemas.conf的片段)告訴Graphite僅存儲最高分辨率的1個數據點(例如10s:10m),並且它應該在數據老化時管理這些數據點的聚合進入較早的時間間隔(定義了較低的分辨率 - 例如1m:1d)。在你的情況下,數據在10分鐘時進入下一個保留時間間隔,10分鐘後數據將按照storage-aggregation.conf中的設置累積。

Aggregation/Downsampling

聚合/下采樣發生年齡時數據並落入具有指定的分辨率低的保留的時間間隔。就你而言,你將每隔10秒存儲一個數據點,但是一旦數據超過10分鐘,老石墨現在將數據存儲爲1個數據點,間隔1分鐘。這意味着您必須告訴石墨應該如何處理10秒的數據點(其中您有6分鐘的數據點),並在整個分鐘內將它們聚合爲1個數據點。它應該平均嗎?它應該和?根據數據類型(例如計時,計數器),這可能會產生很大的不同,正如您在帖子中暗示的那樣。

默認情況下,石墨將平均數據,因爲它聚合成較低分辨率的數據。應用於定時器(甚至衡量)數據時,使用平均值執行聚合是有意義的。這就是說,你正在處理櫃檯,所以你想要總和

例如,在存儲aggregation.conf:

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

UI(和原始數據)聚集/下采樣

同樣重要的是瞭解聚集/下采樣數據是如何表示的查看圖形或查看不同時間段的原始(json)數據時,數據保留模式閾值直接影響圖形。在你的情況下,你正在查詢render?from=-20min,它跨越你的10s:10m邊界。

石墨將根據定義的最低分辨率精度顯示(並執行)數據的實時下采樣。換言之,這意味着如果您繪製的數據跨越一個或多個保留時間間隔,則會相應地進行彙總。一個例子會有所幫助(假設保留時間= 10秒:10分鐘,1分鐘:1分鐘,15分鐘:30分鐘)

任何含有最近10分鐘數據的圖表將顯示10秒聚合。當您超過10分鐘的閾值時,您將開始根據storage-aggregation.conf中設置的策略看到1分鐘的累計計數數據。

摘要/ tldr;

因爲你作圖/查詢20分鐘值得你肯定落入較低精度存儲設置數據(例如render?from=-20min)的(即,10秒:10米,1米:1D,15M:30D),這意味着根據您的聚合策略,聚合正在發生您應該確認您正在使用sum獲取storage-aggregation.conf文件中的正確模式。此外,您可以縮短圖表/查詢時間範圍到少於10分鐘,這將避免動態彙總。

+0

查看'render?from = -10min'時,它可以正常工作,所以您可以在那裏找到它,謝謝。然而,在'storage-aggregation.conf'中,我有那些總結'.count'指標的行,所以它似乎是石墨/碳的動態/永久聚合(我不太確定永久下采樣是誰)忽略了這一點。我懷疑這是石墨的一個缺陷(v0.9.10),關於如何/可能會有什麼錯誤的任何建議。我停下來重新啓動carbon-cache.py。我需要對石墨做同樣的更改才能生效嗎? – AJP

+2

如果在存儲度量標準後(在whisper = graphite的存儲器中)更改了模式或聚合設置,則需要刪除指標的.wsp文件(石墨將重新創建它們)或運行whisper-resize.py。您可以通過針對.wsp文件運行whisper-info.py來查看一些耳語數據來驗證設置。在/ graphite/storage/whisper /中找到.wsp文件,查看其中一個指標並驗證設置。運行:'whisper-info.py my_metric_data.wsp'。 whisper-info.py輸出應該告訴你更多關於存儲設置的工作方式。 –

+0

請幫助我http://stackoverflow.com/questions/20433697/graphite-returning-incorrect-datapoint – GJain