據分析能夠幫助我們更好地進行運營決策，數據分析能夠很好的為轉化用戶提供參考與數據支撐。

商業領域的數據分析，就是為了給商業行為提供良好的數據預測以及效果評估，在互聯網界也是如此。我們在目前商業環境所做的每一項活動都直接或者間接與用戶有著聯系，其目的本質都是一樣，為了讓用戶成為你的消費者，更進一步的持久消費者。因此數據分析，也應該為轉化用戶提供參考與數據支撐。畢竟沒有用戶轉化為消費者這個過程，所有的分析都是天方夜譚。數據的結論與行為的預測彼此就是一個循環論證的過程。

首先澄清一下數據分析其實并不是什么高深的學問，在現實的職場實戰中，涉及涵蓋的數據分析的方法以及復雜性是遠低于在學校里習得的專業知識。什么卡方檢驗，方差分析，回歸分析顯著性檢驗等等在非用研以及非專業統計分析領域是很少涉及的。（當然那些學過數理統計學的專業人士也不屑于本文提到的內容，如果大家對這些看起來比較高深的分析方法有興趣可以自行腦補）。本文只給運營以及一些涉及產品方向的崗位提供分析思路并結合實際案例對我所涉及的領域，抽絲剝繭，給大家一個更加直觀的用戶轉化方面涉及數據分析的知識覆蓋。

互聯網的大用戶概念我們可以直接簡單粗暴認定為流量，這里的流量并不是指的簡單的IP,UV,PV也可以指來電數，訪客人數，人流量等概念既然是流量也就有其自身的數量。我們在對流量轉化的數據分析時都會基于一種邏輯方案———流量漏斗轉化模型進行分析。

原理很簡單，我們可以形象的認為自身的互聯網產品其本身就是一個虛擬的漏斗，用戶在進行瀏覽到最終完成下單行為（或者其他我們認定的轉化行為比如注冊，關注，轉發等）有多少被直接阻擋在了“濾網”之上，有多少順利的達到了我們預設的“轉化行為區域”。當然，我們所有的活動都并不是一錘子買賣，因此也要從橫向（時間）維度來分析問題。持續的轉化用戶，保持老用戶的消費活力也是分析工作的重中之重。當然，我們在轉化流量不僅僅是指的轉化的數量而且還指轉化的質量，說的比較簡單點，就是要提高單個用戶的消費價值。在橫縱兩個維度方面，在這些層層“濾網”中，我們是如何透過這些數據分析問題的呢。

以大型電商網站下單流程為例，我將從流量來源-中間頁面訪問-詳情頁-加入購物車-提交訂單-復購這幾個階段展開說明。

一，流量來源

流量進入主站的第一道障礙通過不同渠道進入的主站（或者該渠道引入流量的承接頁），主站頁面即是第一層“濾網”我們用穿過第一層濾網進入二級頁面的通過率來衡量渠道的流量的質量。通常我們用來衡量頁面的流量質量的指標包含如下：頁面UV點擊率，頁面停留時間，跳失率。

想要通過第一層“濾網”，需要必要的動作就是產生點擊行為，而點擊行為會產生兩個數據：頁面UV點擊率=頁面點擊總次數/頁面UV數；跳失率=通過一個入口進入就離開的次數/通過該入口訪問的總次數。點擊率越高，說明頁面呈現的內容有吸引力能夠有效的吸引用戶的關注；跳失率越高，說明頁面呈現內容具備欺騙性，所呈現的鏈接內容和文案不具備吸引力。因此在進行第一層濾網的優化方面盡量提高頁面的點擊率，降低頁面的跳失率。盡量讓用戶下沉到二級頁面（或者目標頁面）。同時通過這個數據也可以判斷流量來源的質量是否過關。

一般而言，頁面低質量的流量判斷往往符合以下幾個特點：在排除頁面問題的情況下產生的：1，低點擊率；2，高跳失率；3低頁面停留時間。

這些低質量流量產生的原因主要有幾個方面：1，渠道引流上呈現的文案內容與承接落地頁面不符。2，投放渠道上，與目標用戶活躍范圍不符的渠道，也就是說投放的渠道不精準。3，承接頁出錯等以及其他原因（包含但不限于404錯誤網頁過期，跳轉出錯等）。

既然說到這，順便也給大家看看外部渠道的各種引流的優劣：

以上表格內容，并不一定十分準確，大家可以抱著批判的態度研究論證一下。

二，中間頁面訪問

