概述

這是監控告警產品專題系列第一篇文章，涉及的主要內容為監控產品設計的一些相關基礎知識，算是這個系列文章的一個索引。該篇會主要涉及到以下主要內容

• 後續三篇文章講述的核心內容(這個系列會比較長，先暫定了後面三篇的內容)。

• 關於監控告警一些需要提前交代的概念。

• 立體化監控體系的闡述。

我現在是織雲監控告警產品線的產品經理，而且這部分的產品也在分版本的持續建設中。所以後續主要的產品規劃、設計、實現的講述都是基於織雲這個載體上實現。

尋覓初心

以前做QQ業務運維的時候，有一類平臺是自己天天會用，那這類平臺是什麼呢？就是監控告警平臺，每天在上面查大量的業務檢視、查異常、確認告警、處理告警等等。

對於運維同學來說，如果從使用頻率這個維度看，監控告警類平臺的使用頻率要大於自動化類平臺，畢竟自動化類平臺多數都是由例行變更觸發，而監控告警平臺是我們7X24小時都要使用的。當時自己名下有較多的業務和幾千臺機器，那時有過一天收1000多條告警的記錄，相當崩潰。

其實告警如果一天超過幾十條就基本是無效的，即關注不過來，也處理不過來。在業務運維這個角色中，我更多的是從使用者這個視角去看監控的。

去年下半年我從業務運維轉型為產品經理，現在負責騰訊織雲(企業級運維管理平臺)監控告警產品線的規劃與落地。在產品經理這個階段我更多的是從建設者這個視角去看監控的。

使用者和建設者這兩個視角去看待同一個事物監控告警這個產品，最大的差異點是什麼呢？

• 使用者是點，建設者是面，使用者只關注能服務到自己的功能點，而建設者儘量要更全面的抽象多數使用者所具化的場景，在抽象的基礎上在去構建功能，力爭滿足大部分的使用者場景，解決實際的問題。

“出了任何故障，其他環節都是可能有問題，唯獨監控是一定有問題！”
                            —— 喬治·背黑鍋

基於這兩種不同的視角與在實際建設途中遇到的各種實際問題，我萌發了寫一個監控專題系列的想法，哈哈，臉皮蠻厚的的。自己以前都是寫單篇的文章，這次也算是一個挑戰了。希望通過這個專題能與大家交流下關於一款企業級監控產品是怎麼樣規劃、設計與落地的。

可能是當產品經理習慣了使用者場景與角色的分析，如果把這個主題的文章當做一個產品來看，那麼其中的角色與場景是什麼呢？
梳理一下自己在建設織雲監控告警產品線的一些經驗和思考。

• 對於剛入行對監控告警這個產品還不太熟悉的新業務運維同學。

• 想自己建設監控告警的運維同學或者運營建設同學。

• 正在建設監控告警平臺的運維同學或者產品經理。

• 對監控告警產品天天使用的業務運維同學。

萬丈高樓平地起

本章主要介紹一些關於監控的通用方法論，我們先理清一些基本概念。

• 監控的定義是什麼？

• 監控的方式是什麼？

• 監控的型別有哪些？

• 監控的目標是什麼？

• 監控的本質是什麼？

• 監控的目的是層面？

• 監控的產品屬性如何理解？

監控的定義

通過技術手段發現服務異常，持續優化業務可用性與使用者體驗。這句話的關鍵詞是 發現  持續優化 可用性與體驗。

監控的方式

主動：程式內部埋點，服務主動上報自身的執行情況，一般都是具化為業務的各個屬性或者指標，這種方式準、快，靈活性好，指標豐富。但是在非標準框架下會有一定的程式碼改造成本。

被動：無需埋點，從外部探測或獲取服務的執行情況，例如ping探測、日誌採集分析等等。

旁路：與程式邏輯無關，對服務質量與口碑的監控，例如輿情分析。

那麼這三類有優劣之分嗎？其實沒有，這裡的方式都是針對於不同場景的，例如對域名的監控，就可以通過該域名的外部撥測來達到監控的目標，域名的訪問耗時也可以通過不同的撥測點來監控。在我們騰訊內部QQ和Qzone兩個海量業務對這三類監控都應用到了。

監控的型別

從大的物件範疇與層級關係來說，監控一般分為五種型別

• 基礎監控：這裡的基礎監控囊括範圍比較廣主要指IAAS層(伺服器、系統、網路等)

