監控系統的本質是通過發現故障、解決故障、預防故障來為了保障業務的穩定。而要想在企業內實現監控系統的體系化建設落地，需要從以下三個方面著手建設，分別是監控技術體系、監控指標體系、監控管理體系。

01. 監控技術體系

一般來說，一個完整的監控系統，可以抽象為采集+數據+算子+告警四個基本模塊，缺一不可。

1）采集

① 采集方式

數據采集方式一般分為Agent模式（Agent-based）和非Agent模式（Agentless）；

Agent模式包括各種插件采集、各種格式的腳本采集、主機日志采集、主機進程采集、APM探針和SDK等；

非Agent模式包括SNMP、IPMI/Redfish、SSH、JMX、ODBC/JDBC、Syslog、ICMP、HTTP(s)、TCP/UDP、SMTP等各種通用協議的數據采集。

② 采集頻率

采集頻率一般有分秒級、分鐘級之分，常用的采集頻率為分鐘級；同時也有基于條件觸發式的隨機采集或上報。

關于分鐘級與秒級也有不少爭論，常有人認為越快越好，認為越快就能更快發現問題。但是秒級的采集頻率的增加，這對目標機器性能的影響也會增加，若因為數據采集導致業務性能本身出現問題，這就本末倒置了。而且，隨著數據量加倍，存儲成倍增加，計算量級指數型增長，帶來的成本損耗可能遠超秒級監控帶來的好處。

在實際的應用場景中，需要思考使用秒級頻率是否真的值得，是否能帶來對應的業務價值。秒級監控是監控系統的一種必備的能力，但并不是所有的指標都需要秒級監控，需要挖掘真正的價值場景，而不是為了秒級而秒級，白白浪費資源，徒增維護成本。

③ 采集傳輸

采集傳輸按傳輸發起模式分類有主動采集Pull（拉）、被動接收Push（推）；按傳輸鏈路分類有直連模式、Proxy傳輸。其中Proxy傳輸不僅能解決監控數據跨網傳輸的問題，還可以緩解監控節點數量過多導致出現的數據傳輸的瓶頸，用Proxy機制實現數據傳輸負載分流。

2）數據

① 數據類型

監控的數據類型有指標（Metrics）、日志（Logs）、調用鏈（Traces）三種類型。指標數據是數值型的監控項，主要是通過維度來做標識；日志數據是字符型的數據，主要是從中找一些關鍵字信息來做監控；調用鏈數據反饋的是跟蹤鏈路一個數據流轉的過程，觀察過程中的耗時性能是否正常。

由于數據類型不同，也衍生出了三類不同的監控系統。指標類型的監控，典型代表比如Zabbix、普羅米修斯。日志類常見的監控系統有ELK、Splunk等，主要關注日志類數據的分析和監控。調用鏈是通過TraceID來追蹤請求的過程來進行監控，即APM（應用性能監控），例如Dynatrace、Skywalking等。

② 數據存儲

對于監控系統來說，主要有以下三種存儲供選擇：

• 關系型數據庫：例如MySQL、MSSQL、DB2；典型監控系統代表：Zabbix、SCOM、Tivoli；但由于數據庫本身的限制，很難搞定海量監控的場景，有性能瓶頸，只在傳統監控系統常用，逐漸被淘汰。
• 時序數據庫：幾乎可以說是為監控這種場景設計的數據庫，擅長于指標數據存儲和計算；例如InfluxDB、OpenTSDB（基于Hbase）、Prometheus等；典型監控系統代表：TICK監控、 Open-falcon、Prometheus。
• 全文檢索數據庫：這類型數據庫主要用于日志型存儲，Traces數據也可以存儲，對數據檢索非常友好，例如Elasticsearch。

③ 數據視圖

數據視圖主要是將監控的數據以一種人類便于理解的方式呈現出來，面向不同的角色會有不同的呈現方式，例如領導、管理員、值班員等關注的點都不一樣。常見的數據視圖模式有以下幾種：