在頁面訪問階段，流量成功通過第一道“濾網”進入到中間頁階段，中間頁包含：搜索列表頁，專題活動頁面，頻道頁面等。不同的中間頁也有不同的數據指標反映著頁面內容的好壞以及流量的走向。中間頁的好壞考量最終是有多少訪客進入到了商品詳情頁，因此有一個指標非常重要：UV到達詳情頁轉化率=詳情頁UV/中間頁UV

搜索列表頁

搜索列表頁在大型電商網站中有著不可代替的重要作用，也是站內流量的主要來源，承接著站內商品檢索，品類布局的重任，區分搜索頁面與列表頁面主要是看鏈接字符，搜索頁面的鏈接往往包含search字符，列表頁（或者可以叫類目頁）鏈接包含list字符。搜索頁為依據用戶輸入的關鍵詞來進行整體檢索后呈現給用戶商品陳列頁面。而列表頁則是與網站商品類目后臺直接關聯，呈現品類最全的頁面。兩者的功能都是為了給予用戶更好和更快的定位到想要查看的商品（或者內容）。以下為分別為幾個B2C電商的的搜索和類目頁鏈接的開頭：

• 京東搜索：https://search.jd.com/Search?keyword=關鍵詞代碼
• 京東列表：https://list.jd.com/list.html?cat=列表頁代碼
• 蘇寧搜索：http://search.suning.com/關鍵詞代碼
• 蘇寧列表：http://list.suning.com/列表代碼

其他就不一一列舉了，搜索列表頁的數據指標的考核目的就是為了能讓用戶更加精確快速的找到自己的想要的產品，因此在這一級的頁面中數據指標包含如下：

搜索點擊率=點擊次數/搜索次數；這個指標衡量搜索頁面的呈現質量，理論上而言搜索點擊率要在200%及以上才是比較健康。（不絕對）

UV到詳情頁轉化率=詳情頁UV/搜索或者列表頁UV；該指標在搜索和列表中同樣適用，用來平衡點擊率的作弊可能，也是反映三級頁面呈現質量的指標之一。

搜索無結果次數：用以反映關鍵詞涉及的品牌品類缺失或者未關聯指標。當然搜索無結果詞的次數是越低越好。對于搜索詞呈現結果為空的品類，需要綜合評估后決定是否對相關類目開啟招商，引進產品線；對于未關聯的品類需要著重優化頁面重新關聯。

搜索結果頁首屏點擊率=搜索首屏點擊次數/搜索次數；該指標用以衡量搜索結果首屏的商品排序質量與呈現質量。該數據指標的好壞可以間接的反映出搜索詞呈現的頁面排序是否合理，是否符合用戶的需求。同理列表頁的首屏指標也與此一樣只是名稱不同而已即列表頁首屏點擊率=列表頁首屏點擊次數/列表頁PV.

搜索次數：搜索詞產生的搜索次數。（可以理解為搜索PV）一個搜索詞的搜索次數高表示該詞所涉及的類目需求量高，反之亦然；如果是在列表頁則為訪問PV

搜索人數：搜索詞被多少人搜索的數量（可以理解為搜索UV）；一個搜索詞的搜索人數高表示該詞所涉及的類目需求量高-主要是為了防止出現搜索次數作弊的情況，反之亦然如果是在列表頁則為訪問UV

高級篩選項點擊次數：在搜索列表頁中，頁面頂部的高級篩選項是為提供快速定位而設立的，高級篩選項的點擊次數和使用率也可以為運營人員提供商品熱度參考。舉個例子：在客人搜索“單肩包”或者訪問單肩包的列表頁，在這些頁面中都會出現比如材質，價格款式等參數項來給用戶選擇篩選，通過監控頁面的篩選參數的點擊次數，可以得到相關“單肩包”哪些款式哪些材質多少價位是消費者主要關注的，并以此來進行主推產品的規劃。

在理出了這些指標之后，如何分析這些指標數據呢？

• 根據搜索詞的搜素次數搜索人數重點關注排名靠前的高搜索量的關鍵詞，搜索量高，代表關注度高，接受性強。
• 熱門搜索詞關注其點擊率與詳情頁到達率。分為幾種情況：一，點擊率過高，UV到詳情頁到達率一般，可能出現了點擊作弊的情況（商戶用來刷新排名）；二，點擊率高，到達率也高。說明該關鍵詞的搜索結果頁面運轉良好同時也說明該關鍵詞頁面排序合理，反之則需要優化。
• 高級篩選項參數點擊次數過低，使用率較少則需要重新設置高篩項展示項目。提高使用率。
• 對于搜索無結果的關鍵詞則需要進行深度分析，是否是系統問題或者為未涉及未引進的產品，并反饋給招商采購部門用以提供采購參考。

