統壹監控平臺，說到底本質上也是壹個監控系統，監控的基本能力是必不可少的，回歸到監控的本質，先梳理下整個監控體系：
① 監控系統的本質是通過發現故障、解決故障、預防故障來為了保障業務的穩定。
② 監控體系壹般來說包括數據采集、數據檢測、告警管理、故障管理、視圖管理和監控管理6大模塊。而數據采集、數據檢測和告警處理是監控的最小閉環，但如果想要真正把監控系統做好，那故障管理閉環、視圖管理、監控管理的模塊也缺壹不可。
壹、數據采集
1、采集方式
數據采集方式壹般分為Agent模式和非Agent模式；
Agent模式包括插件采集、腳本采集、日誌采集、進程采集、APM探針等
非Agent模式包括通用協議采集、Web撥測、API接口等
2、數據類型
監控的數據類型有指標、日誌、跟蹤數據三種類型。
指標數據是數值型的監控項，主要是通過維度來做標識。
日誌數據是字符型的數據，主要是從中找壹些關鍵字信息來做監控。
跟蹤型數據反饋的是跟蹤鏈路壹個數據流轉的過程，觀察過程中的耗時性能是否正常。
3、采集頻率
采集頻率分秒級、分鐘級、隨機三種類型。常用的采集頻率為分鐘級。
4、采集傳輸
采集傳輸可按傳輸發起分類，也可按傳輸鏈路分類。
按傳輸發起分類有主動采集Pull（拉）、被動接收Push（推）
按傳輸鏈路分類有直連模式、Proxy傳輸。
其中Proxy傳輸不僅能解決監控數據跨網傳輸的問題，還可以緩解監控節點數量過多導致出現的數據傳輸的瓶頸，用Proxy實現數據分流。
5、數據存儲
對於監控系統來說，主要有以下三種存儲供選擇
① 關系型數據庫
例如MySQL、MSSQL、DB2；典型監控系統代表：Zabbix、SCOM、Tivoli；
由於數據庫本身的限制，很難搞定海量監控的場景，有性能瓶頸，只在傳統監控系統常用
② 時序數據庫
為監控這種場景設計的數據庫，擅長於指標數據存儲和計算；例如InfluxDB、OpenTSDB（基於Hbase）、Prometheus等；典型監控系統代表：TICK監控框架、 Open-falcon、Prometheus
③ 全文檢索數據庫
這類型數據庫主要用於日誌型存儲，對數據檢索非常友好，例如Elasticsearch。
二、數據檢測
1. 數據加工
① 數據清洗
數據清洗比如日誌數據的清洗，因為日誌數據是非結構化的數據，信息密度較低，因此需要從中提取有用的數據。
② 數據計算
很多原始性能數據不能直接用來判斷數據是否產生異常。比如采集的數據是磁盤總量和磁盤使用量，如果要檢測磁盤使用率，就需要對現有指標進行壹個簡單的四則運算，才能得到磁盤使用率。
③ 數據豐富
數據豐富就是給數據打上壹些tags標簽，比如打上主機、機房的標簽，方便進行聚合計算。
④ 指標派生
指標派生指的是通過已有的指標，通過計算得出新的指標。
2. 檢測算法
有固定規則和機器學習算法。固定算法是較為常見的算法，靜態閾值、同比環比、自定義規則，而機器學習主要有動態基線、毛刺檢測、指標預測、多指標關聯檢測等算法。
無論是固定規則還是機器學習，都會有相應的判斷規則，即常見的< > >=和and/or的組合判斷等。
三、告警管理
1. 告警豐富
告警豐富是為了後續告警事件分析做準備，需要輔助信息去判斷該怎麽處理、分析和通知。
告警豐富壹般是通過規則，聯動CMDB、知識庫、作業歷史記錄等數據源，實現告警字段、關聯信息的豐富；通過人工打Tags也是壹種豐富方式，不過實際場景下由於人工成本高導致難以落地。
2. 告警收斂
告警收斂有三種思路：抑制、屏蔽和聚合
① 抑制
即抑制同樣的問題，避免重復告警。常見的抑制方案有防抖抑制、依賴抑制、時間抑制、組合條件抑制、高可用抑制等。
② 屏蔽
屏蔽可預知的情況，比如變更維護期、固定的周期任務這些已經知道會發生的事件，心裏已經有預期。
③ 聚合
聚合是把類似或相同的告警進行合並，因為可能反饋的是同壹個現象。比如業務訪問量升高，那承載業務的主機的CPU、內存、磁盤IO、網絡IO等各項性能都會飆升，這樣把這些性能指標都聚合到壹塊，更加便於告警的分析處理。
3. 告警通知
① 通知到人
通過壹些常規的通知渠道，能夠觸達到人。
這樣在沒有人盯屏的時候，可以通過微信、短信、郵件觸發到工作人員。
② 通知到系統
壹般通過API推送給第三方系統，便於進行後續的事件處理
另外還需要支持自定義渠道擴展（比如企業裏有自己的IM系統，可以自行接入）
四、故障管理
告警事件必須要處理有閉環，否則監控是沒有意義的。
最常見還是人工處理：值班、工單、故障升級等。
經驗積累可以把人工處理的故障積累到知識庫裏面，用於後續故障處理的參考。
自動處理，通過提取壹些特定告警的固化的處理流程，實現特定場景的故障自愈；比如磁盤空間告警時把壹些無用日誌清掉。
智能分析主要是通過故障的關聯分析、定位、預測等AI算法，進壹步提升故障定位和處理的效率；
1. 視圖管理
視圖管理也屬於增值性功能，主要是滿足人的心理述求，做到心中有底，面向的角色很多（領導、管理員、值班員等）。
大屏：面向領導，提供全局概覽
拓撲：面向運維人員，提供告警關聯關系和影響面視圖
儀表盤：面向運維人員，提供自定義的關註指標的視圖
報表：面向運維人員、領導，提供壹些統計匯總報表信息，例如周報、日報等
檢索：面向運維人員，用於故障分析場景下的各類數據檢索
2. 監控管理
監控管理是企業監控落地過程中的最大挑戰。前5個模塊都是監控系統對外提供的服務功能，而監控管理才是面向監控系統自身的管理和控制，關註真正落地的過程的功能呈現。主要有以下幾個方面：
配置：簡單、批量、自動
覆蓋率：監控水平的衡量指標
指標庫：監控指標的規範
移動端：隨時隨地處理問題
權限：使用控制
審計：管理合規
API：運維數據最大的來源，用於數據消費
自監控：自身穩定的保障
為了實現上述監控六大基礎能力模塊，我們可以按如下架構設計我們的統壹監控平臺。
主要分三層，接入層，能力層，功能層。
接入層主要考慮各種數據的接入，除了本身Agent和插件的采集接入，還需要支持第三方監控源的數據接入，才能算壹個完整的統壹監控平臺。
能力層主要考慮監控的基礎通用能力，包含數據采集模塊、數據存儲模塊、數據加工模塊、數據檢測模塊、AI分析模塊。
功能層需要貼近用戶使用場景，主要有管理、展示兩類功能，在建設的過程中可以不斷豐富功能場景。
另外，考慮到數據的關聯關系，為未來的數據分析打下基礎，監控和CMDB也需要緊密聯動，所有的監控對象都應該用CMDB進行管理，另外，還可以配置驅動監控為指導理念，實現監控的自動上下線，告警通知自動識別負責人等場景，簡化監控的維護管理。
為了統壹監控平臺能夠在企業更好的落地，我們需要配備對應的管理體系，其中最重要的是指標管理體系。
指標管理體系的核心理念：
監控的指標體系是以CMDB為骨架，以監控指標為經脈，將整個統壹監控平臺的數據有機整合起來。
貫穿指標的生命周期管理，輔以指標的管理規範，保障監控平臺長久有序的運行。
從企業業務應用的視角出發，壹般將企業監控的對象分為6層，也可以根據企業自己的情況進行調整：
基礎設施層
硬件設備層
操作系統層
組件服務層
應用性能層
業務運營層