• 大屏：面向領導，提供全局概覽；也可以面向值班員，提供盯屏視圖；
• 拓撲：面向運維人員，提供告警關聯關系和影響面視圖；
• 儀表盤：面向運維人員，提供自定義的關注指標的視圖；
• 報表：面向運維人員、領導，提供一些統計匯總報表信息，例如周報、日報等；
• 檢索：面向運維人員，用于故障分析場景下的各類數據的快速查找和定位。

3）算子

① 數據加工

數據加工一般分為：數據清洗、數據計算、數據豐富、指標派生。

• 數據清洗：比如日志數據的清洗，因為日志數據是非結構化的數據，信息密度較低，因此需要從中提取有用的數據。
• 數據計算：很多原始性能數據不能直接用來判斷數據是否產生異常。比如采集的數據是磁盤總量和磁盤使用量，如果要檢測磁盤使用率，就需要對現有指標進行一個簡單的四則運算，才能得到磁盤使用率。
• 數據豐富：就是給數據打上一些tags標簽，比如打上主機、機房的標簽，方便進行聚合計算。
• 指標派生：指的是通過已有的指標，通過各種公式計算得出新的指標，在一些統計指標的場景中比較常用。

② 數據檢測

有固定規則和AI算法。固定算法是較為常見的算法，靜態閾值、同比環比、自定義規則，而機器學習主要有動態基線、毛刺檢測、指標預測、多指標關聯檢測等算法。無論是固定規則還是機器學習，都會有相應的判斷規則，即常見的< > >=和and/or的組合判斷等。

4）告警

① 告警收斂

告警收斂有三種思路：抑制、屏蔽和聚合。

• 抑制：即抑制同樣的問題，避免重復告警。常見的抑制方案有防抖抑制、依賴抑制、時間抑制、組合條件抑制、高可用抑制等。
• 屏蔽：屏蔽可預知的情況，比如變更維護期、固定的周期任務這些已經知道會發生的事件，心里已經有預期。
• 聚合：聚合是把類似或相同的告警進行合并，因為可能反饋的是同一個現象。比如業務訪問量升高，那承載業務的主機的CPU、內存、磁盤IO、網絡IO等各項性能都會飆升，這樣把這些性能指標都聚合到一塊，更加便于告警的分析處理。

② 告警通知

• 通知到人：通過一些常規的通知渠道，能夠觸達到人。這樣在沒有人盯屏的時候，可以通過微信、短信、郵件觸發到工作人員。
• 通知到系統：一般通過API推送給第三方系統，便于進行后續的事件處理。

對于一個成熟的監控，還需要支持自定義通知渠道擴展（比如企業里有自己的IM系統，可以自行接入）

關于上述4個方面便是一個站在技術的角度對監控系統的一個抽象，但是要落地監控系統，僅僅依靠一個技術強大的工具是遠遠不夠的；接下來介紹的將是監控系統的核心數據管理—監控指標體系。

02. 監控指標體系

為什么要搭建指標體系？通過指標體系監測應用運行的狀況，最大的價值就是高效利用時間，把時間花在解決問題上，而不是尋找問題上，從而提高整體的人效。指標體系的輸出結果應當是一份指標字典，需要至少滿足以下要求：

• 成體系化的指標，能夠從多維度了解應用運行的現狀
• 在應用運行出現問題時能夠快速定位問題所在
• 高效地為運維團隊提供數據支持

1）核心理念

• 監控的指標體系是以監控對象為骨架，以監控指標為經脈，將整個監控系統的數據有機整合起來。
• 指標體系的設計原則最重要的是可度量、可采集、可理解、可消費。
• 貫穿指標的生命周期管理，輔以指標的管理規范，才能保障監控平臺長久有序的運行。

2）體系設計

從企業業務應用的視角出發，一般將企業監控的對象分為6層：基礎設施層、硬件設備層、操作系統層、組件服務層、應用性能層、業務運營層；也可以根據企業自己的情況進行調整。

① 基礎設施層

• 基礎設施層，一般指機房的基礎設施配備，用于保證機房的正常運轉，包含動力、環境、安防等設備。即機房動環監控的核心關注點。
• 動力主要包含供電系統、發電機、UPS電源等電力供應設備，核心關注電力的狀態、容量、電壓、電流、穩定性、頻率等指標。
• 環境主要包含溫濕度計、空調、通風等環境監測和調節設備，核心關注環境設備的運行狀態、環境溫度、濕度等指標。
• 安防主要包含視頻攝像頭、門禁、煙霧探測器、消防設備等安全防護設備，核心關注設備的運行狀態、視頻穩定性、門禁狀態等指標。