總結歸納：針對搜索列表頁的數據分析歸為3點：高搜索詞重點優化提高點擊轉化；無結果詞分析反饋；頁面點擊注重高篩適用率方便用戶快速定位。

分析邏輯：以讓用戶下沉到詳情頁為目的逐一分析，各個擊破。

頻道頁/活動頁

頻道頁和活動頁是常規三級頁面，在B2C電商中起著常規類目集合體和活動流量承接頁的作用，在頻道頁和活動專題頁上也有著數據的計算和分析邏輯，其主要的數據指標也是讓用戶下沉至詳情頁。（基于這樣一種假設，用戶只有在詳情頁才有可能產生轉化，這種假設已經被證明-至少絕大部分情況是這樣。）頻道頁和活動頁雖然具體的數據指標與搜素列表頁有所不同，但是他們的最終目的都是相同的。頻道頁活動頁的數據指標包含：

• 點擊率=頁面點擊數/頁面UV數；一般情況而言，點擊率用來衡量頻道頁入口鏈接圖和輪播圖的質量，是否吸引人，文案是否貼切相關，當然也能形容商品的鋪排是否合理。
• 到達詳情頁轉化率=到達詳情頁UV/頁面UV；用以形容活動頁的產品鋪排布局是否合理的指標之一。當然有時候活動頁也是需要考核成交轉化率=成交件數/詳情頁UV，有時候還包含頁面停留時間的維度。

低點擊率的區域可能存在以下幾種原因，一，是圖片以及圖片里的文案不能吸引消費者點擊，需要調整。二，產品頭圖展示樣式不合理需要調整圖片內容或者調換商品。三，展示區域位于首屏以下，關注度不高-需要調整展示位置。

分析邏輯：還是以用戶下沉為目的，分析涉及的元素逐個排查。

三，詳情頁&購物車&訂單

詳情頁作為流量轉化的關鍵頁面，是前臺承載商品信息的最基本單位。也是用戶是否決定下單購買的最最重要的一環。因此在分析詳情頁的時候，數據指標更多的是詳情頁的質量和它的轉化率。當然這兩者是相互聯系的，從現有的數據來看，詳情頁的質量高低與其轉化率確實是存在正相關的關系。而詳情頁質量的高低從數據的量化反映來看有兩個數據指標：一，平均頁面停留時間；二，加入購物車數。

平均頁面停留時間=頁面停留總時間/訪問UV數該指標與頁面的呈現布局有著明顯關聯，包含商品參數介紹，詳情圖片描述，客服在線情況，好評率等。

加入購物車數：用以反映該商品有多少有意向購買者，為即將轉化的關鍵步驟。加入購物車的數量多少由基本以下幾個因素決定：

• 詳情頁頁面綜合質量（圖片，排版，展示，參數說明，售后信息）；
• 在線客服綜合服務指數（響應時間，在線時長，答復滿意度）；
• 評價信息（好評率，差評回復內容，曬單信息）。

從數據的角度講，詳情頁反映出的問題僅僅通過一個平均訪問時長是很難概括的，沒辦法分解到具體某一個細節來層層分解問題。不過這個時候“經驗”的加入就能很好的平衡這一點。這里的經驗表示已經經過了長期的實踐且數據論證的結論。（這里給大家安利一下數據觀點：數據不是萬能的，有時主觀的判斷更具代表性，這也是為什么這個世界上有著那么多的出人意料產品和逆風而上的創意）

購物車是一個特別有趣的設置，對于快消品標準品的電商網站來說，設置購物車一方面是為了節省用戶挑選多個商品的付款時間，更出現了一個更加意想不到的好處，就是提高了客單價。在配合滿減用券等促銷手段的幫助下購物車必然能夠起到事半功倍的作用。

在購物車中如果大量積壓了客戶選購的商品，如果用戶始終沒有進行下單支付，即加入購物車數較大，這個時候則需要采用短信催付，郵件催付，以及apppush等手段來促進用戶轉化。

訂單頁面是縱向轉化的最后一環，在這個界面最主要的目的就是盡量讓用戶盡快付款，達到最后的轉化。考核的數據為：有效訂單轉化率=成交訂單數/有效訂單數，在這個階段促成轉化是較為簡單的如果有效訂單轉化率較低就要分析是否支付頁面存在問題，系統提交流程是否出錯等。在排除系統問題后同樣可以使用短信apppush郵件等手段進行催付。

最后作為總覽全局的用戶轉化指標：UV成交轉化率=成交訂單數/頁面UV數

作為考核整體用戶轉化的指標；平均UV價值=成交金額/頁面UV數作為考核整體用戶質量的指標，值越高，表示質量越高。

