近年來，隨著計算機技術的飛速發展，以及行業資訊的共享,傳統企業的運維己不再是固步自封，日新月異的計算技術的發展推動企業雲平臺的建設，雲平臺的計算能力為大資料分析提供了基礎、雲平臺與大資料分析又將推動運維人工智慧的發展。放眼雲、大資料、人工智慧的運維發展方向的同時，作為運維的生命線，安全生產保障的生命線仍需強調。作為傳統企業的安全生產保障，主要以“監”、“管”、“控”為核心，其中“監”則主要指的的監控。

一、監控體系分層

1、概述：

傳統企業的運維經過多年的積累，往往己沉澱下來不少監控工具，有不同專業條的工具，如基礎設施、硬體、軟體、安全等；也有不同型別的工具，如基於日誌、資料庫、中介軟體、作業系統、網路報文等。對於這些工具，我們採用以下方式處理：

1）建立集中監控平臺，在一體化運維體系中，監控平臺貫穿所有環節，它起到了生產系統涉及的軟硬體環境實時執行狀況的“監”，監控平臺事件驅動的特性也為一體化運維體系起到神經網路驅動的作用，進而進行了“控”，另外，監控平臺優質的運維資料可以作為運維大資料分析的資料來源，實現運維資料採集的角色。為了提高投入效率，減少重複投入，需要建立集中監控平臺實現統一展示、統一管理，支援兩地三中心建設，具備靈活的擴充套件性，支援運維大資料分析；

2）原有的監控工具保留為主：當前並沒有哪一個監控工具可以覆蓋所有生產系統的執行指標，己沉澱下來的監控工具往往是當前生產系統深度定製的工具，俱有存在價值。另外，雖然監控平臺從WEB、APP、到DB均採用了多中心雙活分散式架構部署，但為保證監控覆蓋能力，部份重要的環節仍建議不僅限一套監控工具。

3）各專業條線對各條線的監控負責：各專業條線是最清楚自己需要什麼監控的團隊，各專業條線對監控覆蓋率負責，監控平臺的建設方負責平臺體系的建設，提供基礎技術支撐。

4）工具間整合：不同的專業條線、不同的分析技術可以有不同的監控工具，採用這種多點開花的建設方式更有助於監控面與深度的完善，所有的工具最終需要進行標準化的整合。

基於上面4個處理思路，為防止監控建設失控，減少重複建設、明確主要的建設目標，我們需要對監控工具進行體系化管理，體系化管理首先要做的就是進行監控體系分層。

2、分層方式：

相信每家企業對於監控分層體系都會有各自的劃分方式，以下是以專業條線方式分層：

 1）基礎設施層：包括運營商專線、機房（機房內的設施，比如製冷、安防等）、網路裝置，基礎設施層的監控分為狀態、效能、質量、容量、架構、流量分析等幾個層面。

2）系統伺服器層：包括系統伺服器、儲存等伺服器的可用性狀態。

3）系統及網路服務層：系統及網路服務層主要是指作業系統、系統軟體、網路軟體的使用情況。

4）應用服務層：應用服務層主要是針對應用服務可用性、應用營業狀態、應用效能、應用交易量分析幾方面。

5）客戶體驗層：客戶體驗層包括兩塊，一是客戶訪問速度；二是功能是否正常，具體指的是全部、區域性、個別使用者或終端訪問情況，不僅包括業務系統是否能訪問，訪問的速度是否快，還包括業務邏輯的驗證功能是否正常。

3、各層職責

1）基礎設施

• 狀態監控包括機房供電、空調、網路裝置的軟硬體狀態，如裝置狀態等
• 效能監控包括裝置的效能情況，比如CPU、記憶體大小、session數量、埠流量包量、記憶體溢位監控、記憶體使用率等；
• 網路監控包括裝置錯包、丟包率，針對網路裝置以及網路鏈路的探測延時、丟包率監控等；
• 容量監控包括裝置負載使用率、專線頻寬使用率、出口流量分佈等；

