statsd on steroid

Why Statsd

Statsd 模式最大的好處是兩點

• 上報數據者直接是結果的受益者，並對其負責：由於上報數據的人直接是對最終的圖表和監控負責的，他有最大的動機去選取合適的指標來幫助本身理解被監控的代碼。這種模式能夠避免「玩日誌」的那幫人和那些平臺出現。處理數據的人若是不負責被監控的業務，而上報數據的人不直接決定最終的圖表，那麼兩方都作很差。

• 中心化的設計：全部的大數據平臺都是基於分佈式的。而最多見的問題是數據上報的時候的節點分佈和業務指標統計時所須要的節點分佈不一樣，致使多個stage之間shuffle數據產生大量的開銷。而statsd簡化的設計的一個偶然的結果就是由於數據從上報是直接出結果的，因此一個指標所須要的數據是之接上報給同一個物理節點的。不少複雜的聚合計算從而變成可能。

• 數據上報和計算公式二合一：每次上報的數據裏都包含了計算所須要的全部元信息（好比計算公式）。省去了註冊計算公式的操做，以必定運行時開銷的方式簡化了使用，並且讓數據和數據計算方式的定義二者同時在一塊兒簡化了總體的維護成本。

監控最重要的是度量整個被監控的對象是否 「is getting work done」，就是要不斷關注是否有產出。而關注一個系統是否有產出，就要對這個系統的模型要有理解。statsd作爲很方便的工具，具備很是多的優勢。若是statsd更進一步，內置的aggregator不只僅是counter/gauge這樣的對上報數據的膚淺理解，而是可以從模型的角度更深度地瞭解上報的數據的含義，那麼statsd能夠更加大放光芒~

業務指標監控：線性Funnel

最通用的關於業務的建模是所謂的Business Process，或者說是某種Funnel。好比

基於全部的業務場景均可以用上面這樣的Funnel模型來建模。而從業務角度來講就是關注兩點：

• 實現這個業務流程的IT系統有沒有出問題，是否是有人發了單，可是沒有訂單並無真正被收到，或者流程被「卡」在某一步了。

• 全部階段的業務指標（絕對量或者轉化率）是否顯著低於歷史同期（同比）或者前幾分鐘（環比）

對於一個監控系統來講就是要提供一個方便的接口讓業務直接上報每一個階段的數據，而後自動把業務關心的指標統計出來並告警。從IT系統監控的角度來講無需多維，無需複雜如Mixpanel或者Kissmetrics那樣，能夠簡單的提供這樣一個上報接口

1000897
sales_funnel
stage=01/estimate
f

或者

1000897
sales_funnel
stage=03/new_order
f

這些數據包含了三個信息：

• 1000897 訂單id，或者說是其餘某種流量id

• 對應哪一個funnel stage，這裏是 new_order

• 當前時間，這個是隱含的就是收到這條消息的時間

這些數據還包含了三個元信息：

• 我須要用funnel模型對數據進行統計並告警

• 這個funnel名叫sales_funnel，全部對同一個funnel的數據上報統一計算

• 03/new_order 說明了當前stage在funnel裏的位置，其實也就是用index註冊了一個新的funnel，可是並不須要使用者去註冊，只須要報數據就行了

利用上報的數據就能夠統計出

• 每一個階段的流量

• 每一個階段到下一個階段的轉化率

• 每一個階段到下一個階段的停留時間

• 還有多少流量停留在某個具體階段

複雜一點還須要支持超時，就是時間過去一段時間以後自動轉換爲另一個狀態，好比新的訂單若是遲遲沒有到下一個階段就自動認爲做廢了。這些指標去作同比環比的對比，就能夠得出很是有意義的業務告警了。

業務指標監控：重複性Funnel

重複性Funnel和簡單線性Funnel的區別是中間會有重複性的步驟。重複性的步驟在業務上多是相似於實時計價這樣的重複性動做，也多是系統設計裏相似心跳這樣的設計。對於重複性Funnel，上報的時候須要添加一個標誌位來講明這個stage是否是重複性的。這樣能夠統計出一個關鍵指標

