業務實時監控的統一抽象

01-30

分層

監控可以分成這麼三層。每層有完全不同的視角：

業務層：任意的商業模式都可以建模為一個流程，流程都可以建模為一個單據流的形式。在營銷的領域，我們稱之為funnel analysis。
服務層：業務邏輯都是由各種網路服務提供的。這些網路服務之間用rpc的方式，或者隊列的方式進行連接。
資源層：按照 brendan gregg 的教誨，所有的事務都可以建模成鎖。資源是客觀存在的，多個不同的流程都會去爭搶這些鎖。比如資料庫表，比如文件系統，比如irq中斷，比如cpu鎖。我們可以把監控對象建模為一層層的鎖，來分析資源的爭搶情況。比如db的慢查詢監控。

業務層

業務層監控的目標：業務流程是不是在正常運轉？有沒有可以優化轉化的環節？

假設我們有這樣的一個業務邏輯。客戶先詢問一下價格，然後客戶再用給定的價格下單。我們保證成單用的價格就是用戶之前看見的。

一種實現方式是我們把價格作為「詢價」這個業務操作的返回值。由客戶端保存，然後在客戶決定進行「下單」這個業務操作的時候再帶上來。考慮到客戶端可能有可能被篡改，所以我們會用一些私鑰加密的方式或者電子簽名的方式來保證這份報價信息不是偽造的。

另外一種實現方式是，我們在詢價的時候把報價單作為資料庫記錄保存。並把報價單id返回給客戶端，然後再下單的時候提供報價單id。

從這個例子我們可以看到。無論是rpc的返回值，還是rpc中寫資料庫。其實都是一種保存交易雙方合同的一種方式，我們稱之為單據。所以無論是用客戶端傳遞，還是走資料庫。抽象上來說，前面的業務流程，都是這樣的單據流

一般來說，一個業務操作的處理，除了依賴前序單據+本次操作的用戶輸入之外，經常還依賴其他的業務單據和狀態。也就是單據和操作的關係是多對一的，複雜的操作需要很多的輸入進行綜合決策。

當我們有一個單據的時候，經常界面上會展示多個「call-to-action」。比如展示報價單的時候，可能提供一個按鈕是下單，另外一個按鈕是放棄。

比如我們在「已完成訂單」的這個單據的展示頁上可以，繼續發出「再來一單」，「投訴」，「評價」這麼三個業務操作。這些操作會把這個「已完成訂單」作為參數，也會把我這次提供的評價信息作為參數，也會把我這個「已登錄用戶」，「已註冊用戶」這兩個單據作為參數傳遞進去。

有了這樣一個模型。我們就可以統一地來分析各種業務：

已完成訂單，選擇「再來一單」，「評價」，「投訴」。我們可以來度量不同業務操作被選擇的概率。這種衡量 call-to-action 的轉化率的做法，在營銷入口是非常重要的
業務操作的重試率：可以用于衡量用戶是不是遇到問題了。如果一個司機在反覆點結束訂單，那麼肯定是結束訂單這個操作出問題了。
業務操作的失敗：比如設置密碼失敗，因為密碼太簡單了。通過分析這些失敗的佔比，可以用於發現我們的業務規則是不是太苛刻了。
從已完成訂單到被評價訂單：我們可以衡量單據之間的轉化率。比如呼叫應答率。這個也是營銷領域裡很重要的「漏斗」的概念，所謂funnel analysis。
詢價依賴於定價策略和產品：通過分析一個業務操作依賴哪些數據，可以方便我們快速知道一個問題單據是由哪些因素引起的。比如不合理的定價策略被通過了，第二天所有的詢價單都異常了。

像顧客留存這樣的非實時監控分析就不在這裡討論了。本文只討論如何監控實時的健康狀況。業務層的監控樣式，最常見的是這樣的。

服務層

服務層監控的目標：出了一個問題，哪個模塊提供的線上服務應該為這個負責？

這種rpc調用鏈的監控，應該是最常見的監控形式了。這些網路服務之間用rpc的方式，或者隊列的方式進行連接。網路監控（丟包率之類的）也可以建模成rpc監控。

如果是rpc直接調用，那麼就是

主調方
被調方
失敗率
錯誤碼
延遲
qps

這麼幾個方面。如果是中間走隊列。差不多就是把rpc endpoint替換成topic。隊列額外還需要監控一下端到端延遲，從入隊列到出隊列的per message的延遲。

資源層

資源層監控目標：性能有問題了，瓶頸在哪裡？知道所有的瓶，方知哪裡有頸。

這一層很好理解，大家多看看 brendan gregg 的文章就好了。任何業務都可以按照資源依賴來建模，總是最後會卡在某個資源的瓶頸上。通過對資源依賴關係進行建模和分析，我們可以很容易定位到任何性能問題。我們常見的cpu監控就是按資源視角的監控。

一層層的依賴，一層層的瓶頸。所有有資源爭搶的地方，都可能影響性能。這種依賴舉兩個例子：

聚划算的業務，和天貓的業務，可能用了同一個訂單系統。業務之間互相爭搶資源。
資料庫的前台查詢，以及機器上的監控腳本，可能並發地在做linux網路操作，兩者之間導致了資源的爭搶。

任何一個資源都建模成一個鎖。對於這個鎖的爭搶，我們度量以下指標（USE Method）：

utilization: the average time that the resource was busy servicing work
saturation: the degree to which the resource has extra work which it cant service, often queued
errors: the count of error events

舉幾個例子：

mutex locks: utilization may be defined as the time the lock was held; saturation by those threads queued waiting on the lock.
thread pools: utilization may be defined as the time threads were busy processing work; saturation by the number of requests waiting to be serviced by the thread pool.
process/thread capacity: the system may have a limited number of processes or threads, the current usage of which may be defined as utilization; waiting on allocation may be saturation; and errors are when the allocation failed (eg, "cannot fork").
file descriptor capacity: similar to the above, but for file descriptors.

總結

我相信世界是簡單的。複雜的活動背後可以歸納為幾種類型。我們也許不需要一個支持SQL和map reduce的日誌處理系統。我們也許更需要的是一個提供幾種通用監控模型的監控系統，按照需求，把數據按照模型的要求進行上報（比如 mixpanel 那樣）就可以獲得所有後續的服務，什麼看圖啦，什麼監控啦，什麼告警啦。