總結：層層下探，逐個擊破直到完成付款

四，復購（橫向持續轉化）

有句老話說的好，叫不做一錘子買賣，因此這里就涉及到一個新的指標：

復夠率=一段時間內重復購買的客戶數/一段時間內產生購買的客戶數，該指標則要求我們從橫向時間維度來分析數據，也很容易理解。有據可查，一個成熟期的購物網站其老用戶貢獻的銷售額占據總數的60%-70%之多。因此我們在看到流量漏斗的轉化模型的同時，更加要加深對會員的分層管理，用良好的服務于產品以及具有創意和力度的活動維系你的老用戶。

復夠率過低：1，表示沒有對老會員進行足夠的喚醒，可通過短信push線下廣告等等活動進行推廣激活；2，也有可能近期投入的拉新的資源較多，導致新客增多降低了復夠率，需要核實拉新活動的數據；3，超低價或者超優惠活動引流也會導致大量新用戶引入，也會對復夠率產生影響。上面的兩點并不是對復夠率有壞的影響，針對的客群不同，數據也應有所取舍。

以上就是針對電商下單流程的整個過程，當然有很多模塊并沒有提及，比如智能交叉推薦等。大家只需要理解其中的數據分析的邏輯即可。不同的頁面，不同的時間，轉化用戶的目的不同，根據各個階段的目的，分析不同事件節點的數據，層層推理即用戶數據的分析之道。有關會員管理的相關數據（喚醒激活留存）大家可以自行度娘腦補，不再贅述。

安利幾個針對數據分析中的幾點小tips：

• 不要盲目相信數據，數據為王本身就是悖論，只有結果為王。
• 單日的數據波動較大不具備參考性，需要橫向統計，分析趨勢圖，解釋轉折點
• 能變成圖表就不要用表格展示。
• 分析結論簡單化

以上觀點，均屬于個人見解，不代表權威性不代表絕對準確，謹慎采納。

作者：王小命兒，微信號：wanghuan314400

本文由@王小命兒原創發布于人人都是產品經理。未經許可，禁止轉載。

者 | 李剛

本文經授權轉載自阿里巴巴中間件（ID:ilieyun）

背景介紹

餓了么監控系統 EMonitor ：是一款服務于餓了么所有技術部門的一站式監控系統，覆蓋了系統監控、容器監控、網絡監控、中間件監控、業務監控、接入層監控以及前端監控的數據存儲與查詢。每日處理總數據量近 PB ，每日寫入指標數據量百T，每日指標查詢量幾千萬，配置圖表個數上萬，看板個數上千。

CAT：是基于 Java 開發的實時應用監控平臺，為美團點評提供了全面的實時監控告警服務。

本文通過對比分析下兩者所做的事情為契機討論監控系統或許該有的面貌，以及淺談下監控系統發展的各個階段。

CAT 做的事情（開源版）

首先要強調的是這里我們只能拿到 GitHub 上開源版 CAT 的最新版 3.0.0 ，所以是基于此進行對比。接下來說說 CAT 做了哪些事情？

抽象出監控模型

抽象出 Transaction、Event、Heartbeat、Metric 4 種監控模型。

• Transaction：用來記錄一段代碼的執行時間和次數。

• Event：用來記錄一件事發生的次數。

• Heartbeat：表示程序內定期產生的統計信息, 如CPU利用率。

• Metric：用于記錄業務指標，可以記錄次數和總和。

針對 Transaction 和 Event 都固定了兩個維度， type 和 name ，并且針對 type 和 name 進行分鐘級聚合成報表并展示曲線。

采樣鏈路

針對上述 Transaction、Event 的 type 和 name 分別有對應的分鐘級的采樣鏈路。

自定義的 Metric 打點

目前支持 Counter 和 Timer 類型的打點，支持 tag ，單機內單個 Metric 的 tag 組合數限制 1000 。并且有簡單的監控看板，如下圖所示：

與其他組件集成

比如和 Mybatis 集成，在客戶端開啟相關的 sql 執行統計，并將該統計劃分到 Transaction 統計看板中的 type=SQL 的一欄下。

告警

可以針對上述的 Transaction、Event 等做一些簡單的閾值告警。

餓了么 EMonitor 和 CAT 的對比

餓了么 EMonitor 借鑒了 CAT 的相關思想，同時又進行了改進。

引入 Transaction、Event 的概念

針對 Transaction 和 Event 都固定了兩個維度， type 和 name ，不同地方在于聚合用戶發過來的數據。

CAT 的架構圖如下所示：

CAT 的消費機需要做如下兩件事情：