由於基礎設施硬體往往己有裝置健康性的檢測機制，建議向這類廠商提要求，將裝置的執行事件主動送到監控平臺整合。

2）伺服器層

•  儲存：包括儲存裝置，以及裝置上的硬碟讀寫錯誤、讀寫超時、硬碟掉線、硬碟介質錯誤；
• 伺服器上的記憶體（記憶體缺失、記憶體配置錯誤、記憶體不可用、記憶體校驗）、網絡卡（網絡卡速率；電源：電源電壓、電源模組是否失效）、風扇（風扇轉速等）、Raid卡（Raid卡電池狀態、電池老化、電池和快取是否在位、快取策略）
• 虛擬機器：vcenter等
• 容器：docker等

儲存、物理裝置、虛擬機器等建議參考基礎設施層由廠商主動彙總事件到監控平臺，由於容器方面的監控工具並不多，則需根據實際情況選擇是否借鑑開源的工具進行自研。

3）系統服務層：

系統服務層的資料主要包括作業系統、中介軟體、資料庫，以及其它開源分散式中介軟體等工具，這方面包括很多，以作業系統為例，包括：CPU（CPU整體使用率、CPU各核使用率、CPU Load負載）、記憶體（應用記憶體、整體記憶體、Swap等）、磁碟IO（讀寫速率、IOPS、平均等待延時、平均服務延時等）、網路IO（流量、包量、錯包、丟包）、連線（各種狀態的TCP連線數等）、程序埠存活、檔案控制代碼數、程序數、內網探測延時、丟包率等。

在分析系統服務層的資料消費情況時，可以通過分析系統性能情況，客觀衡量業務負載高低情況，並結合擴縮容排程，實現業務的負載和成本間的平衡。可以根據伺服器所在業務層級（接入層、邏輯層還是資料層）的不同，設定不同的容量參考指標、指標參考基準、指標計算規則、高低負載判別規則，設定業務模組（由相同功能的多個伺服器構成的業務叢集）的擴縮容規則；由系統計算出伺服器、業務模組的負載情況，決策出是否需要擴容或縮容，觸發業務模組的擴縮容操作。

這一層的工具主要採用引入成熟工具或自研的方式，可選的空間比較大，只要覆蓋面夠廣、支援靈活的二次定製開發，應該問題都不大，建設過程中，我認為中介軟體與資料庫兩塊是值得讓DBA、中介軟體管理員深度挖掘監控指標覆蓋面。

另外，在網際網路分散式架構的推動下，傳統企業也逐步使用一些分散式中介軟體，比如分散式資料庫中介軟體，記憶體資料庫、訊息佇列等。由於對於這類開源中介軟體，傳統企業在技術上弱於網際網路企業，且監控工具並不多，需要重點投入資源進行相關監控指標的開發。

4）應用服務層

• 服務可用性監控：如服務、埠是否存在，是否假死等
• 應用營業狀態監控：指應用的狀態是否滿足業務開業狀態
• 應用效能：應用處理能力，比如交易量、成功率、失敗率、響應率、耗時
• 應用交易：比如交易主動埋點、交易流水、ESB等

應用服務層監控可擴充套件的面與深入的度都有很大空間，具體介紹參見公眾號另一篇梳理《應用可用性監控建設階段小結》，以下是一部份應用監控點：

5）客戶體驗層

比如測速系統以及模擬使用者訪問的方式：
以模擬使用者訪問為例，通過模擬使用者訪問業務並校驗返回資料結果，監測業務是否可用、訪問質量及效能、邏輯功能正確性的監控系統。不僅僅是接入層(網站類業務是否能訪問，訪問的速度是否快)，業務邏輯的驗證就涉及到登入鑑權、關係資料自動化獲取等。

二、監控整合

監控的分層的方式促進了每一個專業層的監控覆蓋面與深度，防止建設失控，但也帶來一個管理上的副作用，所以需要在事件、視覺化、子系統、資料的整合，以減少管理成本。