② 硬件設備層

• 硬件設備層，一般指服務器、存儲、網絡、安全四類常見硬件設備對象，用于提供應用運行所需的硬件資源。即基礎硬件監控的核心關注點。
• 服務器設備主要包含X86服務器、小機、大機等計算資源設備，隨著分布式計算技術的普及，小機、大機這種性能超強的專用機器逐漸淘汰，X86服務器成為當下主流；核心關注服務器的電源、CPU、內存、磁盤、風扇等配件的工作狀態和性能指標。
• 存儲設備主要包含磁盤整列、磁帶庫、存儲交換機等存儲資源設備，隨著虛擬存儲的技術的出現，專用而昂貴的存儲設備逐漸減少，取而代之的是廉價的服務器設備配合大量的硬盤通過虛擬化技術提供的存儲資源；核心關注存儲設備的容量、IOPS、運行狀態、讀寫速率等指標。
• 網絡設備主要包含交換機、路由器、負載均衡等網絡資源設備；核心關注網絡設備的運行狀態、端口狀態、端口流量、吞吐量、錯誤包、丟包率等指標。
• 安全設備主要包含防火墻、入侵檢測設備、防病毒設備、加密機等；核心關注安全設備的運行狀態、接口狀態、速率、丟包數、網絡攻擊數等指標。

③ 操作系統層

• 操作系統層，除了包含傳統意義上的各類操作系統之外，還把虛擬化、容器也納入該層，主要是考慮到虛擬化、容器本質上也是由操作系統驅動而提供的一種資源服務，如有需要，單獨劃分管理也未嘗不可。
• 操作系統主要包含Windows Server、Linux系的CentOS、RHEL、Suse、Ubuntu、AIX、HP-Unix等服務器操作系統；核心關注CPU使用率、內存使用率、磁盤使用率、磁盤IO速率、網卡流量等指標。
• 虛擬化主要包含VMware、OpenStack、KVM、Citrix等虛擬化平臺；核心關注平臺主機、集群、存儲的狀態和資源容量、資源數、配額等指標。
• 當前的容器監控主要指K8s容器管理平臺的監控；核心關注Cluster、Namespace、Service、Pod、Workload、Node等資源的狀態、CPU負載、內存使用、磁盤使用、網絡流量等指標。

④ 組件服務層

• 組件服務層，一般指數據庫、中間件及其運行進程等軟件資源對象，部分監控系統經常將進程歸屬于操作系統監控，或者獨立進行監控，反應的都是進程本身的狀態，但是進程本質是各種數據庫、中間件軟件資源服務化的表現形式，應當隸屬于資源實例監控的一部分。
• 數據庫主要包含企業常用的各種關系型數據庫MySQL、Oracle、MSSQL等，以及非關系型數據庫MongoDB、Redis、InfluxDB等；核心關注的是數據庫的連接數、讀寫速率、鎖、索引命中率、連接數等指標。
• 中間件主要包含Web中間件、消息中間件兩種，例如WebLogic、Was、Tomcat、kafka、RabbitMQ等，其它的還有配置中間件、分布式事務、任務調度中間件等；核心關注的是中間件的吞吐量、連接數、JVM性能等指標。
• 一般只有數據庫、中間件或者應用本身的進程才會進行監控，進程監控核心關注進程狀態、端口狀態、進程的性能使用率等指標。

⑤ 應用性能層

• 應用性能層，一般包含應用系統服務端和客戶端兩個方面，其中服務端主要指調用鏈，客戶端主要包含移動端APP、PC端Web頁面。
• 對于服務端的調用鏈，核心關注可用率、錯誤率、響應時間、吞吐率等關鍵性能指標。
• 對于客戶的移動端APP和PC端的Web頁面，核心關注瀏覽量、請求數、首屏時間、渲染時間、可用率、響應時間等關鍵性能指標。
• 另外，對于應用和服務的基礎探活，也可以采用協議撥測的方式來實現，此時主要關注網站或接口的撥測可用率、撥測響應時間。