• 對 Transaction、Event 等消息模型按照 type 和 name 進行當前小時的聚合，歷史小時的聚合數據寫入到 mysql 中；

• 將鏈路數據寫入到本地文件或者遠程 HDFS 上。

EMonitor 的架構圖如下所示：

EMonitor 分兩路對數據進行隔離處理：

• Real-Time Streaming Compute：對用戶發過來的鏈路中的 Transaction 、Event 等監控模型轉變成指標數據并進行 10s 的預聚合，同時也對用戶發過來的 Metric 數據進行 10s 預聚合。最后將 10s 預聚合的數據寫入到 LinDB 時序數據庫（已開源，有興趣的可以關注 star 下）中，以及 kafka 中，讓告警模塊 watchdog 去消費 kafka 做實時告警；

• Real-Time Data Writer：對用戶發過來的鏈路數據構建鏈路索引、向 HDFS 和 HBase 寫入索引和鏈路數據，同時會構建應用之間的依賴關系，將依賴關系寫入到 Neo4j 中。

所以 EMonitor 和 CAT 的一個很大不同點就在于對指標的處理上， EMonitor 交給專業的時序數據庫來做，而 CAT 自己做聚合就顯得功能非常受限，如下所示：

• CAT 只能整小時的查看 type 和 name 數據，不能跨小時，即不能查看任意兩個時間之間的報表數據， EMonitor 沒有此限制；

• CAT 沒法查看所有 type 匯總后的響應時間和 QPS ， EMonitor 可以靈活的自由組合 type 和 name 進行聚合；

• CAT 的 type 和 name 報表是分鐘級的， EMonitor 是 10s 級別的；

• CAT 的 type 和 name 沒能和歷史報表曲線直接對比， EMonitor 可以對比歷史報表曲線，更容易發現問題；

• CAT 的 type 和 name 列表首頁展示了一堆數字，無法立即獲取一些直觀信息，比如給出了響應時間 TP99 100ms 這個到底是好還是壞， EMonitor 有當前曲線和歷史曲線，相對來說可以直接判斷到底 ok 不 ok ；

• CAT的TP99、TP999基于單機內某個小時內的報表是準確的，除此之外多機或者多個小時的聚合TP99、TP999是用加權平均來計算的，準確性有待提高。

但是CAT也有自己的優勢：

• CAT 含有 TP999、TP9999 線(但是準確性還有些問題)， EMonitor 只能細到 TP99 ；

• CAT 的 type 和 name 可以按照機器維度進行過濾， EMonitor 沒有做到這么細粒度。

采樣鏈路

目前 CAT 和 EMonitor 都可以通過 type 和 name 來過濾采樣鏈路，不同點在于：

• CAT 的采樣鏈路是分鐘級別的， EMonitor 是 10s 級別的；

• 針對某一個 type 和 name ，CAT 目前無法輕松找想要的鏈路， EMonitor 可以輕松的找到某個時刻或者說某段時間內響應時間想要的鏈路（目前已經申請專利）。

EMonitor 的鏈路如下所示：

• 這張圖是某個10s 時刻、某個 type 和 name 過濾條件下的采樣鏈路；

• 第一行是這 10s 內的采樣鏈路，按照響應時間進行了排序；

• 可以隨意點擊某個響應時間來查看對應的鏈路詳情。

自定義的 Metric 打點

EMonitor 支持 Counter、Timer、Histogram、Payload、Gauge 等等多種形式的打點方式，并且支持 tag ：

• Counter：計數累加類型；

• Timer：可以記錄一段代碼的耗時，包含執行次數、耗時最大值、最小值、平均值；

• Histogram：包含 Timer 的所有東西，同時支持計算 TP99 線，以及其他任意 TP 線(從 0 到 100 )；

• Payload：可以記錄一個數據包的大小，包含數據包個數、包的最大值、最小值、平均值；

• Gauge：測量值，一般用于衡量隊列大小、連接數、CPU、內存等等。

也就是任意 Metric 打點都可以流經 EMonitor 進行處理了并輸送到LinDB時序數據庫中。至此， EMonitor 就可以將任何監控指標統一在一起了，比如機器監控都可以通過 EMonitor 來保存了，這為一站式監控系統奠定了基礎。

自定義 Metric 看板

CAT只有一個簡易的 Metric 看板 EMonitor 針對 Metric 開發了一套可以媲美Grafana 的指標看板，相比 Grafana 的優勢：

• 有一套類似 SQL 的非常簡單的配置指標的方式；

• 跟公司人員組織架構集成，更加優雅的權限控制，不同的部門可以建屬于自己的看板；

• 指標和看板的收藏，當源指標或看板改動后，無需收藏人員再改動；

