現如今，越來越多的企業想要建設統一監控平臺，但不知道從哪裏開始着手。比如：
◇ 有些企業會直接將監控系統頁面集成到統一監控的門戶裏，當作統一的監控平臺。
◇ 有些企業把所有告警事件集中到統一系統裏進行處理和流轉。
◇ 還有些企業把所有數據比如性能數據、日誌數據、事件數據接入大數據的平臺，企圖應用大數據平臺的計算能力來完成統一監控。
如果沒有明確的目標，缺少體系化的思考，這些做法會在後續使用的過程中面臨各式各樣的問題。
因此，我們邀請到嘉爲藍鯨產品總監蘇文老師，爲我們講解建設基於數據的統一平臺思路，希望能給有想建設統一監控平臺的企業帶來一些啓發。
一、監控系統的六大核心模塊
統一監控平臺，說到底本質上也是一個監控系統，監控的基本能力是必不可少的，迴歸到監控的本質，先梳理下整個監控體系。
監控系統的本質是通過發現故障、解決故障、預防故障，從而保障業務的穩定。
監控體系一般來說包括數據採集、數據檢測、告警管理、故障管理、視圖管理和監控管理6大模塊。
而數據採集、數據檢測和告警處理是監控的最小閉環，但如果想要真正把監控系統做好，那故障管理閉環、視圖管理、監控管理的模塊也缺一不可。
1.數據採集
1）採集方式
數據採集一般分爲Agent模式和非Agent模式。
- Agent模式包括插件採集、腳本採集、日誌採集、進程採集、APM探針等。
- 非Agent模式包括通用協議採集、Web撥測、API接口等。
2）數據類型
監控的數據類型有指標、日誌、跟蹤數據三種類型。
◇ 指標數據是數值型的監控項，主要是通過維度來做標識。
◇ 日誌數據是字符型的數據，主要是從中找一些關鍵字來做監控。
◇ 跟蹤型數據反饋的是跟蹤鏈路一個數據流轉的過程，觀察過程中的耗時是否正常。
由於數據類型不同，也衍生出三類不同的監控系統。
◇ 指標類型的監控，典型代表比如Zabbix、普羅米修斯。
◇ 日誌類常見的監控系統有日誌易、Splunk等，主要關注日誌類數據的分析和監控。
◇ 跟蹤型的系統是通過trace ID請求的過程來進行監控，即APM（應用性能監控）類型的監控，例如Dynatrace、Skywalking等。
由於三種數據互不兼容，導致數據存儲分散，不利於集中分析，而近兩年興起的OpenTelemetry，將三種數據格式的輸入和消費實現了統一，但並沒有解決存儲和分析的問題。
目前主流解決方案還是將三類數據存儲到不同的庫中，再封裝一層統一的查詢層，屏蔽數據存儲層的差異，實現集中的分析查詢。
3）採集頻率
採集頻率分秒級、分鐘級、隨機三種類型。常用的採集頻率爲分鐘級。
- 關於分鐘級與秒級
越來越多的客戶開始對秒級有一種執念，覺得越快越好，認爲越快就能更快發現問題。但是秒級的採集頻率的增加，這對目標機器性能的影響也會增加，若因爲數據採集導致業務性能本身出現問題，這就本末倒置了。
而且，隨着數據量加倍，存儲成倍增加，計算量級指數型增長，帶來的成本損耗可能遠超秒級監控帶來的好處。在真實的應用場景中，大家需要思考使用秒級頻率是否值得。這提前十幾秒的告警發現，運維人員是否能夠在這十幾秒的時間內把問題解決掉，如果解決不掉，那秒級監控並沒有太大的意義。比如騰訊遊戲的業務是以秒來賺錢，所以需要針對關鍵指標需要做到秒級監控，配合自動伸縮替換故障節點，可以實現秒級恢復。這種情況下的秒級監控必不可少。
秒級監控是監控系統的一種必備的能力，但並不是所有的指標數據都需要秒級監控，需要挖掘真正的場景需求來判斷是否需要這個秒級監控，而不是爲了秒級而秒級，白白浪費資源，徒增維護成本。
- 隨機採集
隨機適用於增量採集或觸發式採集，採集頻率不定。主要場景是日誌採集、應用系統異常事件上報。
4）採集傳輸
採集傳輸可按傳輸發起分類，也可按傳輸鏈路分類。
◇ 按傳輸發起分類有主動採集Pull（拉）、被動接收Push（推）。
◇ 按傳輸鏈路分類有直連模式、Proxy傳輸。
其中，Proxy傳輸不僅能解決監控數據跨網傳輸的問題，還可以緩解監控節點數量過多導致出現的數據傳輸的瓶頸，用Proxy實現數據分流。
5）數據存儲
對於監控系統來說，主要有以下三種存儲供選擇：
- 關係型數據庫
由於數據庫本身的限制，很難搞定海量監控的場景，有性能瓶頸，只在傳統監控系統常用。
例如MySQL、MSSQL、DB2；典型監控系統代表：Zabbix、SCOM、Tivoli。
- 時序數據庫
爲監控這種場景設計的數據庫，擅長於指標數據存儲和計算。
例如InfluxDB、OpenTSDB（基於Hbase）、Prometheus等；典型監控系統代表：TICK監控框架、 Open-falcon、Prometheus。
- 全文檢索數據庫
這類型數據庫主要用於日誌型存儲，對數據檢索非常友好，例如Elasticsearch。
2. 數據檢測
1）數據加工
- 數據清洗
數據清洗比如日誌數據的清洗，因爲日誌數據是非結構化的數據，信息密度較低，因此需要從中提取有用的數據。
- 數據計算
很多原始數據不能直接用來判斷數據是否產生異常。比如採集的數據是磁盤總量和磁盤使用量，如果要檢測磁盤使用率，就需要對現有指標進行一個簡單的四則運算，才能得到磁盤使用率。
- 數據豐富
數據豐富就是給數據打上一些tags標籤，比如打上主機、機房的標籤，方便進行聚合計算。
- 指標派生
指標派生指的是通過已有的指標，通過計算得出新的指標。
2）檢測算法
有固定規則和機器學習算法。
◇ 固定算法是較爲常見的算法，靜態閾值、同比環比、自定義規則
◇ 機器學習主要有動態基線、毛刺檢測、指標預測、多指標關聯檢測等算法。
無論是固定規則還是機器學習，都會有相應的判斷規則，即常見的< > >=和and/or的組合判斷等。
2. 告警管理
1）告警豐富
告警豐富是爲了後續告警事件分析做準備，需要輔助信息去判斷該怎麼處理、分析和通知。
告警豐富一般是通過規則，聯動CMDB、知識庫、作業歷史記錄等數據源，實現告警字段、關聯信息的豐富。
通過人工打Tags也是一種豐富方式，不過實際場景下由於人工成本高導致難以落地。
2）告警收斂
告警收斂有三種思路：抑制、屏蔽和聚合。
- 抑制
即抑制同樣的問題，避免重複告警。常見的抑制方案有防抖抑制、依賴抑制、時間抑制、組合條件抑制、高可用抑制等。
- 屏蔽
屏蔽可預知的情況，比如變更維護期、固定的週期任務這些已經知道會發生的事件，心裏已經有預期。
- 聚合
聚合是把類似或相同的告警進行合併，因爲可能反饋的是同一個現象。
比如業務訪問量升高，其他性能也飆升，這樣把這些性能都聚合到一塊，那承載業務的主機的CPU、內存、磁盤IO、網絡IO等各項性能都會飆升，這樣把這些性能指標都聚合到一塊，更加便於告警的分析處理。
3）告警通知
- 通知到人
通過一些重要的渠道，能夠觸達到人。
這樣在沒有人盯屏的時候，可以通過微信、短信、郵件觸發到工作人員。
- 通知到系統
一般通過API推送給第三方系統，便於進行後續的事件處理。另外還需要支持自定義渠道擴展（比如企業裏有自己的IM系統，可以自行接入）
3. 故障管理
告警事件必須要處理有閉環，否則監控是沒有意義的。
- 人工處理
這是最常見的方式，值班、工單、故障升級等。
- 經驗積累
可以把人工處理的故障積累到知識庫裏面，爲自動化處理做準備。
- 自動處理
通過提取一些特定告警的固化處理流程，實現特定場景的故障自愈，比如磁盤空間告警時把一些無用日誌清掉。
- 智能分析
主要是通過故障的關聯分析、定位、預測等AI算法，進一步提升故障定位和處理的效率。
4. 視圖管理
視圖管理也屬於增值性功能，主要是滿足人的心理述求，做到心中有底，面向的角色很多（領導、管理員、值班員等）。
- 大屏
面向領導，提供全局概覽。
- 拓撲
面向運維人員，提供告警關聯關係和影響面視圖。
- 儀表盤
面向運維人員，提供自定義的關注指標的視圖。
- 報表
面向運維人員、領導，提供一些統計彙總報表信息，例如週報、日報等。
- 檢索
面向運維人員，用於故障分析場景下的各類數據檢索。
5. 監控管理
監控管理是企業監控落地過程中的最大挑戰。
前5個模塊都是監控系統對外提供的服務功能，而監控管理纔是面向監控系統自身的管理和控制，關注真正落地的過程的功能呈現。主要有以下幾個方面：
◇ 配置：簡單、批量、自動
◇ 覆蓋率：監控水平的衡量指標
◇ 指標庫：監控指標的規範
◇ 移動端：隨時隨地處理問題
◇ 權限：使用控制
◇ 審計：管理合規
◇ API：運維數據最大的來源，用於數據消費
◇ 自監控：自身穩定的保障
二、監控平臺建設的現狀和傳統建設模式的挑戰
1. 監控建設的現狀
一般來說，企業監控建設的現狀主要分成四個階段：監控工具建設階段、統一監控建設階段、智能分析建設階段、主動防禦建設階段，目前大部分企業都處在第一和第二階段之間掙扎。
◇ 第一階段的主要目標是全覆蓋，能夠全面監控對象，全面感知告警。
◇ 第二個階段的核心重點在於管理，需要有統一的指標體系和統一的事件管理流程，同時也是爲第三個階段做數據的準備。
◇ 第三階段重點關注的是效率提升，之前要配很多閾值的算法，有了智能檢測算法就不需要再每個每個指標配置閾值了。而關聯影響分析能夠利用機器學習幫助機械能問題定位分析，減少人工定位分析的時間消耗。
◇ 第四階段的核心是預防，提前預測來採取一些措施，去預防相關問題的發生。比如根據磁盤損耗的速率變化趨勢，預測1個月後磁盤可能會壞掉，這樣提前更換磁盤，將事故消滅在萌芽中。
2. 傳統監控系統建設所面臨的挑戰
由於大部分傳統監控系統在建設之初並沒有考慮到統一監控，定位都是做一個監控的工具，在建設統一系統時，會面臨以下困難和挑戰：
◇ 技術演進快，監控複雜度日益升高；
◇ 監控工具多，統一治理無從下手；
◇ 工具互相隔離，無法聯動協同，效率低下；
◇ 升級擴展慢，無法響應快速發展的業務要求；
◇ 系統複雜度高，故障分析定位難，業務損失大。
以上種種挑戰都導致了企業亟待建設一個統一監控平臺。
三、從兩個層面建設統一監控平臺
1. 產品能力上
除了需要有靈活的擴展能力，能夠廣泛適配各種對象的監控數據接入外，還得有統一採集、統一檢測、統一告警、統一展示四個基本能力。
2. 產品架構上
主要爲三層：接入層、能力層、功能層.
1）接入層
主要考慮各種數據的接入，除了本身Agent和插件的採集接入，還需要支持第三方監控源的數據接入，才能算一個完整的統一監控平臺。
2）能力層
主要考慮監控的基礎通用能力，包含數據採集模塊、數據存儲模塊、數據加工模塊、數據檢測模塊、AI分析模塊。
3）功能層
功能層需要貼近用戶使用場景，主要有管理、展示兩類功能，在建設的過程中可以不斷豐富功能場景。
另外，考慮到數據的關聯關係，爲未來的數據分析打下基礎，監控和CMDB也需要緊密聯動，所有的監控對象都應該用CMDB進行管理。
還可以配置驅動監控爲指導理念，實現監控的自動上下線，告警通知自動識別負責人等場景，簡化監控的維護管理。
嘉爲藍鯨統一監控平臺的功能界面
1.基於CMDB的指標管理
聯動CMDB，把CMBD的對象納入到統一監控平臺，並對監控對象的指標進行統一管理。至於如何去梳理構建整個監控指標體系，是接下來第4部分要講解的內容。
2. 配置驅動監控
通過動態分組來實現，利用CMDB已知的屬性來作爲判斷條件，去創建動態分組。
整個分組的實例是動態變化的，只有滿足條件的的實例纔會納入分組，不滿足時會自動剔除分組。
監控如果識別到實例數的動態變化，實現監控的自動上下線操作。
3. 插件式採集擴展
監控平臺需要接受各種各樣的數據，不僅支持監控對象的數據採集。還支持將第三方監控源的數據接入到平臺，進行統一管理。
整個插件的設計可以直接在頁面進行編輯或上傳，這樣擴展性會比較強，擴展也非常簡單方便。
4. 模板化策略配置
強調模板化配置，根據不同的場景設置不同的模板。
比如說對測試環境，做一個主機測試環境的模板， 對生產環境做主機生產環境的策略模板，這樣就減少監控配置量。
5. 集中事件中心
將前面產生的策略和告警事件在事件中心呈現，給出一些輔助信息比如指標、數據流轉信息、字段等，幫助進行故障排查。
6. 動態菜單視圖功能
第一個視角是資源視角，以動態菜單的形式去做，菜單根據添加的監控對象來自動生成。
第二個視角是應用視角，形式是應用監控視圖。是爲了在應用層面來看監控對象是否正常，應用的拓撲哪些節點發生了問題等。
四、構建指標體系的理念和規範
1. 核心理念
◇ 監控的指標體系是以CMDB爲骨架，以監控指標爲經脈，將整個統一監控平臺的數據有機結合起來。
◇ 貫穿指標的生命週期管理，輔以指標的管理規範，保障監控平臺長久有序的運行。
2. 指標管理規範
1）設計原則示例
最重要的是可度量、可採集、可理解、可消費。
落到監控指標，還有兩個輔助原則，即構建統一監控指標體系規範；明確監控目標和消費場景。
2）指標分層的示例
從企業業務應用的視角出發，一般將企業監控的對象分爲6層：基礎設施層、硬件設備層、操作系統層、組件服務層、應用性能層、業務運營層。也可以根據企業自己的情況進行調整。
3. 指標分級規範
一般分三級，按重要程度區分：核心指標、關鍵指標和常規指標。
◇ 核心指標一般不會定太多，主要反映這個監控對象是活着還是死了，1到2個即可。
◇ 關鍵指標是看核心性能是否正常，參考谷歌定義的SRE四大常規指標。
◇ 常規指標可以根據實際的業務場景去考慮。
通過不同指標的分級、權重，可以建設模型，衡量整個業務的健康情況。
4. 命名規範示例
沒有絕對的標準，可讀就行，可根據企業情況自行設定。
5. 指標管理流程
目的是讓整個指標的生命週期管理順利運行下去，可以根據企業實際情況來設計相關流程。
本次直播主要講述了四個部分，第一部分講解了監控體系（採集-檢測-告警-故障-視圖-管理），第二部分講解了現狀和挑戰，第三部分介紹了統一監控平臺的產品設計（產品能力和產品架構兩個角度），第四部分梳理了指標體系的建設管理（核心是以CMDB爲骨架、以監控指標爲經脈），保障統一監控平臺的順利落地。
精選互動問答
問：告警豐富階段的處理時間，是否會影響到告警發送的及時性呢？
答：告警豐富是需要一定的時間損耗的，會影響告警發送及時性，但是相對於後期去找這些信息的時間來看，告警豐富所花時間幾乎可以忽略不計，另外告警豐富之後，帶來的更多信息除了可以輔助排錯，還可以根據豐富的新的字段進行收斂、聚合等。
問：監控模板也是放置在CMDB嗎，還是放在監控平臺呢？
答：監控模板肯定放在監控平臺，只不過監控模板應用的對象範圍可以和CMDB聯動，效果更佳
問：統一監控裏包含網絡性能監控嗎？
答：統一監控平臺是可以接入第三方網絡監控系統數據的，例如Zabbix。
問：統一監控初期建設的時候，需要對接很多已有監控平臺，比如Zabbix、Prometheus、聽雲、網管neteagle等，這個階段應該如何對現有監控的納管呢？
答：可以考慮分階段建設：
1、建設CMDB，將所有的監控系統的監控對象和CMDB的對象對齊，爲統一監控建設打下基礎
2、將所有的監控系統的告警事件進行統一管理，聯動CMDB進行告警的收斂和影響分析，提升告警處理效率，節省告警處理的時間，釋放人力進行後期建設
3、梳理企業內部的指標管理體系，建立監控的管理規範和流程，將所有的監控系統的性能數據按指標體系接入統一監控平臺，注意聯動CMDB，實現統一管理和視圖
4、引入AI平臺，基於統一監控平臺的數據進行智能檢測和分析，進一步提升人效
問：監控系統和告警系統是兩個團隊去開發的麼? 兩者會有一些耦合的部分麼? 比如對於CMDB 的依賴。
答：監控系統和告警系統是分開開發的，但是產品設計是統一設計的，兩套系統可以直接聯動，監控系統的告警事件可以直接推送到告警系統中，並且可以關閉監控系統中原有的告警通知功能，讓兩邊的聯動更加友好。且監控系統中和CMDB建立的關聯關係，推送到告警系統中之後，CMDB關聯關係依舊會保存下來，不必要重複建設關聯關係。