⑥ 業務運營層

• 業務運營層，主要指業務系統中的業務數據的監控，一般需要根據業務系統的特點來進行梳理，常見的業務系統主要關注交易量、交易耗時、庫存量、用戶數、活躍用戶數、在線用戶數等業務核心指標

⑦ 指標分級管理

根據上述梳理的指標清單，對于指標本身也建議能夠做一個分級管理。一般分三級，按重要程度區分：核心指標、關鍵指標和常規指標。

• 核心指標一般不會定太多，主要反映這個監控對象是活著還是死了，1到2個即可。
• 關鍵指標是看核心性能是否正常，參考谷歌定義的SRE四大黃金指標。
• 常規指標可以根據實際的業務場景去考慮。

核心指標一定要配置告警基線，關鍵指標建議配置，而常規指標可以按業務場景考慮是否配置。后續通過不同指標的分級、權重，便可以很容易地建設起企業內地應用健康評估模型，衡量整個應用的健康情況。

通過上述分層分類的指標體系設計，可以對企業內的指標進行一個清晰的歸納和管理，再結合一套優秀的監控工具，便可實現企業IT資源應用的無死角監控，但要想監控系統在企業內實現長治久安，甚至不斷進化，還得搭配下面即將介紹的監控管理體系。

03. 監控管理體系

監控的管理最重要的便是告警閉環管理，很多企業建設了很多套監控系統，都能產生告警，但是告警之后呢？沒有然后了。對于監控體系的落地，運營管理比系統建設更加重要。只有將監控系統產生的告警治理起來，監控系統才能發揮其應有的價值，監控體系化建設過程才能出現正向的進化，而不是用著用著就沒用了。

1）告警閉環管理

告警事件的閉環管理可以分為三個大的階段，事前、事中、事后。事前核心關注發現問題的發現和預防，提示告警處理的效率；事中核心關注快速發現和解決問題，快速恢復業務，保障業務連續性，降低損失；事后核心關注問題的根因復盤，優化告警預防的方案和下次告警處理的效率。

① 告警預防管理（事前）

告警預防階段，主要是針對可能出現的問題進行規避，核心是評估、調優、監測和預案。

• 評估：可以通過性能壓測、人員測試等方式，評估系統的可用性和性能瓶頸，作為提前擴容調優的依據。
• 調優：根據測試評估的結論以及歷史問題的反饋建議，對應用系統進行架構、容量、性能等方面的優化，以防事故發生。
• 監測：提前建設一些監控、巡檢等工具，即前兩部分中的監控系統建設，對應用系統的一些關鍵指標進行實時或定期檢測，便于及時發現問題，提前解決問題，降低問題的影響時間。
• 預案：對于一些可能發生的問題，組織團隊一起做出對應的方案，以便在事故真實發生時能夠快速處理，最大可能性降低損失；例如災備、降級、限流等方案。

② 告警處理管理（事中）

告警處理階段流程最為復雜，又可以分為告警感知、告警響應、告警定位、告警恢復4個過程。

在具體談告警處理之前，先說說告警分級，只有對告警提前進行分級，才能在告警發生時有條不紊，采取不同的應對策略。告警一般分為三級，致命、警告、提醒。致命告警一般代表服務已經異常，需要馬上進行處理；警告告警一般代表如果不進行及時處理，服務即將異常；提醒告警一般代表一些潛在問題，需要開始關注或提前采取行動，避免異常產生。另外，告警分級的設定的影響因子也有很多，一般來說對象等級、指標等級、所屬環境（生產/測試/準生產等）、業務重要性等為核心考慮因子。