• alpha、beta、prod 不同環境之間的一鍵同步指標和看板，無需配置多次；

• PC端和移動端的同步查看指標和看板。

類 SQL 的配置查詢指標方式如下所示：

• 可以配置圖表的展現形式；

• 可以配置要查詢的字段以及字段之間的加減乘除等豐富的表達式；

• 可以配置多個任意 tag 的過濾條件；

• 可以配置 group by 以及 order by。

看板整體如下所示：

移動端顯示如下：

與其他組件集成

目前 EMonitor 已經打通了 IaaS 層、 PaaS 層、應用層的所有鏈路和指標的監控，再也不用在多個監控系統中切換來切換去了，如下所示：

• IaaS層物理機、機房網絡交換機等的監控指標；

• PaaS 層中間件服務端的監控指標；

• 應用層 SOA、Exception、JVM、MQ 等客戶端的相關指標；

• 應用層自定義的監控指標。

以打通餓了么分庫分表中間件 DAL 為例：

可以根據機房、執行狀態、表、操作類型（比如 Insert、Update、Select 等）進行過濾查看：

• 左邊列表給出每條 SQL 的執行的平均耗時；

• 右邊2個圖表給出該條 SQL 在 DAL 中間件層面、 DB 層面的耗時以及調用 QPS；

• 可以給出該 SQL 打在后端 DAL 中間、 DB 上的分布情況，可以用于排查是否存在一些熱點的情況；

• 還有一些 SQL 查詢結果的數據包大小的曲線、 SQL 被 DAL 限流的情況等等；

• 可以查看任何時間點上該 SQL 的調用鏈路信息。

再以打通餓了么 SOA 服務為例：

• 可以根據機房和狀態信息進行過濾；

• 左邊一欄列出該應用提供的 SOA 服務接口，同時給出平均響應時間以及和昨天的對比情況；

• 右邊的兩個圖表分別給出了對應服務接口的服務響應時間和 QPS 以及和昨天的對比情況，同時可以切換平均響應時間到 TP99 或者其他 TP 值，同時配有可以快速對相關曲線添加告警的跳轉鏈接；

• 可以切換到單機維度來查看每臺機器該 SOA 接口的響應時間和 QPS ，用來定位某臺機器的問題；

• 可以給出該 SOA 接口調用在不同集群的分布占比；

• 可以給出該 SOA 接口的所有調用方以及他們的 QPS；

• 可以查看任何時間點上該 SOA 接口的調用鏈路信息。

告警

可以針對所有的監控指標配置如下告警方式：

• 閾值：簡單的閾值告警，適用于 CPU 、內存等；

• 同環比：與過去同期比較的告警；

• 趨勢：適合于相對平滑連續的無需閾值的智能告警；

• 其他告警形式。

淺談監控系統的發展趨勢

日志監控階段

本階段實現方式：程序打日志，使用ELK來存儲和查詢程序的運行日志， ELK 也能簡單顯示指標曲線。

排障過程：一旦有問題，則去 ELK 中搜索可能的異常日志來進行分析排障。

鏈路監控階段

上一個階段存在的問題：ELK 只是基于一行一行日志進行聚合或者搜索分析，日志之間沒有上下文關聯。很難知道一次請求耗時較長究竟耗時在哪個階段。

本階段實現方式：CAT 橫空出世，通過建模抽象出 Transaction、Metric 等監控模型，將鏈路分析和簡單的報表帶入了大家的視野。

告警方式：針對報表可以進行閾值監控排障過程：一旦有告警，可以通過點擊報表來詳細定位到是哪個 type 或 name 有一定問題，順便找到對應的鏈路，查看詳細的信息。

指標監控階段

上一階段存在的問題：CAT 對自定義指標支持的比較弱，也無法實現或者展現更加多樣的查詢聚合需求。

本階段的實現方式：支持豐富的 Metric 指標，將鏈路上的一些報表數據也可以劃分到指標中，交給專業的時序數據庫來做指標的存儲和查詢，對接或者自研豐富的指標看板如 Grafana 。

告警方式：針對指標進行更加豐富的告警策略排障過程：一旦有告警，可能需要到各個系統上查看指標看板，粗略定位根因，再結合鏈路總和分析。

平臺打通整合階段

上一階段存在的問題：系統監控、中間件和業務監控、部分業務監控、鏈路監控與指標監控都各搞一套數據收集、預處理、存儲、查詢、展現、告警流程，各個系統處理數據格式、使用方式不統一。

本階段的實現方式：打通從系統層面、容器層面、中間件層面、業務層面等等的可能的鏈路和指標監控，統一數據的處理流程，同時整合發布、變更、告警與監控曲線結合，成為一站式監控平臺。

