近年來，隨着計算機技術的飛速發展，以及行業信息的共享，傳統企業的運維己不再固步自封，日新月異的計算技術發展推動着企業雲平臺的建設，雲平臺的計算能力爲大數據分析提供了基礎，而云平臺與大數據分析又將推動運維人工智能的發展。
放眼雲、大數據、人工智能的運維發展方向的同時，作爲運維的生命線，安全生產保障的生命線仍需強調。作爲傳統企業的安全生產保障，主要以“監、管、控”爲核心，其中“監”則主要指的是監控。
本文將把筆者在工作過程中積累的監控體系建設知識進行總結，梳理成體系，思維導圖如下：
監控體系分層
概述
傳統企業的運維經過多年的積累，往往己沉澱下來不少監控工具，有不同專業條的工具，如基礎設施、硬件、軟件、安全等；也有不同類型的工具，如基於日誌、數據庫、中間件、操作系統、網絡報文等。對於這些工具，我們採用以下方式處理：
建立集中監控平臺：在一體化運維體系中，監控平臺貫穿所有環節，它起到了生產系統涉及的軟硬件環境實時運行狀況的“監”，監控平臺事件驅動的特性也爲一體化運維體系起到神經網絡驅動的作用，進而進行了“控”，另外，監控平臺優質的運維數據可以作爲運維大數據分析的數據源，實現運維數據採集的角色。爲了提高投入效率，減少重複投入，需要建立集中監控平臺實現統一展示、統一管理，支持兩地三中心建設，具備靈活的擴展性，支持運維大數據分析。
原有的監控工具保留爲主：當前並沒有哪一個監控工具可以覆蓋所有生產系統的運行指標，己沉澱下來的監控工具往往是當前生產系統深度定製的工具，具有存在價值。另外，雖然監控平臺從WEB、APP、到DB均採用了多中心雙活分佈式架構部署，但爲了保證監控覆蓋能力，部份重要的環節仍建議不僅限一套監控工具。
各專業條線對各條線的監控負責：各專業條線是最清楚自己需要什麼監控的團隊，各專業條線對監控覆蓋率負責，監控平臺的建設方負責平臺體系的建設，提供基礎技術支撐。
工具間整合：不同的專業條線、不同的分析技術可以有不同的監控工具，採用這種多點開花的建設方式更有助於監控面與深度的完善，所有的工具最終需要進行標準化的整合。
基於上面4個處理思路，爲防止監控建設失控，減少重複建設、明確主要的建設目標，我們需要對監控工具進行體系化管理，體系化管理首先要做的就是進行監控體系分層。
分層方式
相信每家企業對於監控分層體系都會有各自的劃分方式，以下是以專業條線方式分層：
基礎設施層：包括運營商專線、機房（機房內的設施，比如製冷、安防等）、網絡設備，基礎設施層的監控分爲狀態、性能、質量、容量、架構、流量分析等幾個層面。
系統服務器層：包括系統服務器、存儲等服務器的可用性狀態。
系統及網絡服務層：主要是指操作系統、系統軟件、網絡軟件的使用情況。
應用服務層：主要是針對應用服務可用性、應用營業狀態、應用性能、應用交易量分析幾方面。
客戶體驗層：包括兩塊，一是客戶訪問速度；二是功能是否正常，具體指的是全部、局部、個別用戶或終端訪問情況，不僅包括業務系統是否能訪問，訪問的速度是否快，還包括業務邏輯的驗證功能是否正常。
各層職責
基礎設施
- 狀態監控：包括機房供電、空調、網絡設備的軟硬件狀態，如設備狀態等；
- 性能監控：包括設備的性能情況，比如CPU、內存大小、session數量、端口流量包量、內存溢出監控、內存使用率等；
- 網絡監控：包括設備錯包、丟包率，針對網絡設備以及網絡鏈路的探測延時、丟包率監控等；
- 容量監控：包括設備負載使用率、專線帶寬使用率、出口流量分佈等；
由於基礎設施硬件往往己有設備健康性的檢測機制，建議向這類廠商提要求，將設備的運行事件主動送到監控平臺整合。
服務器層
- 存儲：包括存儲設備，以及設備上的硬盤讀寫錯誤、讀寫超時、硬盤掉線、硬盤介質錯誤；
- 服務器上的內存（內存缺失、內存配置錯誤、內存不可用、內存校驗）、網卡（網卡速率；電源：電源電壓、電源模塊是否失效）、風扇（風扇轉速等）、Raid卡（Raid卡電池狀態、電池老化、電池和緩存是否在位、緩存策略）；
- 虛擬機：vcenter等
- 容器：Docker等
存儲、物理設備、虛擬機等建議參考基礎設施層由廠商主動彙總事件到監控平臺，由於容器方面的監控工具並不多，則需根據實際情況選擇是否借鑑開源的工具進行自研。
系統服務層
系統服務層的數據主要包括操作系統、中間件、數據庫，以及其它開源分佈式中間件等工具，這方面包括很多，以操作系統爲例，包括：CPU（CPU整體使用率、CPU各核使用率、CPU Load負載）、內存（應用內存、整體內存、Swap等）、磁盤IO（讀寫速率、IOPS、平均等待延時、平均服務延時等）、網絡IO（流量、包量、錯包、丟包）、連接（各種狀態的TCP連接數等）、進程端口存活、文件句柄數、進程數、內網探測延時、丟包率等。
在分析系統服務層的數據消費情況時，可以通過分析系統性能情況，客觀衡量業務負載高低情況，並結合擴縮容調度，實現業務的負載和成本間的平衡。可以根據服務器所在業務層級（接入層、邏輯層還是數據層）的不同，設置不同的容量參考指標、指標參考基準、指標計算規則、高低負載判別規則，設置業務模塊（由相同功能的多個服務器構成的業務集羣）的擴縮容規則；由系統計算出服務器、業務模塊的負載情況，決策出是否需要擴容或縮容，觸發業務模塊的擴縮容操作。
這一層的工具主要採用引入成熟工具或自研的方式，可選的空間比較大，只要覆蓋面夠廣、支持靈活的二次定製開發，應該問題都不大，建設過程中，我認爲中間件與數據庫兩塊是值得讓DBA、中間件管理員深度挖掘監控指標覆蓋面。
另外，在互聯網分佈式架構的推動下，傳統企業也逐步使用一些分佈式中間件，比如分佈式數據庫中間件，內存數據庫、消息隊列等。由於對於這類開源中間件，傳統企業在技術上弱於互聯網企業，且監控工具並不多，需要重點投入資源進行相關監控指標的開發。
應用服務層
- 服務可用性監控：如服務、端口是否存在，是否假死等；
- 應用營業狀態監控：指應用的狀態是否滿足業務開業狀態；
- 應用性能：應用處理能力，比如交易量、成功率、失敗率、響應率、耗時；
- 應用交易：比如交易主動埋點、交易流水、ESB等；
應用服務層監控可擴展的面與深入的度都有很大空間，以下是部分應用監控點：
客戶體驗層
比如測速系統以及模擬用戶訪問的方式：
以模擬用戶訪問爲例，通過模擬用戶訪問業務並校驗返回數據結果，監測業務是否可用、訪問質量及性能、邏輯功能正確性的監控系統。不僅僅是接入層（網站類業務是否能訪問，訪問的速度是否快），業務邏輯的驗證就涉及到登錄鑑權、關係數據自動化獲取等。
監控整合
監控的分層方式促進了每一個專業層的監控覆蓋面與深度，防止建設失控，但也帶來一個管理上的副作用，所以需要在事件、可視化、子系統、數據的整合，以減少管理成本。
在監控整合上，主要從事件彙總、統一可視化、監控數據彙總三方面進行梳理。
事件彙總
Google SRE解密一書中提過（大體意思如下）：監控應該儘可能簡單地把需要人介入或關注的信息展示給運維團隊，能通過自動化自愈解決、分析定位過程則不在一級視圖提供。當前，能實現自愈的企業還比較少，或還在摸索建設過程中，所以我先講講如何讓每天產生上億條流水，觸發上萬次告警條件（同一告警如未解除會持續不斷觸發告警條件），來自各種不同工具、不同格式的的告警事件以儘可能簡單的方式展示給一線監控團隊。
第一部分監控分層中提到，原有的監控工具以保留爲主思路，這些工具在運營過程中每天都會產生大量事件，爲了實現監控集中展示，集中管理，需要建設一個事件彙總的模塊實現事件統一彙總，並對不同層面、不同專業角度的事件進行收斂，關聯分析，更全面的感知系統運行狀況。
可能上面講得還不夠清楚，舉幾個例子：
- Example01：從可視化角度看，不同的工具有不同的監控事件展示界面，多個運維視圖增加了運維技能要求，需要更多的人力去管理生產；
- Example02：缺少對各類事件進行彙總與數據分析，無法反映生產系統整體的運行狀況，如能將這些事件數據彙總起來，比如物理層的拓撲，則可以直觀地管控應用狀況；
- Example03：同一個生產問題往往會帶來多個維度的生產運行問題，比如一臺物理機宕機，在這臺物理機上的虛擬機都會出現網絡、操作系統層面可用性、應用可用性、交易級狀況、應用性能、客戶體驗的告警，如果監控指標足夠豐富往往會有上百條以上，不能準確、快速定位問題根源。
- Example04：每天能觸發閥值的告警很多，以經驗的方式很難讓一線監控團隊無時無刻能準確的定位哪些是高優先級的告警，比如磁盤空間到了70%的確需要有人去關注，評估是否進行數據清理、擴容，但這類告警屬於低優先級的事件。
- 從上面4個例子可以看到，事件彙總模塊需要有幾個基本要求：
- 事件彙總：彙總不同層次、不同專業條線、不同類型事件是監控集中管理的基礎。
- 事件收斂：前面提到同一個故障會觸發多類指標的告警，同一個指標在故障未解除前也會重複產生大量的告警事件，如果將全部事件都展示出來，那對於監控處理人員將是災難性的，所以需要進行事件收斂。
- 事件分級：對於不同的事件需要有適當層次的事件分級，事件升級的策略。事件分級是將事件當前緊急程度進行標識顯示，事件升級是對於低級的事件當達到一定的程度，比如處理時間過長，則需要進行升級。
- 事件分析：事件分析是建立事件的關聯關係，關聯分析可以從縱向和橫向關係進行分析，縱向是指從底層的基礎設施、網絡、服務器硬件、虛擬機/容器、操作系統、中間件、應用域、應用、交易；橫向是指從當前的應用節點、上游服務器節點、下游服務器節點的交易關係。事件分析是形成故障樹，自愈的基礎。
- 對於事件分析重點在於關係模型的建立，互聯網公司有不少標準化的方案，但我個人認爲需要開發團隊介入改造的標準化不可控，所以另外一方向是針對企業內部特點，以CMDB、應用配置庫爲中心，或以節點型的系統爲中心去建立關係模型，具體介紹見後面第三部分。
- 高性能：爲了實現實時監控，需要事件彙總模塊具備高性能。
- 對外提供採集事件數據接口：監控作爲一體化運維體系的一部份，需要對外提供服務化接口，支持事件數據的採集。
統一可視化
不同監控工具有着不同界面，不同的操作方法，對工具的掌握程度依賴於運維人員的經驗，監控管理很難形成標準化，不利於監控的集中管理、釋放人力成本。所以，監控事件彙總後，需要有一個統一的可視化，支持統一展示、多類型展示形式、多維用戶視角、支持按需訂閱的特點。具體包括：
支持事件的統一展示：支持不同角色用戶管理不同的事件，包括事件的受理、分派、督辦、升級、解除、轉工單等閉環操作，無需在不同工具上多次操作。
多類型的展現形式：PC電腦的web端，移動手持端，大屏展示，爲了支持可視化的快速開發，以及低成本的過渡到移動手持端，建議採用H5的技術選型。
多維用戶：根據不同機構、不同用戶的關注點，比如一線運維主要關注實時告警，二線運維主要關注事件豐富與故障樹等輔助定位，值班經理主要關注當天監控事件處理情況，團隊管理者主要關注團隊內監控事件與重要業務系統運行狀況，主管經理主要關注整合的運行情況與人員處理情況，開發人員需要有協助處理的視角數據等。
支持用戶訂閱展示：針對不同的業務運營場景、不同的用戶進行佈局、推送數據、監控指標的訂閱式展示，比如，雙十一或秒殺的運營活動，需要關注幾十個OS的資源情況，各個OS上的交易、性能情況，如果每一個指標一個窗口，需要看幾十個窗口；如果只看告警信息，又無法觀察到趨勢；所以，需要支持多指標合併在一個視圖頁面的訂閱功能。
數據整合標準
關於數據整合，這裏不再複述不同監控工具事件數據的整合，主要從報文、日誌、數據庫流水幾個角度分析：
1）報文解釋
報文解釋標準，以天旦BPC爲例做個介紹：
市場上有很多APM，大體可以分爲主動模擬撥測、頁面插入代碼監測、客戶端插件採集、服務端代理收集、服務端旁路報文監聽。天旦的BPC採用服務端的網絡層旁路抓取一份報文，通過預先定義好的解碼策略，解出了一份數據格式良好的數據源。在這份數據源之上可以進行監控、運維數據分析等運維場景的使用。由於BPC報文解碼配置設計比較簡單，支持秒級（預計17年將有毫秒級的產品出來），且對應用服務性能無影響，用旁路報文解釋的方式作爲數據輸入標準成爲一種值得推薦的方式。
2）日誌結構標準
日誌結構標準，主要分兩類，一類是直接建一個日誌分析平臺，比如國外的Splunk，或者開源的ELK等；另一類是重構日誌標準組件，比如重構Java企業應用中經常使用的log4j開源包的標準輸出方法，對日誌結構進行整合，並通過異步消息的方式將日誌發送給監控平臺，再提供可視化的IDE對不同系統的日格式進行進一步整理，將需要的數據抽取整合。
3）數據庫流水標準
在監控數據庫流水中，也分兩類，一類是建立標準的運維流水錶，監控直接讀取這些流水進行監控或分析；另一類參考重構log4j的思路，對jdbc的包進行重構，將數據庫執行語句，以及語句執行過程中的開始時間、結構時間、返回狀態進行記錄。第一類我們用得比較多，當前的交易級的監控主要採用這種方式進行，第二類目前仍處於思路階段。
4）其它思路
其實針對日誌LOG4J、數據庫JDBC這兩種方式從思路看都是從節點類的模塊進行，往同類擴展，可以針對標準應用中間件、WEB等模塊進行處理；往大的擴展，則比如企業ESB類的應用系統可以作用標準的數據整合。這些節點類的模塊進行數據整合標準往往可以有事半功倍的作用。
監控指標
如前一部分提到，監控有賴於運維各專業條線協同完善，通過將監控體系進行分層、分類，各專業條線再去有重點的豐富監控指標。
指標分類
1）基礎設施層
環境動力：暖通系統（如空調、新風系統、機房環境、漏水等）、電力系統（如配電櫃、UPS、ATS等）、安防系統（如防雷、消防、門禁等）等
網絡設備：路由器、二三層網絡交換機、多層交換機、負載均衡設備等
安全設備：防火牆、入侵檢測、防病毒、加密機等
2）服務器層
虛擬化：虛擬網絡資源、虛擬主機、虛擬存儲資源等
存儲設備：磁盤陣列、虛擬帶庫、物理磁帶庫、SAN、NAS等
服務器：大中小型機、X86服務器
3）系統軟件層
操作系統：AIX、LINUX、WINDOWS等
數據庫：ORACLE、DB2、SQL SERVER、MYSQL等
中間件：WEBSPHERE、WEBLOGIC、MQ、IHS、TOMCAT、AD、REDIS等
其它系統軟件：備份軟件
4）應用服務層
服務可用性：服務狀態、日誌刷新、端口監聽、網絡連通性等
應用交易：交易整體情況、應用性能（重要交易或整個節點的交易量、耗時、成功率、響應率）、開業情況、批量交易狀態等
5）客戶體驗層
客戶訪問速度：
頁面響應時間、撥測登錄、普通頁面渲染時間、重要接口響應時間等
具體的監控指標內容與閥值參考的明細不同的行業，不同的系統會有不同的認識，這裏不細列。
指標權重與閥值分級
在分解具體指標前，需要重點強調一下監控指標的指標權重、閥值分級與上升機制問題，做監控的人知道“監”的最重要目標是不漏報，爲了不漏報在實際實施過程中會出現監控告警過多的困難。如何讓運維人員在不漏處理監控事件，又能快速解決風險最高的事件？則需要監控的指標需要進行指標權重、閥值分級與上升機制：
1）指標權重監控指標的權重是爲了定義此項監控指標是否爲必須配置，比如應用軟件服務、端口監聽是一個應用可用性的重要指標，權重定義爲一級指標；對於批量狀態，則由於不少應用系統並沒有批量狀態，則定義爲二級指標。通常來說一級指標將作爲監控覆蓋面的底線，通過設置好權重，一是爲了讓運維人員知道哪些監控指標必須確保覆蓋，同時加以引入KPI考覈；二是爲了讓監控平臺建設人員有側重的優化，實現一級指標的自動配置，無需運維人員手工配置。
2）閥值分級與上升機制有監控指標，就需要針對監控指標定義閥值，監控閥值的設立需要有分級機制，以分通知、預警、告警三級爲例：通知需要運維人員關注，比如“交易系統登錄數2000，登錄成功率95%，平時登錄數基線500，登錄成功率96%”，由於登錄成功率並未明顯下降，可能是由於業務作了業務推廣，運維人員只需關注當前應用運行狀態再做判斷；預警代表監控事件需要運維人員處理，但重要性略低，比如“CPU使用率71%，增長趨勢非突增”，管理員受理到這個預警可以先設置爲一個維護期，待當天找個時間集中處理；告警則必須馬上處理的事件，比如“交易成功率爲10%，平時爲90%”這類監控事件己反映出交易運行問題。
對於升級，是指一個預警當長時間未處理時，需要有一個上升機制，轉化爲告警，以督辦運維人員完成監控事件的處理。
閥值的分級需通過流程管理加以落實。
3）指標基線
當前運行狀況是否正常需要用運行情況與閥值作比較，但實際實施過程中會發現一個固定的閥值會導致不少監控誤報，比如業務運營大促與非運營活動日、非工作日與工作日、白天與晚上的運行值都會有不小的差異，所以需要建立一個動態的指標基線，當前運行值與動態基線的偏離度大小來判斷是否爲監控事件。指標基線的建設過程中有幾個方面需要關注：
- 基線的自我學習前面己提到指標的基線是動態的，基線動態就需要對系統運行的情況按一個指定的時間間隔粒度進行學習，理論上運行學習的時間越長，基線越準確（但如果業務做了推廣，歷史的基線數據則需要降低權重）。
- 基線指標的組合有些情況判斷一個監控指標是否是事件，需要將多個指標放在一起看才能判斷。比如WINDOWS集羣下的SQL SERVER進程內存長期都佔95%以上，如果將內存作爲基線畫線，就會是一條高負載的線，所以可以考慮將CPU、內存兩個指標合併作爲一個基線指標。
- 另外，還可以用不同時間段與指標組合的方式，比如按節假日與非節假日、按星期幾、按白天與晚上設計不同的基線。
- 性能基線是由指定時間段的大量歷史數據不斷迭加組合，間隔的時間越短需要的性能越高，尤其是當基線的組合類型豐富的情況下，需要大量的計算資源，選用一個合理的計算方案就顯得很重要。我們原來採用單庫跑基線，只能做到30分鐘一個點，目前採用分佈式數據庫結合緩存方式設計性能，未來根據基線運行的情況再考慮是否選用大數據流計算等技術框架。
- 基線的人工調整系統運行過程中難免會因爲業務運營推廣等導致歷史基線不能反映指標是否合理，這時候需要有一個人工調整基線的入口，運維人員可以重新繪製基線、減少對歷史數據的參考權重等。
另外，人工智能這麼火，也提一點通過機器學習來實現監控基線的思路（思路還不成熟，僅供參考）：
將應用運行健康與不健康的樣本數據彙總，樣本中不同指標的指標數據作爲不同的變量，結合不同的算法，通過調參學習後，得到運行狀態好壞的基線。這樣，就可以將基線做一個監控運行狀態的服務，把實際運行的多個監控指標數據關給基線服務，基線服務返回當前服務運行好壞。
監控事件
監控事件
監控事件反映的是IT基礎設施、中間件、應用程序、業務流程等運行過程中發生的問題。監控系統通過採集運行數據，通過數據判斷規則生成事件，監控事件還涉及事件的處理（比如事件豐富、收斂等）、事件的關聯分析，並驅動事件的解決。
前面提到了事件整合，下面主要講講事件關聯、事件應急、事件分析、智能處理方面的建設思路。
事件標準
事件數據模型
事件數據主要包含數據頭信息、靜態豐富信息、事件現場信息、知識庫信息、關聯信息。
靜態豐富信息：包含描述豐富信息、拓撲豐富信息，描述豐富信息主要包含相關人員描述信息、服務器描述信息、工單信息等，這塊豐富數據可以通過CMDB消費獲取，這部份豐富數據有助於事件處理過程中關聯分析。
事件現場信息：包含指標信息、性能信息、系統資源信息等，這部份信息主要是反映事件的現場數據。
知識庫信息：主要指相似歷史事件及其處理方式等信息，比如“建議如何做，己自動進行了什麼動作”等。關聯信息主要包含從屬事件信息、關聯影響信息。
事件分級標準
前面提到了事件分級的問題，分級是將事件當前緊急程度進行標識顯示，事件升級是對於低級的事件當達到一定的程度，比如處理時間過長，則需要進行升級。我們將監控事件等級事件級別分爲通知、預警、故障三種：
- 通知：指一般的通知信息類事件。
- 預警：指已經出現異常，即將要引起生產故障的事件。
- 故障：指已經發生問題，並且已經影響到生產流程的事件，如果需要進一步細化故障級別，可以分爲一般故障和緊急故障：一般故障不需要緊急處理的故障，緊急故障需要管理員緊急處理的故障。
事件細分的粒度需根據各企業團隊的管理要求而定。
2、事件關聯
1）事件壓縮及收斂
事件壓縮及收斂就是爲了減少事件數量，提高事件定位能力。
監控採集數據後，根據具體的單指標或多指標的規則判斷是否觸發事件，如觸發事件，則發送事件接收器。爲什麼不直接通過可視化方式馬上將匹配到的事件信息呈現給監控人員呢？那是由於監控數據採集是實時採集，但事件的解決可能並非馬上解決，爲了減少重複性的告警數量，需要由事件處理引擎進一步壓縮處理。比如每2分鐘採集一次文件系統容器數據，當某個文件系統容量超過70%後，觸發了預警閥值，但這個文件系統是緩慢增長，計劃在當週的擴容窗口集中變更，如果不對事件進行處理，那每2分鐘就會有一個預警，產生預警氾濫，所以這時需要對事件進行壓縮，比如針對事件來源、關鍵字組合等規則進行壓縮，並記錄事件發生次數。
有了事件壓縮還不夠，因爲觸發事件的指標往往是相互關聯的，這就需要對多項指標關係進行分析，減少相同問題產生的事件。比如這個應用場景：
NAS監控：NAS文件系統在各OS上都會有監控，一個NAS文件系統出問題時，每個服務器的NAS文件系統監控都會報警。如能對NAS進行掛載關係梳理，同一NAS的報警可以大量收斂。
進程、端口、通訊檢測：一個進程宕掉時，該進程啓動的端口、關聯繫統與該進程端口的通訊等都會同時報警。如能對進程、端口、通訊關係進行梳理，同一個進程引發的進程、端口、通訊監控事件也能收斂明顯。
2）事件豐富
事件豐富包括事件描述豐富（通過CMDB豐富、拓撲豐富）、事件現場豐富（指標信息豐富、APM信息豐富、系統資源信息豐富）、知識庫豐富，提高運維人員分析問題的能力。
事件主要豐富方法如下：
- 與第三方監控系統對接，獲取事件相關信息進行豐富。如與CMDB系統對接，獲取服務器等相關配置信息進行CMDB數據豐富；
- 根據拓撲關係模型，進行拓撲豐富；
- 指標信息豐富：獲取事件發生前後一段時間內的相關指標信息數據（如CPU/內存等），進行指標信息豐富；
- 相關事件豐富：根據拓撲關係模型、應用關係關聯模型、交易流行關聯模型將相近事件時間範圍內的事件進行豐富展示；
- 知識庫豐富：建立事件處理方案知識庫，記錄事件處理的方法和流程，爲事件處理人提供參考依據，以及爲後續自動化運維提供理論支撐。
下面這個是我們做的一個事件豐富，主要包括幾塊內容：
- 事件涉及的軟硬件的基本配置信息、人員信息，這一塊是基本CMDB的數據消費；
- 事件報警的主體信息，包括時間、事件描述、事件可能原因、事件處理情況等；
- 事件應急處理及流程工單鏈接；
- 事件主體信息的具體指標數據展示，以及指標變化趨勢；
- 最近30分鐘的事件情況，以備分析是否受其它事件關聯影響；
- 該事件所在OS的CPU、內存、IO的信息；
- 事件涉及的性能信息，比如交易量、成功率、交易耗時；
- 事件處理進展。
3）事件擴散
事件發生之後，監控系統需要能自動分析事件的關聯信息，幫助運維人員儘可能的還原事件現場，提高分析問題的能力，關聯信息主要有縱向和橫向的關係，其中縱向的關聯是把基礎設施、網絡、系統、應用域、應用、交易關聯起來，任何一個環節出問題，向上計算出波及範圍和受影響系統；橫向的關聯是以交易爲中心，計算上下游的交易節點。下面分別是兩個關聯：
縱向關係：
橫向關係：
4）事件觸發
系統在設置報警策略時，可針對指標進行觸發條件設置，觸發條件按照類型分爲閾值觸發、基線觸發、智能預測。系統根據不同的觸發類型設置，採用的判斷方式也不一樣。具體明細如下：
1、閾值觸發
系統支持指標的閾值觸發設置，當指標值達到設置的閾值時即可進行報警。
閾值的設置範圍只能在該指標的數值範圍內進行設置。
閾值在設置時需要指定數值單位，防止數值因單位不同出現判斷錯誤。
在設置閾值時系統支持實時查看指標當日折現圖和歷史基線，幫助運維人員正確判斷閾值的設置範圍。
2、基線觸發
系統支持指標的基線觸發設置，當指標值達到設置的基線時即可進行報警。
基線設置可按照昨日基線、月基線、周基線進行設置。
系統支持在選定的基線基礎上進行上浮或下沉幅度的設置。
在設置基線時系統支持實時查看指標當日折現圖和歷史基線，幫助運維人員正確判斷基線的設置範圍。
系統支持按照平均基線進行設置。
基線設置時需要有一定的歷史數據作爲依據。
3、智能預測
智能預測主要是通過歷史數據的分析，通過人工智能算法預測未來可能出現的問題，這一塊是未來監控事件優化的一個方向。
3、事件應急
1）應急恢復
運維最基本的指標就是系統可用性，應急恢復的時效性是系統可用性的關鍵指標。通常來講應急恢復的方法有不少，比如：
- 服務整體性能下降或異常，可以考慮重啓服務；
- 應用做過變更，可以考慮是否需要回切變更；
- 資源不足，可以考慮應急擴容；
- 應用性能問題，可以考慮調整應用參數、日誌參數；
- 數據庫繁忙，可以考慮通過數據庫快照分析，優化SQL；
- 應用功能設計有誤，可以考慮緊急關閉功能菜單；
- 還有很多……
監控系統的事件豐富過程中需要儘可能關聯上述的一些應急手段，供運維人員快速應急，比如服務啓停工具、切換工具、程序回切工作等
2）現場保護**
故障處理中，理論上應該在應急前進行現場保護以備問題原因排查的跟進。現場信息主要包含進程內部狀態信息、日誌信息。實際應用過程中可以結合工具進行現場保護，仍以服務啓停工具爲例，支持獲取進程線程鏡像信息、進程內存鏡像信息及GC日誌信息。
3）問題排查
是否爲偶發性、是否可重現
故障現象是否可以重現，對於快速解決問題很重要，能重現說明總會有辦法或工具幫助我們定位到問題原因，而且能重現的故障往往可能是服務異常、變更等工作導致的問題。
但，如果故障是偶發性的，是有極小概率出現的，則比較難排查，這依賴於系統是否有足夠的故障期間的現場信息來決定是否可以定位到總是原因。
是否進行過相關變更
大部份故障是由於變更導致，確定故障現象後，如果有應的變更，有助於從變更角度出現分析是否是變更引起，進而快速定位故障並準備好回切等應急方案。
是否可縮小範圍
一方面應用系統提倡解耦，一支交易會流經不同的應用系統及模塊；另一方面，故障可能由於應用、系統軟件、硬件、網絡等環節的問題。在排查故障原因時應該避免全面性的排查，建議先把問題範圍縮小到一定程序後再開始協調關聯團隊排查。
關聯方配合分析問題
與第3小點結合避免各關聯團隊同時無頭緒的排查的同時，對於牽頭方在縮小範圍後需要開放的態度去請求關聯方配合定位，而對於關聯方則需要有積極配合的工作態度。
是否有足夠的日誌
定位故障原因，最常用的方法就是分析應用日誌，對運維人員不僅需要知道業務功能對應哪個服務進程，還要知道這個服務進程對應的哪些應用日誌，並具備一些簡單的應用日誌異常錯誤的判斷能力。
是否有core或dump等文件
故障期間的系統現場很重要，這個在故障應急前建議在有條件的情況下留下系統現場的文件，比如COREDUMP，或TRACE採集信息等，備份好一些可能被覆蓋的日誌等。
4）應急文檔
故障的表現雖然形式很多，但實際的故障處理過程中，應急措施往往重複使用幾個常用的步驟，所以應急文檔首先要針對這些常用的場景，過於追求影響應用系統方方面面的內容，會導致這個方案可讀性變差，最終變更一個應付檢查的文檔。以下是我覺得應用系統應急方案應該有的內容：
系統級能知道當前應用系統在整個交易中的角色，當前系統出現問題或上下游出現問題時，可以知道如何配合上下游分析問題，比如：上下游系統如何通訊，通訊是否有唯一的關鍵字等。另外，系統級裏還涉及一些基本應急操作，比如擴容、系統及網絡參數調整等。
服務級能知道這個服務影響什麼業務，服務涉及的日誌、程序、配置文件在哪裏，如何檢查服務是否正常，如何重啓服務，如何調整應用級參數等。
交易級能知道如何查到某支或某類交易出現了問題，是大面積、局部，還是偶發性問題，能用數據說明交易影響的情況，能定位到交易報錯的信息。這裏最常用的方法就是數據庫查詢或工具的使用。知道最重要的交易如何檢查是否正常，重要的定時任務的應急處理方案，比如開業、換日、對賬的時間要求及應急措施。
溝通方案溝通方案涉及通訊錄，包括上下游系統、第三方單位、業務部門等渠道。
另外，有了應急方案，如何讓運維人員持續去更新是難點。我認爲要解決這個難點，需要先讓運維人員經常使用這個手冊。如果一個手冊沒有場景可以用，那就需要管理者爲運維人員創造機會去使用這個手冊，比如應急演練。
持續優化
1、整體思路
監控系統建設目標是完善“監”能力，增加“控”的能力，這章提到的持續優化主要是針對“監”能力的落實，歸納起來就是“不漏報，少誤報”，可以針對不同的階段量化目標，比如60%告警即故障，80%故障來自監控。
2、措施
1）目標分解
不漏報
漏報可以從兩個層面看，一個是監控工具不具備某一方面的監控能力；一個是監控工具具備監控能力，但因爲使用者使用問題導致未覆蓋監控。前者需要完善監控能力，比如針對生產故障舉一反三式的優化，或由不同專業條線主動增加監控能力，後者則需要考慮幾個問題：
管理上有沒有要求指標的100%覆蓋率；
覆蓋率的要求是否確實可以落地，或功能上是否設計極不友好；
100%的覆蓋率是否從技術默認設置，如果技術無法默認設置，能否從技術上主動發現；
前面兩個問題需要從管理手段上解決，最後一個問題需要在監控系統中解決，即儘可能讓需要覆蓋的監控指標從技術上落地，減少對運維人員主動性上的依靠，同時監控系統要快速從技術上響應新的監控指標的落地。
減少誤報
誤報帶來的問題也很大，大量、反覆的誤報告警會讓運維人員麻木，進而忽視監控報警，錯過了真正的監控事件的處理，所以監控誤報情況也需要重視。
2）心得
以下是在監控優化上的一些措施心得供參考：
第一階段：減少監控報警數量
目標：每週報警總量上下降60%
主要工作：
抓突出的報警指標，調整閥值，比如CPU、內存、空間、應用性能這幾塊大頭，如果閥值不合理將帶來大量告警，對這幾類指標閥值做優化會有事半功倍的效果；
抓每個指標突出的組、系統進行鍼對性整改，可能就是某個團隊或某些管理員不重視監控，解決刺頭的成效也很明顯；
針對重複性的告警，優化監控系統，減少重複報警。
第二階段：減少監控誤報率
目標：60%告警即故障（排除磁盤、表空間類）
主要工作：
區分監控級別，告警即故障：分析確認哪類監控報警必須作爲事件處理，並將交易量監控設置爲告警，非故障調整爲預警；
所有預警即關聯工單，對預警工單閥值進行分析調整；
優化監控短信內容，提高短信對事件定位；
完成動態基線的監控功能上線功能，提高監控準確率；
完成應用部署與監控維護期關聯，減少未設置維護期導致的監控報警；
完成應用啓停集中處理，減少應用啓停帶來的維護期報警。
第三階段：提高監控對故障的覆蓋率
目標：80%故障來自監控
主要工作：
每週分析生產事件的發現環節，對於非監控發現的故障進行專項分析；
其它方案（針對第一、二階段實施情況完善）
第四階段：提高監控事件處理效率
目標：監控告警1小時內關閉
主要工作：
對監控報警耗時進行分析，並通報
針對無法快速恢復的監控報警優化功能處理
其它方案（待定）
3、團隊
因爲有持續優化的工作，所以最好能夠有一個橫向的監控優化團隊，區分於監控系統工具建設團隊，作爲監控的使用角色，這個團隊有幾個目標：將持續優化的工作進行落地；作好數據分析，比如監控的事件量是否突增，某些系統的事件是否陡增，誤報量是否過多，故障哪些不是通過監控發現，未通過監控發現的故障是否完成監控覆蓋面整改，監控功能有哪些不友好等等。
總結：監控體系的建立是一個長期的過程，需要不斷的優化，以上幾個維度是可以作爲建立監控體系的時候參考方向；