在監控整合上，主要從事件彙總、統一視覺化、監控資料彙總3方面進行梳理。

1、事件彙總

google sre解密一書中提過（大體意思如下）：監控應該儘可能簡單的把需要人介入或關注的資訊展示給運維團隊，能通過自動化自愈解決、分析定位過程則不在一級檢視提供。當前，能實現自愈的企業還比較少，或還在摸索建設過程中，所以我先講講如何讓每天產生上億條流水，觸發上萬次告警條件（同一告警如未解除會持續不斷觸發告警條件），來自各種不同工具、不同格式的的告警事件以儘可能簡單的方式展示給一線監控團隊。

第一章監控分層中提到，原有的監控工具以保留為主思路，這些工具在運營過程中每天都會產生大量事件，為了實現監控集中展示，集中管理，需要建設一個事件彙總的模組實現事件統一彙總，並對不同層面、不同專業角度的事件進行收斂，關聯分析，更全面的感知系統執行狀況。

可能上面講得還不夠清楚，舉幾個例子：

• 從視覺化角度看，不同的工具有不同的監控事件展示介面，多個運維檢視增加了運維技能要求，需要更多的人力去管理生產；
• 缺少對各類事件進行彙總與資料分析，無法反映生產系統整體的執行狀況，如能將這些事件資料彙總起來，比如物理層的拓撲，則可以直觀的管控應用狀況；
• 同一個生產問題往往會帶來多個維度的生產執行問題，比如一臺物理機宕機，在這臺物理機上的虛擬機器都會出現網路、作業系統層面可用性、應用可用性、交易級狀況、應用效能、客戶體驗的告警，如果監控指標足夠豐富往往會有上百條以上，不能準確、快速定位問題根源。
• 每天能觸發閥值的告警很多，以經驗的方式很難讓一線監控團隊無時無刻能準確的定位哪些是高優先順序的告警，比如磁碟空間到了70%的確需要有人去關注，評估是否進行資料清理、擴容，但這類告警屬於低優先順序的事件。

從上面4個例子可以看到，事件彙總模組需要有幾個基本要求：

• 事件彙總：彙總不同層次、不同專業條線、不同型別事件是監控集中管理的基礎。
• 事件收斂：前面提到同一個故障會觸發多類指標的告警，同一個指標在故障未解除前也會重複產生大量的告警事件，如果將全部事件都展示出來，那對於監控處理人員將是災難性的，所以需要進行事件收斂（關於收斂的思路可以見公眾號另一篇關於事件收斂的文章）
• 事件分級：對於不同的事件需要有適當層次的事件分級，事件升級的策略。事件分級是將事件當前緊急程度進行標識顯示，事件升級是對於低階的事件當達到一定的程度，比如處理時間過長，則需要進行升級。
• 事件分析：事件分析是建立事件的關聯關係，關聯分析可以從縱向和橫向關係進行分析，縱向是指從底層的基礎設施、網路、伺服器硬體、虛擬機器/容器、作業系統、中介軟體、應用域、應用、交易；橫向是指從當前的應用節點、上游伺服器節點、下游伺服器節點的交易關係。事件分析是形成故障樹，自愈的基礎。對於事件分析重點在於關係模型的建立，網際網路公司有不少標準化的方案，但我個人認為需要開發團隊介入改造的標準化不可控，所以另外一方向是針對企業內部特點，以CMDB、應用配置庫為中心，或以節點型的系統為中心去建立關係模型，具體介紹見第三章。
• 高效能：為了實現實時監控，需要事件彙總模組具備高效能。
• 對外提供採集事件資料介面：監控作為一體化運維體系的一部份，需要對外提供服務化介面，支援事件資料的採集。

2、統一視覺化

不同監控工具有著不同介面，不同的操作方法，對工具的掌握程度依賴於運維人員的經驗，監控管理很難形成標準化，不利於監控的集中管理、釋放人力成本。所以，監控事件彙總後，需要有一個統一的視覺化，支援統一展示、多型別展示形式、多維使用者視角、支援按需訂閱的特點。具體包括：