告警方式：可以統一的針對各個層面的監控數據做統一化的告警排障過程：只需要在一個監控系統中就可以查看到所有的監控曲線和鏈路信息。

目前我們 EMonitor 已完成這個階段，將公司之前存在已久的 3 套獨立的監控系統統一整合成現如今的一套監控系統。

深度分析階段

上一階段存在的問題：

• 用戶雖然可以在一個系統中看到所有各個層面的監控數據了，但是每次排障時仍然要花很多的時間去查看各個層面是否有問題，一旦漏看一項可能就錯過了問題所在的根因；

• 沒有整個業務的全局監控視角，都停留在各自應用的角度。

總之：之前的階段都是去做一個監控平臺，用戶查詢什么指標就展示相應的數據，監控平臺并不去關心用戶所存儲數據的內容。現在呢就需要轉變思路，監控平臺需要主動去幫用戶分析里面所存儲的數據內容。

本階段的實現方式：所要做的就是把幫用戶分析的過程抽象出來，為用戶構建應用大盤和業務大盤，以及為大盤做相關的根因分析。

• 應用大盤：就是為當前應用構建上下游應用依賴的監控、當前應用所關聯的機器監控、redis、MQ、database 等等監控，可以時刻為應用做體檢，來主動暴露出問題，而不是等用戶去一個個查指標而后發現問題；

• 業務大盤：就是根據業務來梳理或者利用鏈路來自動生產大盤，該大盤可以快速告訴用戶是哪些業務環節出的問題。

根因分析：一個大盤有很多的環節，每個環節綁定有很多的指標，每次某個告警出來有可能需要詳細的分析下每個環節的指標，比如消費 kafka 的延遲上升，有各種各樣的原因都可能導致，每次告警排查都需要將分析流程再全部人為分析排查下，非常累，所以需要將定位根因的過程通過建模抽象下，來進行統一解決。

趨勢報表分析：主動幫用戶發現一些逐漸惡化的問題點，比如用戶發布之后，接口耗時增加，很可能用戶沒有發現，雖然當前沒有問題，但是很有可能在明天的高峰期就會暴露問題，這些都是已經實實在在發生的事故。

要想做主動分析，還深度依賴指標下鉆分析，即某個指標調用量下降了，能主動分析出是哪些 tag 維度組合導致的下降，這是上述很多智能分析的基礎，這一塊也不簡單。

告警方式：可以統一的針對各個層面的監控數據做統一化的告警排障過程：NOC 根據業務指標或者業務大盤快速得知是哪些業務或者應用出先了問題，應用的 owner 通過應用大盤的體檢得知相關的變動信息，比如是 redis 波動、database 波動、上下游應用的某個方法波動等等，來達到快速定位問題目的，或者通過對大盤執行根因分析來定位到根因。

再談 Logging、Tracing、Metrics

三者關系如下圖所示：

三者的確都不可或缺，相輔相成，但是我想說以下幾點：

• 三者在監控排障中的所占比例卻大不一樣：Metrics 占據大頭， Tracing 次之， Logging 最后；

• Tracing 含有重要的應用之間的依賴信息， Metrics 有更多的可深度分析和挖掘的空間，所以未來必然是在 Metrics 上大做文章，再結合 Tracing 中的應用依賴來做更深度全局分析，即 Metrics 和 Tracing 兩者結合發揮出更多的可能性。

參考鏈接：

CAT：https://github.com/dianping/cat

深度剖析開源分布式監控CAT：

https://tech.meituan.com/2018/11/01/cat-in-depth-java-application-monitoring.html

作者簡介：李剛，網名乒乓狂魔，餓了么監控組研發專家，餓了么內部時序數據庫LinDB項目負責人，目前致力于監控的智能分析領域。

本文縮略圖：icon by dmbcjl

【END】

說，到2020年，有500億設備要連接網絡，這是未來物聯網的廣闊前景。好消息，以后運營商也不用跪著發展客戶了，坐等設備連接就好了！

不過，沒那么樂觀！支持物聯網的無線技術太多，蜂窩網絡也只是其中一小部分而已。

做個計算題，假設500億連接設備中，減去100億連接手機和PC，剩下400億去連接物聯網，按照目前的蜂窩網技術，估計只有2%（約8億）的物聯網設備可接入蜂窩網絡。

才8億？我泱泱中華的手機用戶數都超過啦，何況物聯網那點流量，呵呵！

為了解決這些問題，Cat.0就來了！

什么是Cat.0？

