StatsD/Graphite命名約定的指標

Question

我正在開始檢測Web應用程序並使用StatsD儘可能多地收集相關指標的過程。舉例來說，這裏是我目前使用的高級別指標名稱的幾個例子：

http.responseTime 
http.status.4xx 
http.status.5xx 
view.renderTime 
oauth.begin.facebook 
oauth.complete.facebook 
oauth.time.facebook 
users.active 

...還有許多，許多。我現在正在努力的是爲各種度量標準建立一致的層次結構和一組命名約定，以便目前的標準具有意義，並且存在用於添加未來度量標準的邏輯分區。

我的問題是雙重的：

1. 什麼相關的指標是你收集你已經找到indespensible？
2. 您使用什麼命名結構來對指標進行分類？

Answer 1

這是有沒有明確答案的問題，但這裏是我們如何做到這一點的Datadog（我們是一個託管的監測服務，所以我們往往會迷戀這些東西）。

1.哪些指標是不可或缺的？這取決於旁觀者。但是對於每個團隊而言，在高層次上，儘可能接近其目標的度量標準（這可能不是最容易收集的）。系統指標（例如系統負載，內存等）收集起來很微不足道，但很少可操作，因爲它們太難以將它們可靠地連接到可能的原因。

另一方面，完成的產品之旅的數量對任何負責確保新用戶從使用產品的第一分鐘開始就感到滿意的任何人都很重要。 StatsD使這種東西容易收集。

我們還發現，隨着產品的不斷髮展，任何團隊變更的關鍵指標的核心組合都會發生變化，因此連續編輯流程。

這反過來意味着公司中的任何人都需要能夠挑選哪些指標對他們重要。沒有權限問，沒有摩擦去獲取數據。

2.命名結構層次結構的最高級別是產品線或過程。我們的網頁前端在內部被稱爲dogweb，因此該組件的所有指標前綴爲dogweb.。下一層級是子組件，例如， dogweb.db.,dogweb.http.等 層級的最後一級是被測量的東西（例如renderTime或responseTime）。

石墨中的懸而未決的問題是度量標準名稱中的度量標準元數據編碼（使用*進行選擇，例如dogweb.http.browser.*.renderTime）這很聰明，但可能會妨礙您的工作。

我們最終在我們的數據模型中實現了明確的元數據，但這不是statsd/graphite，所以我會留下細節。如果您想了解更多信息，請直接與我聯繫。