支援事件的統一展示：支援不同角色使用者管理不同的事件，包括事件的受理、分派、督辦、升級、解除、轉工單等閉環操作，無需在不同工具上多次操作。

多型別的展現形式：PC電腦的web端，移動手持端，大屏展示，為了支援視覺化的快速開發，以及低成本的過渡到移動手持端，建議採用H5的技術選型。

多維使用者：根據不同機構、不同使用者的關注點，比如一線運維主要關注實時告警，二線運維主要關注事件豐富與故障樹等輔助定位，值班經理主要關注當天監控事件處理情況，團隊管理者主要關注團隊內監控事件與重要業務系統執行狀況，主管經理主要關注整合的執行情況與人員處理情況，開發人員需要有協助處理的視角資料等。

支援使用者訂閱展示，針對不同的業務運營場景、不同的使用者進行佈局、推送資料、監控指標的訂閱式展示，比如，雙十一或秒殺的運營活動，需要關注幾十個OS的資源情況，各個OS上的交易、效能情況，如果每一個指標一個視窗，需要看幾十個視窗；如果只看告警資訊，又無法觀察到趨勢；所以，需要支援多指標合併在一個檢視頁面的訂閱功能。

3、資料整合標準

關於資料整合，這裡不再複述不同監控工具事件資料的整合，主要從報文、日誌、資料庫流水幾個角度分析：

1）報文解釋：

報文解釋標準，以天旦BPC為例做個介紹。

市場上有很多APM，大體可以分為主動模擬撥測、頁面插入程式碼監測、客戶端外掛採集、服務端代理收集、服務端旁路報文監聽（詳細的分類可以見公眾號另一篇關於APM的文章）。天旦的BPC採用服務端的網路層旁路抓取一份報文，通過預先定義好的解碼策略，解出了一份資料格式良好的資料來源。在這份資料來源之上可以進行監控、運維資料分析等運維場景的使用。由於BPC報文解碼配置設計比較簡單，支援秒級（預計17年將有毫秒級的產品出來），且對應用服務效能無影響，用旁路報文解釋的方式作為資料輸入標準成為一種值得推薦的方式。

2）日誌結構標準：

日誌結構標準，主要分兩類，一類是直接建一個日誌分析平臺，比如國外的splunk、國內的日誌易，或者開源的ELK（日誌易也是用了ELK）;另一類是重構日誌標準組件，比如重構java企業應用中經常使用的log4j開源包的標準輸出方法，對日誌結構進行整合，並通過非同步訊息的方式將日誌傳送給監控平臺，再提供視覺化的IDE對不同系統的日格式進行進一步整理，將需要的資料抽取整合。

3）資料庫流水標準：

在監控資料庫流水中，也分兩類，一類是建立標準的運維流水錶，監控直接讀取這些流水進行監控或分析；另一類參考重構log4j的思路，對jdbc的包進行重構，將資料庫執行語句，以及語句執行過程中的開始時間、結構時間、返回狀態進行記錄。第一類我們用得比較多，當前的交易級的監控主要採用這種方式進行，第二類目前仍處於思路階段。

4）其它思路：

其實針對日誌LOG4J、資料庫JDBC這兩種方式從思路看都是從節點類的模組進行，往同類擴充套件，可以針對標準應用中介軟體、WEB等模組進行處理；往大的擴充套件，則比如企業ESB類的應用系統可以作用標準的資料整合。這些節點類的模組進行資料整合標準往往可以有事半功倍的作用。

三、監控指標

如前一章提到，監控有賴於運維各專業條線協同完善，通過將監控體系進行分層、分類，各專業條線再去有重點的豐富監控指標。

1、指標分類

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）客戶體驗層：

客戶訪問速度：頁面響應時間、撥測登入、普通頁面渲染時間、重要介面響應時間等

具體的監控指標內容與閥值參考的明細不同的行業，不同的系統會有不同的認識，這裡不細列。