• 基於前一個stage和後一個stage得出還有多少流量應該停留在當前的stage

• 基於重複性動做以心跳的形式計算出當前stage還有多少流量active

• active流量和理論流量的比例

這樣能夠得出當前這個stage後面對應的IT系統是否是有故障了，好比是否是客戶端上報遇到了困難，或者服務器掛掉了。

系統指標監控：RPC

另一個告警的層面是從系統架構的角度來建模。最多見的系統的模型就是一個RPC鏈條。A調用了B，B調用了C。能夠把statsd擴展爲這樣的形式

0.53,error
my_srv/rpc
caller=/login
callee=http://passport.com/validate
rpc

這裏包含了四個信息：

• 主調方：/login

• 被調方：協議是 http，服務 passport.com，具體的接口 validate

• 延遲：0.53 秒

• 狀態碼：error

利用這些信息能夠統計出：

• rpc.counter：總調用量

• rpc.error.counter：分錯誤碼調用量

• rpc.latency：延遲的分佈

• rpc.error.ratio：全部錯誤碼加和的總錯誤量相比總調用量的比率

利用error.ratio能夠直接閾值告警，其餘值相比同比和環比也能夠告警。這些rpc指標是統計在某個namespace下的，好比上面是統計在my_srv/rpc下的。把A的被調和B的主調對應起來，就能夠把A=>B=>C這樣的串聯起來。

另外全部的Access log也能夠建模成RPC。好比

0.28,success
my_srv/rpc
caller=/login
callee=<self>
rpc

把callee去掉換成本身，不就是access log了，說明當前接口處理是否成功，花了多久。對當前接口處理的某個函數的耗時，也是某種pc（procedure call），只是否是rpc，好比

0.28,success
my_srv/rpc
caller=/login
callee=<self/some_func>
rpc

系統指標監控：隊列

系統除了用RPC建模，另一種就是隊列了（彷佛全部的架構模式最後就是這兩種作選擇)。隊列其實比RPC要複雜，也更難監控。須要生產方在生產完以後上報數據

1000897
topic1/partition1
producer=passport
queue

這個上報包含了三個信息：

• 1000897 是offset，表明了隊列裏的一條消息（id），也能夠度量隊列的長度

• topci1/partition1 表明了排隊的主體

• 生產方名叫passport

• 隱藏的信息是 1000897 的生產時間

須要消費方在消費完成以後上報數據

1000677,error
topic1/partition1
consumer=profile
queue

這個上報包含了三個信息：

• 1000677 消費到了哪一個offset

• topci1/partition1 表明了排隊的主體

• 消費方名叫profile

• 隱藏的信息是 1000677 被profile消費的時間

這樣就能夠統計出

• 每一個消費者本身的隊列長度，好比profile還有多少消息須要消費

• 每一個消費者本身隊列的消費時間分佈，從入隊列到消費完成。這個是利用了收到產生消息和收到消費消息的時間點。

• 每一個消費者的錯誤率

• 每一個生產者產生了多少消息

核心點

全部以上構想的功能若是有一點吸引力，那主要是由於上報數據的人懶。這也是statsd的核心思想，它作了複雜的事情（有狀態），因此你能夠變得簡單。好比咱們能夠在訂單被接了以後上報的數據包含訂單是何時發出來的，這樣是簡化了statsd，可是對於statsd的使用方來講就必須記錄和上報這個訂單是什麼發出來的。也許你會說業務原本就記錄了這些，可是也許你上報的地方可能沒有讀數據庫呢？也許就是懶呢？

咱們須要一個statsd，不可是有狀態，還能夠理解業務和系統模型。從而使得使用方能夠很是簡單，在每一個節點上無狀態地上報當前階段有的信息。讓statsd本身去聚合這個時間片的指標，聚合關聯流程上下游的指標，聚合關聯同比和環比的指標。直接出圖。直接告警。just works。