• 告警感知：發現并感知到告警，有兩種方式。一種是通過系統檢測并通知到人，例如監控檢測、主動撥測、輿情監測、健康巡檢等；另一種是通過人工發現并反饋，例如關鍵應用盯屏機制、用戶報障、服務臺上報、測試人員上報等。
• 告警響應：接收并響應告警，也有兩個過程。首先是處理人接收到自己負責的告警，主要是通過多種渠道（例如郵件、短信、電話、微信等）的通知，告警系統/服務臺的分派，零線/一線無法處理告警的升級，值班室/值班群的通報機制等；然后是處理人響應告警，根據不同告警的處理策略，會有服務臺響應、值班組響應、運維組響應、專家組響應等不同級別的響應模式。
• 告警定位：快速定位告警的問題，一般都是以人員經驗為主，工具為輔進行快速定位。可以從各種數據著手，對指標、日志、鏈路數據進行快速分析；也可以從周邊關聯入手，是否是關聯問題影響或者影響到了其它系統；還可以從變更歷史記錄中尋找可能的問題；目標是快速找到問題的原點，便于快速決策解決方案，特別注意，此時最關鍵的是問題解決的速率，而不是問題的根因分析，尤其是技術人員千萬不要陷入問題根因定位中。
• 告警恢復：通過一系列行之有效的方案快速恢復應用系統的功能，可以通過問題節點隔離、負載限流、服務降級、資源擴容、應用重啟、切換災備、問題系統重裝上線等方式，快速恢復核心業務服務，盡可能減少損失。

③ 復盤改進機制（事后）

告警復盤改進也可以分3個部分，分別是問題復盤、經驗積累、改進優化。

• 問題復盤：核心目的是找出問題的根因，徹底解決問題，并且需要留下問題復盤報告，以防下次類似問題。
• 經驗積累：經驗積累最重要的便是知識庫建設，據了解很多企業都有知識庫，但是并沒有真正用起來。建設知識庫要注重3個點；一是以終為始，消費驅動，而不是為了沉淀而建設，一定要保障知識庫的易用性，具備強大的檢索能力，便于快速找到想要的知識；二是工具承載，基于知識消費場景豐富知識庫，打通聯動各個系統，自動匯聚知識經驗；三是流程保證，設立專門的知識管理組織，保障知識庫的落地和持續運營。
• 改進優化：回歸本質，監控體系的建設不僅僅是為了出現問題后解決問題，而是為了不出或少出問題，故除了監控系統本身的使用優化之外，反推業務應用的優化才是根本。
• 告警關閉分析：統計直接關閉告警數、自動恢復數，分析原因，判斷該項是否需要持續監控，是否可以優化告警策略？
• 誤告警分析：通過打標簽的方式標記誤告警，可進一步優化告警策略，精準告警。
• 告警排行分析：業務告警數排行、資源對象告警數排行、指標告警數排行、跨區業務的區域告警數排行等，對于高頻告警業務、對象、指標、區域等進行重點整治，優化業務應用系統。
• 自愈告警分析：自愈告警數、自愈告警成功率，自愈是否有誤？自愈流程是否可以進一步優化？

為了更好的落地監控體系，還得有建設成果的衡量指標，主要可以從監控覆蓋廣度和告警處理效率兩方面來看。

2）運營管理指標

① 監控覆蓋率

主要是監控對象采集覆蓋率、監控指標覆蓋率兩個指標，主要衡量監控的推廣使用情況。監控對象采集覆蓋率一般通過監控任務覆蓋的對象實例數和CMDB中該對象的實例總數進行對比得出；監控指標覆蓋率，一般是某個實例的規劃指標總數和該實例的采集指標數進行對比得出。

② 告警處理指標

從告警生命周期的過程來看，會有告警發生時間、發現時間、響應時間、診斷時間、告警處理開始時間到告警恢復時間等關鍵時間節點，衡量告警管理會有如下幾個關鍵指標。

• MTTI（平均告警發現時間）=發現時間-發生時間（一般可忽略）
• MTTA （平均告警響應時間）=響應時間-發現時間
• MTTR（平均告警恢復時間） =恢復時間-發生時間
• MTBF（平均無故障告警時間）=運行時間-故障時間

告警管理的根本目標便是降低MTTA，縮短MTTR，提升MTBF。即：快速發現并響應故障；快速定位并解決故障；減少故障發生，提升業務連續性。

其中的MTTA、MTTR便是運維團隊工作的告警處理的最好衡量指標，直接反饋了團隊的告警處理效率和告警處理能力。