2、指標權重與閥值分級

在分解具體指標前，需要重點強調一下監控指標的指標權重、閥值分級與上升機制問題，做監控的人知道“監”的最重要目標是不漏報，為了不漏報在實際實施過程中會出現監控告警過多的困難。如何讓運維人員在不漏處理監控事件，又能快速解決風險最高的事件，則需要監控的指標需要進行指標權重、閥值分級與上升機制：

1）指標權重：

監控指標的權重是為了定義此項監控指標是否為必須配置，比如應用軟體服務、埠監聽是一個應用可用性的重要指標，權重定義為一級指標；對於批量狀態，則由於不少應用系統並沒有批量狀態，則定義為二級指標。通常來說一級指標將作為監控覆蓋面的底線，通過設定好權重，一是為了讓運維人員知道哪些監控指標必須確保覆蓋，同時加以引入KPI考核；二是為了讓監控平臺建設人員有側重的優化，實現一級指標的自動配置，無需運維人員手工配置。

2）閥值分級與上升機制：

有監控指標，就需要針對監控指標定義閥值，監控閥值的設立需要有分級機制，以分通知、預警、告警三級為例：通知需要運維人員關注，比如“交易系統登入數2000，登入成功率95%，平時登入數基線500，登入成功率96%”，由於登入成功率並未明顯下降，可能是由於業務作了業務推廣，運維人員只需關注當前應用執行狀態再做判斷；預警代表監控事件需要運維人員處理，但重要性略低，比如“CPU使用率71%，增長趨勢非突增”，管理員受理到這個預警可以先設定為一個維護期，待當天找個時間集中處理；告警則必須馬上處理的事件，比如“交易成功率為10%，平時為90%”這類監控事件己反映出交易執行問題。

對於升級，是指一個預警當長時間未處理時，需要有一個上升機制，轉化為告警，以督辦運維人員完成監控事件的處理。

閥值的分級需通過流程管理加以落實。

3、指標基線

當前執行狀況是否正常需要用執行情況與閥值作比較，但實際實施過程中會發現一個固定的閥值會導致不少監控誤報，比如業務運營大促與非運營活動日、非工作日與工作日、白天與晚上的執行值都會有不小的差異，所以需要建立一個動態的指標基線，當前執行值與動態基線的偏離度大小來判斷是否為監控事件。指標基線的建設過程中有幾個方面需要關注：

1）基線的自我學習：

前面己提到指標的基線是動態的，基線動態就需要對系統執行的情況按一個指定的時間間隔粒度進行學習，理論上執行學習的時間越長，基線越準確（但如果業務做了推廣，歷史的基線資料則需要降低權重）。

2）基線指標的組合：

有些情況判斷一個監控指標是否是事件，需要將多個指標放在一起看才能判斷。比如WINDOWS叢集下的SQL SERVER程序記憶體長期都佔95%以上，如果將記憶體作為基線畫線，就會是一條高負載的線，所以可以考慮將CPU、記憶體兩個指標合併作為一個基線指標。

另外，還可以用不同時間段與指標組合的方式，比如按節假日與非節假日、按星期幾、按白天與晚上設計不同的基線。

3）效能：

基線是由指定時間段的大量歷史資料不斷迭加組合，間隔的時間越短需要的效能越高，尤其是當基線的組合型別豐富的情況下，需要大量的計算資源，選用一個合理的計算方案就顯得很重要。我們原來採用單庫跑基線，只能做到30分鐘一個點，目前採用分散式資料庫結合快取方式設計效能，未來根據基線執行的情況再考慮是否選用大資料流計算等技術框架。

4）基線的人工調整：

系統執行過程中難免會因為業務運營推廣等導致歷史基線不能反映指標是否合理，這時候需要有一個人工調整基線的入口，運維人員可以重新繪製基線、減少對歷史資料的參考權重等。

另外，人工智慧這麼火，也提一點通過機器學習來實現監控基線的思路（思路還不成熟，僅供參考）：