Cat.即UE-Category，根據3GPP的定義，UE-Category分為1~10共10個等級，其中Cat.1-5為R8定義，Cat.6-8為R10定義，Cat.9-10為R11定義。

如上圖，UE-Category主要定義了UE終端能支持的上下行速率。

Cat.0是被寫入3GPP Rel.12標準，支持更低速率、更低功耗版本的LTE終端等級。Cat.0和Cat.1都是指向廣闊的物聯網市場，實現更低功耗、更低成本物聯網設備連接到LTE網絡。支持更低Category，對可穿戴設備、智慧家庭和智慧電表等物聯網應用非常關鍵。

不過，一直以來，無論是網絡還是終端芯片，LTE與物聯網之間總是存在一條難以跨越的鴻溝，不過，隨著這些年一些通信設備公司和芯片公司的積極投入，可望改變市場局勢，為LTE網絡連接物聯網提供更廣闊的前景。比如，前不久，Sequans與Altair相繼宣布近期將推出Cat.0和Cat.1芯片組。

為什么要定義Cat.0呢？

為了應對物聯網，LTE-M（M2M）必須對LTE網絡進行幾個方面的優化：

1）設備成本

盡管大量設備接入帶來巨大價值，但是，連接設備的成本卻是一個大問題。連接蜂窩網絡的設備需要芯片支持，為了支持高清視頻、在線游戲，目前LTE芯片主要支持幾十到幾百Mpbs的高速高性能LTE網絡。芯片支持的速率越高，硬件就越復雜，成本也就越高。物聯網M2M應用并不需要這么高的速率，甚至有些設備間連接只需要幾百bps就夠了。因此，為了減小設備成本，就得簡化芯片來滿足物聯網M2M應用需求。

2）電池壽命

我們可以每天給手機或平板充電，物聯網設備不可能每天甚至每個月為其充電，不僅不方便，而且維護成本上升。一些設備需要長期保持運行狀態，一旦電池耗盡，通信中斷，可能會導致重大損失。比如，應用于火警聯動的設備直接將信號傳送至消防中心。超長的電池使用時間，就顯得尤為重要。

3）增強覆蓋

對于物聯網M2M應用，覆蓋同樣非常重要。一個簡單的例子，智能水表都安裝在地下室或建筑物內隱蔽的地方。由于信號衰減，通常這些地方信號偏弱。所以，需要提升增強網絡覆蓋來應對物聯網。

設備成本

為了減少設備成本，R12就制定了Cat.0終端等級，實際上，Cat.0指的就是低成本的M2M設備。為了降低設備復雜性和減小設備成本，Cat.0定義了一系列的簡化方案，主要包括：

1.半雙工FDD模式（Half duplex FDD)。

半雙工FDD模式允許在FDD模式下時分復用。

2.減小設備接收帶寬到1.4MHz，當然，也可以擴到20MHz。

3.單接收通路，取消RX分集雙通路。

4.低速數據速率。不僅降低速率需求，處理器計算能力和存儲能力也相對降低。

在R13版本還會有進一步的優化，比如取消發射分集，不再支持MIMO，支持小于1.4MHz更低的帶寬，支持更低的數據速率。

關于Cat.0、Cat.1、Cat.4和R13版本的Cat.的特征比較如下圖：

為了面向物聯網，降低設備成本，除了定義Cat.0終端設備等級外，還需要對電池使用時長和覆蓋進行優化。

電池使用壽命

為了省電，R12采用一種叫power saving mode (PSM，省電模式)的方案。如果設備支持PSM，在附著或TAU（Tracking Area Update）過程中，PSM向網絡申請一個激活定時器值。當設備從連接狀態轉移到空閑狀態后，該定時器開始運行。當定時器終止，設備進入省電模式。當設備進入省電模式，設備不再接收尋呼消息，看起來設備和網絡失聯，但設備仍然注冊在網絡中。設備將一直保持這種省電模式，直到設備需要主動向網絡發送信息（比如周期性TAU，發送上行數據等）。

據說，采用這種方案，兩節5號電池可以用10年以上。

如上圖，如果DRX不連續接收循環為10分鐘，設備每周上傳一次數據，這樣，兩節5號電池可以用132月（11年）之久。

增強覆蓋

在增強覆蓋方面，LTE-M采用的技術包括：放大數據和參考信號發射功率、重傳、和降低性能需求，比如，允許更長時延和更高的誤碼率。采用這些技術，覆蓋性能可以提升20dB。

總之，當我們在要求4G網絡更快、更強時，物聯網M2M設備卻不停在喊，低點，再低點，還能再低么？也許后面還有比Cat.0更低的等級，不過應該叫Cat.幾呢？