• 服務端監控：一般指後臺服務，例如QQ的後臺訊息服務

• 客戶端監控：一般指app，手Q的客戶端與微信的客戶端。

• WEB監控：一般指網站，例如對網站域名的撥測。

• 使用者端監控：一般指使用者輿情監控，例如某個APP的口碑好壞
  

監控的目標

一個好的監控體系應該要達到以下三點目標

• 全：監控物件的廣度，監控點的覆蓋率，例如上文提到的5種物件型別是否都能覆蓋到

• 快：監控的效能，資料流的處理能力

• 準：智慧分析與收斂、監控物件收攏
  

監控的本質

在DevOps中，運維、開發、測試這三個角色應該視角統一，這裡為什麼說要視角統一，就是大家在監控這個層面關注的點應該是一致的，而不是你關注你的點，我關注我的點。例如所有的業務監控都可以抽象出三個核心指標：請求量、成功率、耗時。這三個關鍵指標來判斷我們服務的可靠性，通過可靠性可以推算出可用性，並且可以間接反映使用者使用我們產品的的體驗。例如如果服務的可靠性不好，那麼使用者的產品體驗肯定不會好。

監控的目的

通過對上文的一些概念介紹，其實我們已經可以推匯出應用監控告警的目的，就是持續優化業務服務質量，並建設質量體系。同樣織雲監控也是為了打造質量體系的閉環路徑。

監控告警的產品屬性

監控告警是一款資料類屬性的產品，既然是資料類產品，那麼在產品設計的時候一定要注意這樣的路徑閉環 資料生產→資料增值→資料消費，圍繞著這樣的路徑我們就可以勾勒出很多的使用者故事，使用者故事就是針對具體的角色，會有什麼具體的活動，這個活動所產生的價值。

這裡舉個簡單的例子，來說明資料生產與資料消費。隨著後面詳細的講述產品建設過程中會更加詳細的闡述這個閉環的路徑。
資料生產：例如一臺伺服器上報的各種基本的 OS 指標資料，如 CPU 使用率，記憶體使用量等。這就產生了若干待消費的原始資料，那麼我們能用這些資料幹什麼呢？

資料消費：對這些上報的原始資料整理可以用作檢視展示，例如圖形化展示該服務在最近一個小時的 CPU 使用率。 又或者對這些原始資料設定閾值，當超過某個閾值的時候，就產生告警通知。這些都是最直接的消費的場景。

我們再延伸一步對於這些消費場景產生的告警資料，是否可以再進一步消費呢？答案是可以的，例如對若干承載 CPU 計算型業務的伺服器所產生的cup使用率告警(生產)時間進行分析統計(消費)，是不是可以基本推匯出該業務的服務高峰期是大概在那個時間範圍呢？
這裡想說明的是多數原子資料並無單一的消費或者生產的屬性，而是要取決於在具體的場景與所處的資料鏈條中的角色。

並且監控告警的資料加上特定的流程（ITSM）也可以驅動監控告警+自動化的大的業務邏輯互動閉環，這個場景容我先賣個關子，後面的敘述會再次提及到這部分。

監控體系

體系，泛指一定範圍內或同類的事物按照一定的秩序和內部聯絡組合而成的整體，是不同系統組成的系統。其實這個描述是有些抽象的，咱們用大白話套用監控體系來解讀下。

對於一個有一定體量的公司，需要一些不同的監控系統，通過系統與系統間的內部互動來組成一個大的整體，從而完成對不同場景下的監控需求即監控體系。用我們內部來舉例說，我們內部在現網上跑的監控系統也有快10套了，同樣在構建體系時關鍵的部分也是要用動態的視角去看待這些系統所產生的資料，而不是每個系統都是一個孤立的資料孤島。下圖是織雲整體的監控體系。

在織雲監控告警產品建設過程中，我們融入了很多關於海量運維的監控思考與經驗沉澱。

這裡的監控體系是和公司體量大小有直接關係的，但是一般來說在這個體系中，應該有三類監控系統是必備的。

總結

通過上文的簡單介紹，相信大家對監控告警會有個初步的巨集觀認識，隨著後續文章的鋪開，大家會逐步瞭解到一個企業級的監控產品是怎樣從0到1演化而來的。同時下篇文文章就會進入到實戰階段。建設監控告警是一條持續且漫長的路也是蠻複雜的，坑也很多，但還是有一些基本的方法論和規律可以遵循的。