將應用執行健康與不健康的樣本資料彙總，樣本中不同指標的指標資料作為不同的變數，結合不同的演算法，通過調參學習後，得到執行狀態好壞的基線。這樣，就可以將基線做一個監控執行狀態的服務，把實際執行的多個監控指標資料關給基線服務，基線服務返回當前服務執行好壞。

四、監控事件

1、監控事件：

監控事件反映的是IT基礎設施、中介軟體、應用程式、業務流程等執行過程中發生的問題。監控系統通過採集執行資料，通過資料判斷規則生成事件，監控事件還涉及事件的處理（比如事件豐富、收斂等）、事件的關聯分析，並驅動事件的解決。（以下是監控事件處理的一般流程圖）

前面提到了事件整合，下面主要講講事件關聯、事件應急、事件分析、智慧處理方面的建設思路。

2、事件標準

1）事件資料模型

事件資料主要包含資料頭資訊、靜態豐富資訊、事件現場資訊、知識庫資訊、關聯資訊。

靜態豐富資訊包含描述豐富資訊、拓撲豐富資訊，描述豐富資訊主要包含相關人員描述資訊、伺服器描述資訊、工單資訊等，這塊豐富資料可以通過CMDB消費獲取，這部份豐富資料有助於事件處理過程中關聯分析。事件現場資訊包含指標資訊、效能資訊、系統資源資訊等，這部份資訊主要是反映事件的現場資料。知識庫資訊主要指相似歷史事件及其處理方式等資訊，比如“建議如何做，己自動進行了什麼動作”等。關聯資訊主要包含從屬事件資訊、關聯影響資訊。

2）事件分級標準

前面提到了事件分級的問題，分級是將事件當前緊急程度進行標識顯示，事件升級是對於低階的事件當達到一定的程度，比如處理時間過長，則需要進行升級。我們將監控事件等級事件級別分為通知、預警、故障三種：

•   通知：指一般的通知資訊類事件。

•   預警：指已經出現異常，即將要引起生產故障的事件。

•   故障：指已經發生問題，並且已經影響到生產流程的事件，如果需要進一步細化故障級別，可以分為一般故障和緊急故障：一般故障不需要緊急處理的故障，緊急故障需要管理員緊急處理的故障。

事件細分的粒度需根據各企業團隊的管理要求而定。

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）事件觸發

系統在設定報警策略時，可針對指標進行觸發條件設定，觸發條件按照型別分為閾值觸發、基線觸發、智慧預測。系統根據不同的觸發型別設定，採用的判斷方式也不一樣。具體明細如下：

•   閾值觸發

系統支援指標的閾值觸發設定，當指標值達到設定的閾值時即可進行報警。

-閾值的設定範圍只能在該指標的數值範圍內進行設定。

– 閾值在設定時需要指定數值單位，防止數值因單位不同出現判斷錯誤。

– 在設定閾值時系統支援實時檢視指標當日折現圖和歷史基線，幫助運維人員正確判斷閾值的設定範圍。

•   基線觸發

系統支援指標的基線觸發設定，當指標值達到設定的基線時即可進行報警。

-基線設定可按照昨日基線、月基線、周基線進行設定。

-系統支援在選定的基線基礎上進行上浮或下沉幅度的設定。

-在設定基線時系統支援實時檢視指標當日折現圖和歷史基線，幫助運維人員正確判斷基線的設定範圍。

-系統支援按照平均基線進行設定。

-基線設定時需要有一定的歷史資料作為依據。

•   智慧預測

智慧預測主要是通過歷史資料的分析，通過人工智慧演算法預測未來可能出現的問題，這一塊是未來監控事件優化的一個方向。

3、事件應急

1）應急恢復

運維最基本的指標就是系統可用性，應急恢復的時效性是系統可用性的關鍵指標。通常來講應急恢復的方法有不少，比如：

•  服務整體效能下降或異常，可以考慮重啟服務；

•  應用做過變更，可以考慮是否需要回切變更；

