投屏問題如何監控.
邊界
1.用戶行爲是邊界 2.代碼作爲兩個邊界之間的執行體,就是監控的對象.
埋點圖
任何埋點都整理成圖,對應的比例關係在統計層面都是差不多不變的.
基於埋點圖的統計監控:
如果某個埋點數低了,那麼就要從哪些沒有了下游埋點的埋點中去找對應的問題,假設A埋點後肯定是B埋點. A,B埋點之間只有代碼. 那麼邏輯上A埋點和B埋點的數量應該是一致的. 或者說除去某些業務異常外,A,B埋點數量是一致的. 故存在A成功-B和A失敗-X埋點. 需要對A打標.
異常case定位
怎麼找case,這個時候就需要一個唯一標識了. 一般這個就是uid加單位分鐘. 通過01分鐘的A,01-02分鐘內都沒有出現過B.這些A篩選出來就是可用於case分析的例子.
Q: 如果有正常情況就是沒有B,那麼定位就會非常難.
A: 不會除非是有用戶的行爲沒有埋點, 不然肯定是完備的
跨用戶的埋點串聯
如果類似投屏垮了用戶和智能設備,需要把用戶uid和設備uid關聯起來,也就是需要一個sessionId. 不然無法找到那些缺失了B埋點的A埋點,進行case分析.
其實埋點的時候,也會有一個sessionId,一般是軟件激活時更新. 對於監控報警來說一般不需要,
進一步地縮小到某個具體業務:
例如投屏,幾個行爲串聯起來. 作爲業務狀態監控,避免出現那種大流量接口少了一些發現不了.
後來想了想上訴還是不夠通用:
歸本溯源,還是要模擬服務端接口. 對每次代碼進行try Catch 或者 對result碼進行監控. 成功數監控,失敗數監控,耗時監控.
外加可通過灰度id監控+體感報警監控.來解決大流量少了一部分發現不了的問題.
最終還是監控好每段獨立的代碼即可,異步的單獨添加,弱依賴的單獨添加..丟失問題不是很大.
端上的是異步回調,無非是將服務端的一個監控變成了三個(主動調用一個,失敗回調一個,成功回調一個; 主動調用,除了自己代碼,基本不會出現異常,重點監控, 失敗回調屬於依賴監控,需要知道,需要做好降級,做好推進解決.,失敗回調裏的代碼需要重點監控, 成功回調需要重點監控. )
關鍵是端上如果沒有好的框架,統一監控比較難. 埋點還是有用的.
綜上所訴:
埋點是粗粒度,且要求一個行爲後續所有行爲埋點都完備,不然可報警但不好定位. 類似狀態機. 不可操作性
代碼段tryCatch監控是細粒度,提供更精準的定位和分析,且有一個報警和定位都具備. 可操作性.