•  資源不足，可以考慮應急擴容；

•  應用效能問題，可以考慮調整應用引數、日誌引數；

•  資料庫繁忙，可以考慮通過資料庫快照分析，優化SQL；

•  應用功能設計有誤，可以考慮緊急關閉功能選單；

•  還有很多……

監控系統的事件豐富過程中需要儘可能關聯上述的一些應急手段，供運維人員快速應急，比如服務啟停工具、切換工具、程式回切工作等，比如下面這個應用服務啟停工具例子：

2）現場保護

故障處理中，理論上應該在應急前進行現場保護以備問題原因排查的跟進。現場資訊主要包含程序內部狀態資訊、日誌資訊。實際應用過程中可以結合工具進行現場保護，仍以服務啟停工具為例，支援獲取程序執行緒映象資訊、程序記憶體映象資訊及GC日誌資訊。

3）問題排查

•  是否為偶發性、是否可重現

故障現象是否可以重現，對於快速解決問題很重要，能重現說明總會有辦法或工具幫助我們定位到問題原因，而且能重現的故障往往可能是服務異常、變更等工作導致的問題。

但，如果故障是偶發性的，是有極小概率出現的，則比較難排查，這依賴於系統是否有足夠的故障期間的現場資訊來決定是否可以定位到總是原因。

•  是否進行過相關變更

大部份故障是由於變更導致，確定故障現象後，如果有應的變更，有助於從變更角度出現分析是否是變更引起，進而快速定位故障並準備好回切等應急方案。

•  是否可縮小範圍

一方面應用系統提倡解耦，一支交易會流經不同的應用系統及模組；另一方面，故障可能由於應用、系統軟體、硬體、網路等環節的問題。在排查故障原因時應該避免全面性的排查，建議先把問題範圍縮小到一定程式後再開始協調關聯團隊排查。

•  關聯方配合分析問題

與第（3）點避免同時各關聯團隊同時無頭緒的排查的同時，對於牽頭方在縮小範圍後需要開放的態度去請求關聯方配合定位，而對於關聯方則需要有積極配合的工作態度。

•  是否有足夠的日誌

定位故障原因，最常用的方法就是分析應用日誌，對運維人員不僅需要知道業務功能對應哪個服務程序，還要知道這個服務程序對應的哪些應用日誌，並具備一些簡單的應用日誌異常錯誤的判斷能力。

•  是否有core或dump等檔案

故障期間的系統現場很重要，這個在故障應急前建議在有條件的情況下留下系統現場的檔案，比如CORE\DUMP，或TRACE採集資訊等，備份好一些可能被覆蓋的日誌等。

4）應急文件

故障的表現雖然形式很多，但實際的故障處理過程中，應急措施往往重複使用幾個常用的步驟，所以應急文件首先要針對這些常用的場景，過於追求影響應用系統方方面面的內容，會導致這個方案可讀性變差，最終變更一個應付檢查的文件。以下是我覺得應用系統應急方案應該有的內容：

（1）系統級：

能知道當前應用系統在整個交易中的角色，當前系統出現問題或上下游出現問題時，可以知道如何配合上下游分析問題，比如：上下游系統如何通訊，通訊是否有唯一的關鍵字等。另外，系統級裡還涉及一些基本應急操作，比如擴容、系統及網路引數調整等。

（2）服務級：

能知道這個服務影響什麼業務，服務涉及的日誌、程式、配置檔案在哪裡，如何檢查服務是否正常，如何重啟服務，如何調整應用級引數等。

（3）交易級：

能知道如何查到某支或某類交易出現了問題，是大面積、區域性，還是偶發性問題，能用資料說明交易影響的情況，能定位到交易報錯的資訊。這裡最常用的方法就是資料庫查詢或工具的使用。知道最重要的交易如何檢查是否正常，重要的定時任務的應急處理方案，比如開業、換日、對賬的時間要求及應急措施。

（4）溝通方案：

溝通方案涉及通訊錄，包括上下游系統、第三方單位、業務部門等渠道。

另外，有了應急方案，如何讓運維人員持續去更新是難點。我認為要解決這個難點，需要先讓運維人員經常使用這個手冊。如果一個手冊沒有場景可以用，那就需要管理者為運維人員創造機會去使用這個手冊，比如應急演練。

五、持續優化

1、整體思路

監控系統建設目標是完善“監”能力，增加“控”的能力，這章提到的持續優化主要是針對“監”能力的落實，歸納起來就是“不漏報，少誤報”，可以針對不同的階段量化目標，比如60%告警即故障，80%故障來自監控。

2、措施

1）目標分解：

•   不漏報

漏報可以從兩個層面看，一個是監控工具不具備某一方面的監控能力；一個是監控工具具備監控能力，但因為使用者使用問題導致未覆蓋監控。前者需要完善監控能力，比如針對生產故障舉一反三式的優化，或由不同專業條線主動增加監控能力；後者則需要考慮幾個問題：

-管理上有沒有要求指標的100%覆蓋率

-覆蓋率的要求是否確實可以落地，或功能上是否設計極不友好

-100%的覆蓋率是否從技術預設設定，如果技術無法預設設定，能否從技術上主動發現

前面兩個問題需要從管理手段上解決，最後一個問題需要在監控系統中解決，即儘可能讓需要覆蓋的監控指標從技術上落地，減少對運維人員主動性上的依靠，同時監控系統要快速從技術上響應新的監控指標的落地。

•   減少誤報

誤報帶來的問題也很大，大量、反覆的誤報告警會讓運維人員麻木，進而忽視監控報警，錯過了真正的監控事件的處理，所以監控誤報情況也需要重視。

2）心得：

以下是在監控優化上的一些措施心得供參考：

第一階段：減少監控報警數量

目標：每週報警總量上下降60%

主要工作：

•   抓突出的報警指標，調整閥值，比如CPU、記憶體、空間、應用效能這幾塊大頭，如果閥值不合理將帶來大量告警，對這幾類指標閥值做優化會有事半功倍的效果；

•   抓每個指標突出的組、系統進行鍼對性整改，可能就是某個團隊或某些管理員不重視監控，解決刺頭的成效也很明顯；

•   針對重複性的告警，優化監控系統，減少重複報警；

第二階段：減少監控誤報率

目標：60%告警即故障（排除磁碟、表空間類）

主要工作：

•   區分監控級別，告警即故障：分析確認哪類監控報警必須作為事件處理，並將交易量監控設定為告警，非故障調整為預警；

•   所有預警即關聯工單，對預警工單閥值進行分析調整；

•   優化監控簡訊內容，提高簡訊對事件定位；

•   完成動態基線的監控功能上線功能，提高監控準確率；

•   完成應用部署與監控維護期關聯，減少未設定維護期導致的監控報警；

•   完成應用啟停集中處理，減少應用啟停帶來的維護期報警；

第三階段：提高監控對故障的覆蓋率

目標：80%故障來自監控

主要工作：

•   每週分析生產事件的發現環節，對於非監控發現的故障進行專項分析；

•   其它方案（針對第一、二階段實施情況完善）

第四階段：提高監控事件處理效率

目標：監控告警1小時內關閉

主要工作：

•   對監控報警耗時進行分析，並通報；

•   針對無法快速恢復的監控報警優化功能處理；

•   其它方案（待定）

3、團隊

因為有持續優化的工作，所以最好能夠有一個橫向的監控優化團隊，區分於監控系統工具建設團隊，作為監控的使用角色，這個團隊有幾個目標：

•   將持續優化的工作進行落地；

•   作好資料分析，比如監控的事件量是否突增，某些系統的事件是否陡增，誤報量是否過多，故障哪些不是通過監控發現，未通過監控發現的故障是否完成監控覆蓋面整改，監控功能有哪些不友好等等。

整理的內容有點長，有點羅嗦，稍整理了整篇總結的思維導圖：

文章來自微信公眾號：運維之路