[[282966]]

近年來，隨著計(jì)算機(jī)技術(shù)的飛速發(fā)展，以及行業(yè)信息的共享，傳統(tǒng)企業(yè)的運(yùn)維己不再固步自封，日新月異的計(jì)算技術(shù)發(fā)展推動著企業(yè)云平臺的建設(shè)，云平臺的計(jì)算能力為大數(shù)據(jù)分析提供了基礎(chǔ)，而云平臺與大數(shù)據(jù)分析又將推動運(yùn)維人工智能的發(fā)展。

放眼云、大數(shù)據(jù)、人工智能的運(yùn)維發(fā)展方向的同時(shí)，作為運(yùn)維的生命線，安全生產(chǎn)保障的生命線仍需強(qiáng)調(diào)。作為傳統(tǒng)企業(yè)的安全生產(chǎn)保障，主要以“監(jiān)、管、控”為核心，其中“監(jiān)”則主要指的是監(jiān)控。

本文將把筆者在工作過程中積累的監(jiān)控體系建設(shè)知識進(jìn)行總結(jié)，梳理成體系，思維導(dǎo)圖如下： 

監(jiān)控體系分層

概述

傳統(tǒng)企業(yè)的運(yùn)維經(jīng)過多年的積累，往往己沉淀下來不少監(jiān)控工具，有不同專業(yè)條的工具，如基礎(chǔ)設(shè)施、硬件、軟件、安全等；也有不同類型的工具，如基于日志、數(shù)據(jù)庫、中間件、操作系統(tǒng)、網(wǎng)絡(luò)報(bào)文等。對于這些工具，我們采用以下方式處理：

建立集中監(jiān)控平臺：在一體化運(yùn)維體系中，監(jiān)控平臺貫穿所有環(huán)節(jié)，它起到了生產(chǎn)系統(tǒng)涉及的軟硬件環(huán)境實(shí)時(shí)運(yùn)行狀況的“監(jiān)”，監(jiān)控平臺事件驅(qū)動的特性也為一體化運(yùn)維體系起到神經(jīng)網(wǎng)絡(luò)驅(qū)動的作用，進(jìn)而進(jìn)行了“控”，另外，監(jiān)控平臺優(yōu)質(zhì)的運(yùn)維數(shù)據(jù)可以作為運(yùn)維大數(shù)據(jù)分析的數(shù)據(jù)源，實(shí)現(xiàn)運(yùn)維數(shù)據(jù)采集的角色。為了提高投入效率，減少重復(fù)投入，需要建立集中監(jiān)控平臺實(shí)現(xiàn)統(tǒng)一展示、統(tǒng)一管理，支持兩地三中心建設(shè)，具備靈活的擴(kuò)展性，支持運(yùn)維大數(shù)據(jù)分析。

原有的監(jiān)控工具保留為主：當(dāng)前并沒有哪一個(gè)監(jiān)控工具可以覆蓋所有生產(chǎn)系統(tǒng)的運(yùn)行指標(biāo)，己沉淀下來的監(jiān)控工具往往是當(dāng)前生產(chǎn)系統(tǒng)深度定制的工具，具有存在價(jià)值。另外，雖然監(jiān)控平臺從WEB、APP、到DB均采用了多中心雙活分布式架構(gòu)部署，但為了保證監(jiān)控覆蓋能力，部份重要的環(huán)節(jié)仍建議不僅限一套監(jiān)控工具。

各專業(yè)條線對各條線的監(jiān)控負(fù)責(zé)：各專業(yè)條線是最清楚自己需要什么監(jiān)控的團(tuán)隊(duì)，各專業(yè)條線對監(jiān)控覆蓋率負(fù)責(zé)，監(jiān)控平臺的建設(shè)方負(fù)責(zé)平臺體系的建設(shè)，提供基礎(chǔ)技術(shù)支撐。

工具間整合：不同的專業(yè)條線、不同的分析技術(shù)可以有不同的監(jiān)控工具，采用這種多點(diǎn)開花的建設(shè)方式更有助于監(jiān)控面與深度的完善，所有的工具最終需要進(jìn)行標(biāo)準(zhǔn)化的整合。

基于上面4個(gè)處理思路，為防止監(jiān)控建設(shè)失控，減少重復(fù)建設(shè)、明確主要的建設(shè)目標(biāo)，我們需要對監(jiān)控工具進(jìn)行體系化管理，體系化管理首先要做的就是進(jìn)行監(jiān)控體系分層。

分層方式

相信每家企業(yè)對于監(jiān)控分層體系都會有各自的劃分方式，以下是以專業(yè)條線方式分層：

基礎(chǔ)設(shè)施層：包括運(yùn)營商專線、機(jī)房（機(jī)房內(nèi)的設(shè)施，比如制冷、安防等）、網(wǎng)絡(luò)設(shè)備，基礎(chǔ)設(shè)施層的監(jiān)控分為狀態(tài)、性能、質(zhì)量、容量、架構(gòu)、流量分析等幾個(gè)層面。

系統(tǒng)服務(wù)器層：包括系統(tǒng)服務(wù)器、存儲等服務(wù)器的可用性狀態(tài)。

系統(tǒng)及網(wǎng)絡(luò)服務(wù)層：主要是指操作系統(tǒng)、系統(tǒng)軟件、網(wǎng)絡(luò)軟件的使用情況。

應(yīng)用服務(wù)層：主要是針對應(yīng)用服務(wù)可用性、應(yīng)用營業(yè)狀態(tài)、應(yīng)用性能、應(yīng)用交易量分析幾方面。

客戶體驗(yàn)層：包括兩塊，一是客戶訪問速度；二是功能是否正常，具體指的是全部、局部、個(gè)別用戶或終端訪問情況，不僅包括業(yè)務(wù)系統(tǒng)是否能訪問，訪問的速度是否快，還包括業(yè)務(wù)邏輯的驗(yàn)證功能是否正常。

各層職責(zé)

基礎(chǔ)設(shè)施

• 狀態(tài)監(jiān)控：包括機(jī)房供電、空調(diào)、網(wǎng)絡(luò)設(shè)備的軟硬件狀態(tài)，如設(shè)備狀態(tài)等；
• 性能監(jiān)控：包括設(shè)備的性能情況，比如CPU、內(nèi)存大小、session數(shù)量、端口流量包量、內(nèi)存溢出監(jiān)控、內(nèi)存使用率等；
• 網(wǎng)絡(luò)監(jiān)控：包括設(shè)備錯(cuò)包、丟包率，針對網(wǎng)絡(luò)設(shè)備以及網(wǎng)絡(luò)鏈路的探測延時(shí)、丟包率監(jiān)控等；
• 容量監(jiān)控：包括設(shè)備負(fù)載使用率、專線帶寬使用率、出口流量分布等。

由于基礎(chǔ)設(shè)施硬件往往己有設(shè)備健康性的檢測機(jī)制，建議向這類廠商提要求，將設(shè)備的運(yùn)行事件主動送到監(jiān)控平臺整合。

服務(wù)器層

• 存儲：包括存儲設(shè)備，以及設(shè)備上的硬盤讀寫錯(cuò)誤、讀寫超時(shí)、硬盤掉線、硬盤介質(zhì)錯(cuò)誤；
• 服務(wù)器上的內(nèi)存（內(nèi)存缺失、內(nèi)存配置錯(cuò)誤、內(nèi)存不可用、內(nèi)存校驗(yàn)）、網(wǎng)卡（網(wǎng)卡速率；電源：電源電壓、電源模塊是否失效）、風(fēng)扇（風(fēng)扇轉(zhuǎn)速等）、Raid卡（Raid卡電池狀態(tài)、電池老化、電池和緩存是否在位、緩存策略）；
• 虛擬機(jī)：vcenter等
• 容器：Docker等

存儲、物理設(shè)備、虛擬機(jī)等建議參考基礎(chǔ)設(shè)施層由廠商主動匯總事件到監(jiān)控平臺，由于容器方面的監(jiān)控工具并不多，則需根據(jù)實(shí)際情況選擇是否借鑒開源的工具進(jìn)行自研。

系統(tǒng)服務(wù)層

系統(tǒng)服務(wù)層的數(shù)據(jù)主要包括操作系統(tǒng)、中間件、數(shù)據(jù)庫，以及其它開源分布式中間件等工具，這方面包括很多，以操作系統(tǒng)為例，包括：CPU（CPU整體使用率、CPU各核使用率、CPU Load負(fù)載）、內(nèi)存（應(yīng)用內(nèi)存、整體內(nèi)存、Swap等）、磁盤IO（讀寫速率、IOPS、平均等待延時(shí)、平均服務(wù)延時(shí)等）、網(wǎng)絡(luò)IO（流量、包量、錯(cuò)包、丟包）、連接（各種狀態(tài)的TCP連接數(shù)等）、進(jìn)程端口存活、文件句柄數(shù)、進(jìn)程數(shù)、內(nèi)網(wǎng)探測延時(shí)、丟包率等。

在分析系統(tǒng)服務(wù)層的數(shù)據(jù)消費(fèi)情況時(shí)，可以通過分析系統(tǒng)性能情況，客觀衡量業(yè)務(wù)負(fù)載高低情況，并結(jié)合擴(kuò)縮容調(diào)度，實(shí)現(xiàn)業(yè)務(wù)的負(fù)載和成本間的平衡。可以根據(jù)服務(wù)器所在業(yè)務(wù)層級（接入層、邏輯層還是數(shù)據(jù)層）的不同，設(shè)置不同的容量參考指標(biāo)、指標(biāo)參考基準(zhǔn)、指標(biāo)計(jì)算規(guī)則、高低負(fù)載判別規(guī)則，設(shè)置業(yè)務(wù)模塊（由相同功能的多個(gè)服務(wù)器構(gòu)成的業(yè)務(wù)集群）的擴(kuò)縮容規(guī)則；由系統(tǒng)計(jì)算出服務(wù)器、業(yè)務(wù)模塊的負(fù)載情況，決策出是否需要擴(kuò)容或縮容，觸發(fā)業(yè)務(wù)模塊的擴(kuò)縮容操作。

這一層的工具主要采用引入成熟工具或自研的方式，可選的空間比較大，只要覆蓋面夠廣、支持靈活的二次定制開發(fā)，應(yīng)該問題都不大，建設(shè)過程中，我認(rèn)為中間件與數(shù)據(jù)庫兩塊是值得讓DBA、中間件管理員深度挖掘監(jiān)控指標(biāo)覆蓋面。

另外，在互聯(lián)網(wǎng)分布式架構(gòu)的推動下，傳統(tǒng)企業(yè)也逐步使用一些分布式中間件，比如分布式數(shù)據(jù)庫中間件，內(nèi)存數(shù)據(jù)庫、消息隊(duì)列等。由于對于這類開源中間件，傳統(tǒng)企業(yè)在技術(shù)上弱于互聯(lián)網(wǎng)企業(yè)，且監(jiān)控工具并不多，需要重點(diǎn)投入資源進(jìn)行相關(guān)監(jiān)控指標(biāo)的開發(fā)。

應(yīng)用服務(wù)層

• 服務(wù)可用性監(jiān)控：如服務(wù)、端口是否存在，是否假死等；
• 應(yīng)用營業(yè)狀態(tài)監(jiān)控：指應(yīng)用的狀態(tài)是否滿足業(yè)務(wù)開業(yè)狀態(tài)；
• 應(yīng)用性能：應(yīng)用處理能力，比如交易量、成功率、失敗率、響應(yīng)率、耗時(shí)；
• 應(yīng)用交易：比如交易主動埋點(diǎn)、交易流水、ESB等。

應(yīng)用服務(wù)層監(jiān)控可擴(kuò)展的面與深入的度都有很大空間，以下是部分應(yīng)用監(jiān)控點(diǎn)：

客戶體驗(yàn)層

比如測速系統(tǒng)以及模擬用戶訪問的方式：

以模擬用戶訪問為例，通過模擬用戶訪問業(yè)務(wù)并校驗(yàn)返回?cái)?shù)據(jù)結(jié)果，監(jiān)測業(yè)務(wù)是否可用、訪問質(zhì)量及性能、邏輯功能正確性的監(jiān)控系統(tǒng)。不僅僅是接入層（網(wǎng)站類業(yè)務(wù)是否能訪問，訪問的速度是否快），業(yè)務(wù)邏輯的驗(yàn)證就涉及到登錄鑒權(quán)、關(guān)系數(shù)據(jù)自動化獲取等。

監(jiān)控整合

監(jiān)控的分層方式促進(jìn)了每一個(gè)專業(yè)層的監(jiān)控覆蓋面與深度，防止建設(shè)失控，但也帶來一個(gè)管理上的副作用，所以需要在事件、可視化、子系統(tǒng)、數(shù)據(jù)的整合，以減少管理成本。

在監(jiān)控整合上，主要從事件匯總、統(tǒng)一可視化、監(jiān)控?cái)?shù)據(jù)匯總?cè)矫孢M(jìn)行梳理。

事件匯總

Google SRE解密一書中提過（大體意思如下）：監(jiān)控應(yīng)該盡可能簡單地把需要人介入或關(guān)注的信息展示給運(yùn)維團(tuán)隊(duì)，能通過自動化自愈解決、分析定位過程則不在一級視圖提供。當(dāng)前，能實(shí)現(xiàn)自愈的企業(yè)還比較少，或還在摸索建設(shè)過程中，所以我先講講如何讓每天產(chǎn)生上億條流水，觸發(fā)上萬次告警條件（同一告警如未解除會持續(xù)不斷觸發(fā)告警條件），來自各種不同工具、不同格式的的告警事件以盡可能簡單的方式展示給一線監(jiān)控團(tuán)隊(duì)。

第一部分監(jiān)控分層中提到，原有的監(jiān)控工具以保留為主思路，這些工具在運(yùn)營過程中每天都會產(chǎn)生大量事件，為了實(shí)現(xiàn)監(jiān)控集中展示，集中管理，需要建設(shè)一個(gè)事件匯總的模塊實(shí)現(xiàn)事件統(tǒng)一匯總，并對不同層面、不同專業(yè)角度的事件進(jìn)行收斂，關(guān)聯(lián)分析，更全面的感知系統(tǒng)運(yùn)行狀況。

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

• Example01：從可視化角度看，不同的工具有不同的監(jiān)控事件展示界面，多個(gè)運(yùn)維視圖增加了運(yùn)維技能要求，需要更多的人力去管理生產(chǎn)；
• Example02：缺少對各類事件進(jìn)行匯總與數(shù)據(jù)分析，無法反映生產(chǎn)系統(tǒng)整體的運(yùn)行狀況，如能將這些事件數(shù)據(jù)匯總起來，比如物理層的拓?fù)洌瑒t可以直觀地管控應(yīng)用狀況；
• Example03：同一個(gè)生產(chǎn)問題往往會帶來多個(gè)維度的生產(chǎn)運(yùn)行問題，比如一臺物理機(jī)宕機(jī)，在這臺物理機(jī)上的虛擬機(jī)都會出現(xiàn)網(wǎng)絡(luò)、操作系統(tǒng)層面可用性、應(yīng)用可用性、交易級狀況、應(yīng)用性能、客戶體驗(yàn)的告警，如果監(jiān)控指標(biāo)足夠豐富往往會有上百條以上，不能準(zhǔn)確、快速定位問題根源；
• Example04：每天能觸發(fā)閥值的告警很多，以經(jīng)驗(yàn)的方式很難讓一線監(jiān)控團(tuán)隊(duì)無時(shí)無刻能準(zhǔn)確的定位哪些是高優(yōu)先級的告警，比如磁盤空間到了70%的確需要有人去關(guān)注，評估是否進(jìn)行數(shù)據(jù)清理、擴(kuò)容，但這類告警屬于低優(yōu)先級的事件。

從上面4個(gè)例子可以看到，事件匯總模塊需要有幾個(gè)基本要求：

• 事件匯總：匯總不同層次、不同專業(yè)條線、不同類型事件是監(jiān)控集中管理的基礎(chǔ)。
• 事件收斂：前面提到同一個(gè)故障會觸發(fā)多類指標(biāo)的告警，同一個(gè)指標(biāo)在故障未解除前也會重復(fù)產(chǎn)生大量的告警事件，如果將全部事件都展示出來，那對于監(jiān)控處理人員將是災(zāi)難性的，所以需要進(jìn)行事件收斂。
• 事件分級：對于不同的事件需要有適當(dāng)層次的事件分級，事件升級的策略。事件分級是將事件當(dāng)前緊急程度進(jìn)行標(biāo)識顯示，事件升級是對于低級的事件當(dāng)達(dá)到一定的程度，比如處理時(shí)間過長，則需要進(jìn)行升級。
• 事件分析：事件分析是建立事件的關(guān)聯(lián)關(guān)系，關(guān)聯(lián)分析可以從縱向和橫向關(guān)系進(jìn)行分析，縱向是指從底層的基礎(chǔ)設(shè)施、網(wǎng)絡(luò)、服務(wù)器硬件、虛擬機(jī)/容器、操作系統(tǒng)、中間件、應(yīng)用域、應(yīng)用、交易；橫向是指從當(dāng)前的應(yīng)用節(jié)點(diǎn)、上游服務(wù)器節(jié)點(diǎn)、下游服務(wù)器節(jié)點(diǎn)的交易關(guān)系。事件分析是形成故障樹，自愈的基礎(chǔ)。

對于事件分析重點(diǎn)在于關(guān)系模型的建立，互聯(lián)網(wǎng)公司有不少標(biāo)準(zhǔn)化的方案，但我個(gè)人認(rèn)為需要開發(fā)團(tuán)隊(duì)介入改造的標(biāo)準(zhǔn)化不可控，所以另外一方向是針對企業(yè)內(nèi)部特點(diǎn)，以CMDB、應(yīng)用配置庫為中心，或以節(jié)點(diǎn)型的系統(tǒng)為中心去建立關(guān)系模型，具體介紹見后面第三部分。

• 高性能：為了實(shí)現(xiàn)實(shí)時(shí)監(jiān)控，需要事件匯總模塊具備高性能。
• 對外提供采集事件數(shù)據(jù)接口：監(jiān)控作為一體化運(yùn)維體系的一部份，需要對外提供服務(wù)化接口，支持事件數(shù)據(jù)的采集。

統(tǒng)一可視化

不同監(jiān)控工具有著不同界面，不同的操作方法，對工具的掌握程度依賴于運(yùn)維人員的經(jīng)驗(yàn)，監(jiān)控管理很難形成標(biāo)準(zhǔn)化，不利于監(jiān)控的集中管理、釋放人力成本。所以，監(jiān)控事件匯總后，需要有一個(gè)統(tǒng)一的可視化，支持統(tǒng)一展示、多類型展示形式、多維用戶視角、支持按需訂閱的特點(diǎn)。具體包括：

支持事件的統(tǒng)一展示：支持不同角色用戶管理不同的事件，包括事件的受理、分派、督辦、升級、解除、轉(zhuǎn)工單等閉環(huán)操作，無需在不同工具上多次操作。

多類型的展現(xiàn)形式：PC電腦的web端，移動手持端，大屏展示，為了支持可視化的快速開發(fā)，以及低成本的過渡到移動手持端，建議采用H5的技術(shù)選型。

多維用戶：根據(jù)不同機(jī)構(gòu)、不同用戶的關(guān)注點(diǎn)，比如一線運(yùn)維主要關(guān)注實(shí)時(shí)告警，二線運(yùn)維主要關(guān)注事件豐富與故障樹等輔助定位，值班經(jīng)理主要關(guān)注當(dāng)天監(jiān)控事件處理情況，團(tuán)隊(duì)管理者主要關(guān)注團(tuán)隊(duì)內(nèi)監(jiān)控事件與重要業(yè)務(wù)系統(tǒng)運(yùn)行狀況，主管經(jīng)理主要關(guān)注整合的運(yùn)行情況與人員處理情況，開發(fā)人員需要有協(xié)助處理的視角數(shù)據(jù)等。

支持用戶訂閱展示：針對不同的業(yè)務(wù)運(yùn)營場景、不同的用戶進(jìn)行布局、推送數(shù)據(jù)、監(jiān)控指標(biāo)的訂閱式展示，比如，雙十一或秒殺的運(yùn)營活動，需要關(guān)注幾十個(gè)OS的資源情況，各個(gè)OS上的交易、性能情況，如果每一個(gè)指標(biāo)一個(gè)窗口，需要看幾十個(gè)窗口；如果只看告警信息，又無法觀察到趨勢；所以，需要支持多指標(biāo)合并在一個(gè)視圖頁面的訂閱功能。

數(shù)據(jù)整合標(biāo)準(zhǔn)

關(guān)于數(shù)據(jù)整合，這里不再復(fù)述不同監(jiān)控工具事件數(shù)據(jù)的整合，主要從報(bào)文、日志、數(shù)據(jù)庫流水幾個(gè)角度分析：

1）報(bào)文解釋

報(bào)文解釋標(biāo)準(zhǔn)，以天旦BPC為例做個(gè)介紹：

市場上有很多APM，大體可以分為主動模擬撥測、頁面插入代碼監(jiān)測、客戶端插件采集、服務(wù)端代理收集、服務(wù)端旁路報(bào)文監(jiān)聽。天旦的BPC采用服務(wù)端的網(wǎng)絡(luò)層旁路抓取一份報(bào)文，通過預(yù)先定義好的解碼策略，解出了一份數(shù)據(jù)格式良好的數(shù)據(jù)源。在這份數(shù)據(jù)源之上可以進(jìn)行監(jiān)控、運(yùn)維數(shù)據(jù)分析等運(yùn)維場景的使用。由于BPC報(bào)文解碼配置設(shè)計(jì)比較簡單，支持秒級（預(yù)計(jì)17年將有毫秒級的產(chǎn)品出來），且對應(yīng)用服務(wù)性能無影響，用旁路報(bào)文解釋的方式作為數(shù)據(jù)輸入標(biāo)準(zhǔn)成為一種值得推薦的方式。

2）日志結(jié)構(gòu)標(biāo)準(zhǔn)

日志結(jié)構(gòu)標(biāo)準(zhǔn)，主要分兩類，一類是直接建一個(gè)日志分析平臺，比如國外的Splunk，或者開源的ELK等；另一類是重構(gòu)日志標(biāo)準(zhǔn)組件，比如重構(gòu)Java企業(yè)應(yīng)用中經(jīng)常使用的log4j開源包的標(biāo)準(zhǔn)輸出方法，對日志結(jié)構(gòu)進(jìn)行整合，并通過異步消息的方式將日志發(fā)送給監(jiān)控平臺，再提供可視化的IDE對不同系統(tǒng)的日格式進(jìn)行進(jìn)一步整理，將需要的數(shù)據(jù)抽取整合。

3）數(shù)據(jù)庫流水標(biāo)準(zhǔn)

在監(jiān)控?cái)?shù)據(jù)庫流水中，也分兩類，一類是建立標(biāo)準(zhǔn)的運(yùn)維流水表，監(jiān)控直接讀取這些流水進(jìn)行監(jiān)控或分析；另一類參考重構(gòu)log4j的思路，對jdbc的包進(jìn)行重構(gòu)，將數(shù)據(jù)庫執(zhí)行語句，以及語句執(zhí)行過程中的開始時(shí)間、結(jié)構(gòu)時(shí)間、返回狀態(tài)進(jìn)行記錄。第一類我們用得比較多，當(dāng)前的交易級的監(jiān)控主要采用這種方式進(jìn)行，第二類目前仍處于思路階段。

4）其它思路

其實(shí)針對日志LOG4J、數(shù)據(jù)庫JDBC這兩種方式從思路看都是從節(jié)點(diǎn)類的模塊進(jìn)行，往同類擴(kuò)展，可以針對標(biāo)準(zhǔn)應(yīng)用中間件、WEB等模塊進(jìn)行處理；往大的擴(kuò)展，則比如企業(yè)ESB類的應(yīng)用系統(tǒng)可以作用標(biāo)準(zhǔn)的數(shù)據(jù)整合。這些節(jié)點(diǎn)類的模塊進(jìn)行數(shù)據(jù)整合標(biāo)準(zhǔn)往往可以有事半功倍的作用。

監(jiān)控指標(biāo)

如前一部分提到，監(jiān)控有賴于運(yùn)維各專業(yè)條線協(xié)同完善，通過將監(jiān)控體系進(jìn)行分層、分類，各專業(yè)條線再去有重點(diǎn)的豐富監(jiān)控指標(biāo)。

指標(biāo)分類

1）基礎(chǔ)設(shè)施層

環(huán)境動力：暖通系統(tǒng)（如空調(diào)、新風(fēng)系統(tǒng)、機(jī)房環(huán)境、漏水等）、電力系統(tǒng)（如配電柜、UPS、ATS等）、安防系統(tǒng)（如防雷、消防、門禁等）等

網(wǎng)絡(luò)設(shè)備：路由器、二三層網(wǎng)絡(luò)交換機(jī)、多層交換機(jī)、負(fù)載均衡設(shè)備等

安全設(shè)備：防火墻、入侵檢測、防病毒、加密機(jī)等

2）服務(wù)器層

虛擬化：虛擬網(wǎng)絡(luò)資源、虛擬主機(jī)、虛擬存儲資源等

存儲設(shè)備：磁盤陣列、虛擬帶庫、物理磁帶庫、SAN、NAS等

服務(wù)器：大中小型機(jī)、X86服務(wù)器

3）系統(tǒng)軟件層

操作系統(tǒng)：AIX、LINUX、WINDOWS等

數(shù)據(jù)庫：ORACLE、DB2、SQL SERVER、MYSQL等

中間件：WEBSPHERE、WEBLOGIC、MQ、IHS、TOMCAT、AD、REDIS等

其他系統(tǒng)軟件：備份軟件

4）應(yīng)用服務(wù)層

服務(wù)可用性：服務(wù)狀態(tài)、日志刷新、端口監(jiān)聽、網(wǎng)絡(luò)連通性等

應(yīng)用交易：交易整體情況、應(yīng)用性能（重要交易或整個(gè)節(jié)點(diǎn)的交易量、耗時(shí)、成功率、響應(yīng)率）、開業(yè)情況、批量交易狀態(tài)等

5）客戶體驗(yàn)層

客戶訪問速度：

頁面響應(yīng)時(shí)間、撥測登錄、普通頁面渲染時(shí)間、重要接口響應(yīng)時(shí)間等
具體的監(jiān)控指標(biāo)內(nèi)容與閥值參考的明細(xì)不同的行業(yè)，不同的系統(tǒng)會有不同的認(rèn)識，這里不細(xì)列。

指標(biāo)權(quán)重與閥值分級

在分解具體指標(biāo)前，需要重點(diǎn)強(qiáng)調(diào)一下監(jiān)控指標(biāo)的指標(biāo)權(quán)重、閥值分級與上升機(jī)制問題，做監(jiān)控的人知道“監(jiān)”的最重要目標(biāo)是不漏報(bào)，為了不漏報(bào)在實(shí)際實(shí)施過程中會出現(xiàn)監(jiān)控告警過多的困難。如何讓運(yùn)維人員在不漏處理監(jiān)控事件，又能快速解決風(fēng)險(xiǎn)最高的事件？則需要監(jiān)控的指標(biāo)需要進(jìn)行指標(biāo)權(quán)重、閥值分級與上升機(jī)制：

1）指標(biāo)權(quán)重

監(jiān)控指標(biāo)的權(quán)重是為了定義此項(xiàng)監(jiān)控指標(biāo)是否為必須配置，比如應(yīng)用軟件服務(wù)、端口監(jiān)聽是一個(gè)應(yīng)用可用性的重要指標(biāo)，權(quán)重定義為一級指標(biāo)；對于批量狀態(tài)，則由于不少應(yīng)用系統(tǒng)并沒有批量狀態(tài)，則定義為二級指標(biāo)。通常來說一級指標(biāo)將作為監(jiān)控覆蓋面的底線，通過設(shè)置好權(quán)重，一是為了讓運(yùn)維人員知道哪些監(jiān)控指標(biāo)必須確保覆蓋，同時(shí)加以引入KPI考核；二是為了讓監(jiān)控平臺建設(shè)人員有側(cè)重的優(yōu)化，實(shí)現(xiàn)一級指標(biāo)的自動配置，無需運(yùn)維人員手工配置。

2）閥值分級與上升機(jī)制

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

對于升級，是指一個(gè)預(yù)警當(dāng)長時(shí)間未處理時(shí)，需要有一個(gè)上升機(jī)制，轉(zhuǎn)化為告警，以督辦運(yùn)維人員完成監(jiān)控事件的處理。

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

3）指標(biāo)基線

當(dāng)前運(yùn)行狀況是否正常需要用運(yùn)行情況與閥值作比較，但實(shí)際實(shí)施過程中會發(fā)現(xiàn)一個(gè)固定的閥值會導(dǎo)致不少監(jiān)控誤報(bào)，比如業(yè)務(wù)運(yùn)營大促與非運(yùn)營活動日、非工作日與工作日、白天與晚上的運(yùn)行值都會有不小的差異，所以需要建立一個(gè)動態(tài)的指標(biāo)基線，當(dāng)前運(yùn)行值與動態(tài)基線的偏離度大小來判斷是否為監(jiān)控事件。指標(biāo)基線的建設(shè)過程中有幾個(gè)方面需要關(guān)注：

基線的自我學(xué)習(xí)

前面己提到指標(biāo)的基線是動態(tài)的，基線動態(tài)就需要對系統(tǒng)運(yùn)行的情況按一個(gè)指定的時(shí)間間隔粒度進(jìn)行學(xué)習(xí)，理論上運(yùn)行學(xué)習(xí)的時(shí)間越長，基線越準(zhǔn)確（但如果業(yè)務(wù)做了推廣，歷史的基線數(shù)據(jù)則需要降低權(quán)重）。

基線指標(biāo)的組合

有些情況判斷一個(gè)監(jiān)控指標(biāo)是否是事件，需要將多個(gè)指標(biāo)放在一起看才能判斷。比如WINDOWS集群下的SQL SERVER進(jìn)程內(nèi)存長期都占95%以上，如果將內(nèi)存作為基線畫線，就會是一條高負(fù)載的線，所以可以考慮將CPU、內(nèi)存兩個(gè)指標(biāo)合并作為一個(gè)基線指標(biāo)。

另外，還可以用不同時(shí)間段與指標(biāo)組合的方式，比如按節(jié)假日與非節(jié)假日、按星期幾、按白天與晚上設(shè)計(jì)不同的基線。

性能

基線是由指定時(shí)間段的大量歷史數(shù)據(jù)不斷迭加組合，間隔的時(shí)間越短需要的性能越高，尤其是當(dāng)基線的組合類型豐富的情況下，需要大量的計(jì)算資源，選用一個(gè)合理的計(jì)算方案就顯得很重要。我們原來采用單庫跑基線，只能做到30分鐘一個(gè)點(diǎn)，目前采用分布式數(shù)據(jù)庫結(jié)合緩存方式設(shè)計(jì)性能，未來根據(jù)基線運(yùn)行的情況再考慮是否選用大數(shù)據(jù)流計(jì)算等技術(shù)框架。

基線的人工調(diào)整

系統(tǒng)運(yùn)行過程中難免會因?yàn)闃I(yè)務(wù)運(yùn)營推廣等導(dǎo)致歷史基線不能反映指標(biāo)是否合理，這時(shí)候需要有一個(gè)人工調(diào)整基線的入口，運(yùn)維人員可以重新繪制基線、減少對歷史數(shù)據(jù)的參考權(quán)重等。

另外，人工智能這么火，也提一點(diǎn)通過機(jī)器學(xué)習(xí)來實(shí)現(xiàn)監(jiān)控基線的思路（思路還不成熟，僅供參考）：

將應(yīng)用運(yùn)行健康與不健康的樣本數(shù)據(jù)匯總，樣本中不同指標(biāo)的指標(biāo)數(shù)據(jù)作為不同的變量，結(jié)合不同的算法，通過調(diào)參學(xué)習(xí)后，得到運(yùn)行狀態(tài)好壞的基線。這樣，就可以將基線做一個(gè)監(jiān)控運(yùn)行狀態(tài)的服務(wù)，把實(shí)際運(yùn)行的多個(gè)監(jiān)控指標(biāo)數(shù)據(jù)關(guān)給基線服務(wù)，基線服務(wù)返回當(dāng)前服務(wù)運(yùn)行好壞。

監(jiān)控事件

監(jiān)控事件反映的是IT基礎(chǔ)設(shè)施、中間件、應(yīng)用程序、業(yè)務(wù)流程等運(yùn)行過程中發(fā)生的問題。監(jiān)控系統(tǒng)通過采集運(yùn)行數(shù)據(jù)，通過數(shù)據(jù)判斷規(guī)則生成事件，監(jiān)控事件還涉及事件的處理（比如事件豐富、收斂等）、事件的關(guān)聯(lián)分析，并驅(qū)動事件的解決。

以下是監(jiān)控事件處理的一般流程圖：

前面提到了事件整合，下面主要講講事件關(guān)聯(lián)、事件應(yīng)急、事件分析、智能處理方面的建設(shè)思路。

事件標(biāo)準(zhǔn)

事件數(shù)據(jù)模型

事件數(shù)據(jù)主要包含數(shù)據(jù)頭信息、靜態(tài)豐富信息、事件現(xiàn)場信息、知識庫信息、關(guān)聯(lián)信息。

靜態(tài)豐富信息：包含描述豐富信息、拓?fù)湄S富信息，描述豐富信息主要包含相關(guān)人員描述信息、服務(wù)器描述信息、工單信息等，這塊豐富數(shù)據(jù)可以通過CMDB消費(fèi)獲取，這部份豐富數(shù)據(jù)有助于事件處理過程中關(guān)聯(lián)分析。

事件現(xiàn)場信息：包含指標(biāo)信息、性能信息、系統(tǒng)資源信息等，這部份信息主要是反映事件的現(xiàn)場數(shù)據(jù)。

知識庫信息：主要指相似歷史事件及其處理方式等信息，比如“建議如何做，己自動進(jìn)行了什么動作”等。關(guān)聯(lián)信息主要包含從屬事件信息、關(guān)聯(lián)影響信息。

事件分級標(biāo)準(zhǔn)

前面提到了事件分級的問題，分級是將事件當(dāng)前緊急程度進(jìn)行標(biāo)識顯示，事件升級是對于低級的事件當(dāng)達(dá)到一定的程度，比如處理時(shí)間過長，則需要進(jìn)行升級。我們將監(jiān)控事件等級事件級別分為通知、預(yù)警、故障三種：

• 通知：指一般的通知信息類事件。
• 預(yù)警：指已經(jīng)出現(xiàn)異常，即將要引起生產(chǎn)故障的事件。
• 故障：指已經(jīng)發(fā)生問題，并且已經(jīng)影響到生產(chǎn)流程的事件，如果需要進(jìn)一步細(xì)化故障級別，可以分為一般故障和緊急故障：一般故障不需要緊急處理的故障，緊急故障需要管理員緊急處理的故障。

事件細(xì)分的粒度需根據(jù)各企業(yè)團(tuán)隊(duì)的管理要求而定。

事件關(guān)聯(lián)

1）事件壓縮及收斂

事件壓縮及收斂就是為了減少事件數(shù)量，提高事件定位能力。

監(jiān)控采集數(shù)據(jù)后，根據(jù)具體的單指標(biāo)或多指標(biāo)的規(guī)則判斷是否觸發(fā)事件，如觸發(fā)事件，則發(fā)送事件接收器。為什么不直接通過可視化方式馬上將匹配到的事件信息呈現(xiàn)給監(jiān)控人員呢？那是由于監(jiān)控?cái)?shù)據(jù)采集是實(shí)時(shí)采集，但事件的解決可能并非馬上解決，為了減少重復(fù)性的告警數(shù)量，需要由事件處理引擎進(jìn)一步壓縮處理。比如每2分鐘采集一次文件系統(tǒng)容器數(shù)據(jù)，當(dāng)某個(gè)文件系統(tǒng)容量超過70%后，觸發(fā)了預(yù)警閥值，但這個(gè)文件系統(tǒng)是緩慢增長，計(jì)劃在當(dāng)周的擴(kuò)容窗口集中變更，如果不對事件進(jìn)行處理，那每2分鐘就會有一個(gè)預(yù)警，產(chǎn)生預(yù)警泛濫，所以這時(shí)需要對事件進(jìn)行壓縮，比如針對事件來源、關(guān)鍵字組合等規(guī)則進(jìn)行壓縮，并記錄事件發(fā)生次數(shù)。

有了事件壓縮還不夠，因?yàn)橛|發(fā)事件的指標(biāo)往往是相互關(guān)聯(lián)的，這就需要對多項(xiàng)指標(biāo)關(guān)系進(jìn)行分析，減少相同問題產(chǎn)生的事件。比如這個(gè)應(yīng)用場景：

NAS監(jiān)控：NAS文件系統(tǒng)在各OS上都會有監(jiān)控，一個(gè)NAS文件系統(tǒng)出問題時(shí)，每個(gè)服務(wù)器的NAS文件系統(tǒng)監(jiān)控都會報(bào)警。如能對NAS進(jìn)行掛載關(guān)系梳理，同一NAS的報(bào)警可以大量收斂。

進(jìn)程、端口、通訊檢測：一個(gè)進(jìn)程宕掉時(shí)，該進(jìn)程啟動的端口、關(guān)聯(lián)系統(tǒng)與該進(jìn)程端口的通訊等都會同時(shí)報(bào)警。如能對進(jìn)程、端口、通訊關(guān)系進(jìn)行梳理，同一個(gè)進(jìn)程引發(fā)的進(jìn)程、端口、通訊監(jiān)控事件也能收斂明顯。

2）事件豐富

事件豐富包括事件描述豐富（通過CMDB豐富、拓?fù)湄S富）、事件現(xiàn)場豐富（指標(biāo)信息豐富、APM信息豐富、系統(tǒng)資源信息豐富）、知識庫豐富，提高運(yùn)維人員分析問題的能力。

事件主要豐富方法如下：

• 與第三方監(jiān)控系統(tǒng)對接，獲取事件相關(guān)信息進(jìn)行豐富。如與CMDB系統(tǒng)對接，獲取服務(wù)器等相關(guān)配置信息進(jìn)行CMDB數(shù)據(jù)豐富；
• 根據(jù)拓?fù)潢P(guān)系模型，進(jìn)行拓?fù)湄S富；
• 指標(biāo)信息豐富：獲取事件發(fā)生前后一段時(shí)間內(nèi)的相關(guān)指標(biāo)信息數(shù)據(jù)（如CPU/內(nèi)存等），進(jìn)行指標(biāo)信息豐富；
• 相關(guān)事件豐富：根據(jù)拓?fù)潢P(guān)系模型、應(yīng)用關(guān)系關(guān)聯(lián)模型、交易流行關(guān)聯(lián)模型將相近事件時(shí)間范圍內(nèi)的事件進(jìn)行豐富展示；
• 知識庫豐富：建立事件處理方案知識庫，記錄事件處理的方法和流程，為事件處理人提供參考依據(jù)，以及為后續(xù)自動化運(yùn)維提供理論支撐。

下面這個(gè)是我們做的一個(gè)事件豐富，主要包括幾塊內(nèi)容：

• 事件涉及的軟硬件的基本配置信息、人員信息，這一塊是基本CMDB的數(shù)據(jù)消費(fèi)；
• 事件報(bào)警的主體信息，包括時(shí)間、事件描述、事件可能原因、事件處理情況等；
• 事件應(yīng)急處理及流程工單鏈接；
• 事件主體信息的具體指標(biāo)數(shù)據(jù)展示，以及指標(biāo)變化趨勢；
• 最近30分鐘的事件情況，以備分析是否受其它事件關(guān)聯(lián)影響；
• 該事件所在OS的CPU、內(nèi)存、IO的信息；
• 事件涉及的性能信息，比如交易量、成功率、交易耗時(shí)；
• 事件處理進(jìn)展。

3）事件擴(kuò)散

事件發(fā)生之后，監(jiān)控系統(tǒng)需要能自動分析事件的關(guān)聯(lián)信息，幫助運(yùn)維人員盡可能的還原事件現(xiàn)場，提高分析問題的能力，關(guān)聯(lián)信息主要有縱向和橫向的關(guān)系，其中縱向的關(guān)聯(lián)是把基礎(chǔ)設(shè)施、網(wǎng)絡(luò)、系統(tǒng)、應(yīng)用域、應(yīng)用、交易關(guān)聯(lián)起來，任何一個(gè)環(huán)節(jié)出問題，向上計(jì)算出波及范圍和受影響系統(tǒng)；橫向的關(guān)聯(lián)是以交易為中心，計(jì)算上下游的交易節(jié)點(diǎn)。下面分別是兩個(gè)關(guān)聯(lián)：

橫向關(guān)系：

4）事件觸發(fā)

系統(tǒng)在設(shè)置報(bào)警策略時(shí)，可針對指標(biāo)進(jìn)行觸發(fā)條件設(shè)置，觸發(fā)條件按照類型分為閾值觸發(fā)、基線觸發(fā)、智能預(yù)測。系統(tǒng)根據(jù)不同的觸發(fā)類型設(shè)置，采用的判斷方式也不一樣。具體明細(xì)如下：

• 閾值觸發(fā)

系統(tǒng)支持指標(biāo)的閾值觸發(fā)設(shè)置，當(dāng)指標(biāo)值達(dá)到設(shè)置的閾值時(shí)即可進(jìn)行報(bào)警。

閾值的設(shè)置范圍只能在該指標(biāo)的數(shù)值范圍內(nèi)進(jìn)行設(shè)置。

閾值在設(shè)置時(shí)需要指定數(shù)值單位，防止數(shù)值因單位不同出現(xiàn)判斷錯(cuò)誤。

在設(shè)置閾值時(shí)系統(tǒng)支持實(shí)時(shí)查看指標(biāo)當(dāng)日折現(xiàn)圖和歷史基線，幫助運(yùn)維人員正確判斷閾值的設(shè)置范圍。

• 基線觸發(fā)

系統(tǒng)支持指標(biāo)的基線觸發(fā)設(shè)置，當(dāng)指標(biāo)值達(dá)到設(shè)置的基線時(shí)即可進(jìn)行報(bào)警。

基線設(shè)置可按照昨日基線、月基線、周基線進(jìn)行設(shè)置。

系統(tǒng)支持在選定的基線基礎(chǔ)上進(jìn)行上浮或下沉幅度的設(shè)置。

在設(shè)置基線時(shí)系統(tǒng)支持實(shí)時(shí)查看指標(biāo)當(dāng)日折現(xiàn)圖和歷史基線，幫助運(yùn)維人員正確判斷基線的設(shè)置范圍。

系統(tǒng)支持按照平均基線進(jìn)行設(shè)置。

基線設(shè)置時(shí)需要有一定的歷史數(shù)據(jù)作為依據(jù)。

• 智能預(yù)測

智能預(yù)測主要是通過歷史數(shù)據(jù)的分析，通過人工智能算法預(yù)測未來可能出現(xiàn)的問題，這一塊是未來監(jiān)控事件優(yōu)化的一個(gè)方向。

事件應(yīng)急

1）應(yīng)急恢復(fù)

運(yùn)維最基本的指標(biāo)就是系統(tǒng)可用性，應(yīng)急恢復(fù)的時(shí)效性是系統(tǒng)可用性的關(guān)鍵指標(biāo)。通常來講應(yīng)急恢復(fù)的方法有不少，比如：

• 服務(wù)整體性能下降或異常，可以考慮重啟服務(wù)；
• 應(yīng)用做過變更，可以考慮是否需要回切變更；
• 資源不足，可以考慮應(yīng)急擴(kuò)容；
• 應(yīng)用性能問題，可以考慮調(diào)整應(yīng)用參數(shù)、日志參數(shù)；
• 數(shù)據(jù)庫繁忙，可以考慮通過數(shù)據(jù)庫快照分析，優(yōu)化SQL；
• 應(yīng)用功能設(shè)計(jì)有誤，可以考慮緊急關(guān)閉功能菜單；
• 還有很多……

監(jiān)控系統(tǒng)的事件豐富過程中需要盡可能關(guān)聯(lián)上述的一些應(yīng)急手段，供運(yùn)維人員快速應(yīng)急，比如服務(wù)啟停工具、切換工具、程序回切工作等，比如下面這個(gè)應(yīng)用服務(wù)啟停工具例子：

縱向關(guān)系：

2）現(xiàn)場保護(hù)**

故障處理中，理論上應(yīng)該在應(yīng)急前進(jìn)行現(xiàn)場保護(hù)以備問題原因排查的跟進(jìn)。現(xiàn)場信息主要包含進(jìn)程內(nèi)部狀態(tài)信息、日志信息。實(shí)際應(yīng)用過程中可以結(jié)合工具進(jìn)行現(xiàn)場保護(hù)，仍以服務(wù)啟停工具為例，支持獲取進(jìn)程線程鏡像信息、進(jìn)程內(nèi)存鏡像信息及GC日志信息。

3）問題排查

• 是否為偶發(fā)性、是否可重現(xiàn)

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

但，如果故障是偶發(fā)性的，是有極小概率出現(xiàn)的，則比較難排查，這依賴于系統(tǒng)是否有足夠的故障期間的現(xiàn)場信息來決定是否可以定位到總是原因。

• 是否進(jìn)行過相關(guān)變更

大部份故障是由于變更導(dǎo)致，確定故障現(xiàn)象后，如果有應(yīng)的變更，有助于從變更角度出現(xiàn)分析是否是變更引起，進(jìn)而快速定位故障并準(zhǔn)備好回切等應(yīng)急方案。

• 是否可縮小范圍

一方面應(yīng)用系統(tǒng)提倡解耦，一支交易會流經(jīng)不同的應(yīng)用系統(tǒng)及模塊；另一方面，故障可能由于應(yīng)用、系統(tǒng)軟件、硬件、網(wǎng)絡(luò)等環(huán)節(jié)的問題。在排查故障原因時(shí)應(yīng)該避免全面性的排查，建議先把問題范圍縮小到一定程序后再開始協(xié)調(diào)關(guān)聯(lián)團(tuán)隊(duì)排查。

• 關(guān)聯(lián)方配合分析問題

與第3小點(diǎn)結(jié)合避免各關(guān)聯(lián)團(tuán)隊(duì)同時(shí)無頭緒的排查的同時(shí)，對于牽頭方在縮小范圍后需要開放的態(tài)度去請求關(guān)聯(lián)方配合定位，而對于關(guān)聯(lián)方則需要有積極配合的工作態(tài)度。

• 是否有足夠的日志

定位故障原因，最常用的方法就是分析應(yīng)用日志，對運(yùn)維人員不僅需要知道業(yè)務(wù)功能對應(yīng)哪個(gè)服務(wù)進(jìn)程，還要知道這個(gè)服務(wù)進(jìn)程對應(yīng)的哪些應(yīng)用日志，并具備一些簡單的應(yīng)用日志異常錯(cuò)誤的判斷能力。

• 是否有core或dump等文件

故障期間的系統(tǒng)現(xiàn)場很重要，這個(gè)在故障應(yīng)急前建議在有條件的情況下留下系統(tǒng)現(xiàn)場的文件，比如COREDUMP，或TRACE采集信息等，備份好一些可能被覆蓋的日志等。

4）應(yīng)急文檔

故障的表現(xiàn)雖然形式很多，但實(shí)際的故障處理過程中，應(yīng)急措施往往重復(fù)使用幾個(gè)常用的步驟，所以應(yīng)急文檔首先要針對這些常用的場景，過于追求影響應(yīng)用系統(tǒng)方方面面的內(nèi)容，會導(dǎo)致這個(gè)方案可讀性變差，最終變更一個(gè)應(yīng)付檢查的文檔。以下是我覺得應(yīng)用系統(tǒng)應(yīng)急方案應(yīng)該有的內(nèi)容：

系統(tǒng)級

能知道當(dāng)前應(yīng)用系統(tǒng)在整個(gè)交易中的角色，當(dāng)前系統(tǒng)出現(xiàn)問題或上下游出現(xiàn)問題時(shí)，可以知道如何配合上下游分析問題，比如：上下游系統(tǒng)如何通訊，通訊是否有唯一的關(guān)鍵字等。另外，系統(tǒng)級里還涉及一些基本應(yīng)急操作，比如擴(kuò)容、系統(tǒng)及網(wǎng)絡(luò)參數(shù)調(diào)整等。

服務(wù)級

能知道這個(gè)服務(wù)影響什么業(yè)務(wù)，服務(wù)涉及的日志、程序、配置文件在哪里，如何檢查服務(wù)是否正常，如何重啟服務(wù)，如何調(diào)整應(yīng)用級參數(shù)等。

交易級

能知道如何查到某支或某類交易出現(xiàn)了問題，是大面積、局部，還是偶發(fā)性問題，能用數(shù)據(jù)說明交易影響的情況，能定位到交易報(bào)錯(cuò)的信息。這里最常用的方法就是數(shù)據(jù)庫查詢或工具的使用。知道最重要的交易如何檢查是否正常，重要的定時(shí)任務(wù)的應(yīng)急處理方案，比如開業(yè)、換日、對賬的時(shí)間要求及應(yīng)急措施。

溝通方案

溝通方案涉及通訊錄，包括上下游系統(tǒng)、第三方單位、業(yè)務(wù)部門等渠道。

另外，有了應(yīng)急方案，如何讓運(yùn)維人員持續(xù)去更新是難點(diǎn)。我認(rèn)為要解決這個(gè)難點(diǎn)，需要先讓運(yùn)維人員經(jīng)常使用這個(gè)手冊。如果一個(gè)手冊沒有場景可以用，那就需要管理者為運(yùn)維人員創(chuàng)造機(jī)會去使用這個(gè)手冊，比如應(yīng)急演練。

持續(xù)優(yōu)化

1、整體思路

監(jiān)控系統(tǒng)建設(shè)目標(biāo)是完善“監(jiān)”能力，增加“控”的能力，這章提到的持續(xù)優(yōu)化主要是針對“監(jiān)”能力的落實(shí)，歸納起來就是“不漏報(bào)，少誤報(bào)”，可以針對不同的階段量化目標(biāo)，比如60%告警即故障，80%故障來自監(jiān)控。

2、措施

1）目標(biāo)分解

• 不漏報(bào)

漏報(bào)可以從兩個(gè)層面看，一個(gè)是監(jiān)控工具不具備某一方面的監(jiān)控能力；一個(gè)是監(jiān)控工具具備監(jiān)控能力，但因?yàn)槭褂谜呤褂脝栴}導(dǎo)致未覆蓋監(jiān)控。前者需要完善監(jiān)控能力，比如針對生產(chǎn)故障舉一反三式的優(yōu)化，或由不同專業(yè)條線主動增加監(jiān)控能力，后者則需要考慮幾個(gè)問題：

• 管理上有沒有要求指標(biāo)的100%覆蓋率；
• 覆蓋率的要求是否確實(shí)可以落地，或功能上是否設(shè)計(jì)極不友好；
• 100%的覆蓋率是否從技術(shù)默認(rèn)設(shè)置，如果技術(shù)無法默認(rèn)設(shè)置，能否從技術(shù)上主動發(fā)現(xiàn)；

前面兩個(gè)問題需要從管理手段上解決，最后一個(gè)問題需要在監(jiān)控系統(tǒng)中解決，即盡可能讓需要覆蓋的監(jiān)控指標(biāo)從技術(shù)上落地，減少對運(yùn)維人員主動性上的依靠，同時(shí)監(jiān)控系統(tǒng)要快速從技術(shù)上響應(yīng)新的監(jiān)控指標(biāo)的落地。

• 減少誤報(bào)

誤報(bào)帶來的問題也很大，大量、反復(fù)的誤報(bào)告警會讓運(yùn)維人員麻木，進(jìn)而忽視監(jiān)控報(bào)警，錯(cuò)過了真正的監(jiān)控事件的處理，所以監(jiān)控誤報(bào)情況也需要重視。

2）心得

以下是在監(jiān)控優(yōu)化上的一些措施心得供參考：

第一階段：減少監(jiān)控報(bào)警數(shù)量

目標(biāo)：每周報(bào)警總量上下降60%

主要工作：

• 抓突出的報(bào)警指標(biāo)，調(diào)整閥值，比如CPU、內(nèi)存、空間、應(yīng)用性能這幾塊大頭，如果閥值不合理將帶來大量告警，對這幾類指標(biāo)閥值做優(yōu)化會有事半功倍的效果；
• 抓每個(gè)指標(biāo)突出的組、系統(tǒng)進(jìn)行針對性整改，可能就是某個(gè)團(tuán)隊(duì)或某些管理員不重視監(jiān)控，解決刺頭的成效也很明顯；
• 針對重復(fù)性的告警，優(yōu)化監(jiān)控系統(tǒng)，減少重復(fù)報(bào)警。

第二階段：減少監(jiān)控誤報(bào)率

目標(biāo)：60%告警即故障（排除磁盤、表空間類）

主要工作：

• 區(qū)分監(jiān)控級別，告警即故障：分析確認(rèn)哪類監(jiān)控報(bào)警必須作為事件處理，并將交易量監(jiān)控設(shè)置為告警，非故障調(diào)整為預(yù)警；
• 所有預(yù)警即關(guān)聯(lián)工單，對預(yù)警工單閥值進(jìn)行分析調(diào)整；
• 優(yōu)化監(jiān)控短信內(nèi)容，提高短信對事件定位；
• 完成動態(tài)基線的監(jiān)控功能上線功能，提高監(jiān)控準(zhǔn)確率；
• 完成應(yīng)用部署與監(jiān)控維護(hù)期關(guān)聯(lián)，減少未設(shè)置維護(hù)期導(dǎo)致的監(jiān)控報(bào)警；
• 完成應(yīng)用啟停集中處理，減少應(yīng)用啟停帶來的維護(hù)期報(bào)警。

第三階段：提高監(jiān)控對故障的覆蓋率

目標(biāo)：80%故障來自監(jiān)控

主要工作：

• 每周分析生產(chǎn)事件的發(fā)現(xiàn)環(huán)節(jié)，對于非監(jiān)控發(fā)現(xiàn)的故障進(jìn)行專項(xiàng)分析；
• 其它方案（針對第一、二階段實(shí)施情況完善）

第四階段：提高監(jiān)控事件處理效率

目標(biāo)：監(jiān)控告警1小時(shí)內(nèi)關(guān)閉

主要工作：

• 對監(jiān)控報(bào)警耗時(shí)進(jìn)行分析，并通報(bào)
• 針對無法快速恢復(fù)的監(jiān)控報(bào)警優(yōu)化功能處理

其它方案（待定）

3、團(tuán)隊(duì)

因?yàn)橛谐掷m(xù)優(yōu)化的工作，所以最好能夠有一個(gè)橫向的監(jiān)控優(yōu)化團(tuán)隊(duì)，區(qū)分于監(jiān)控系統(tǒng)工具建設(shè)團(tuán)隊(duì)，作為監(jiān)控的使用角色，這個(gè)團(tuán)隊(duì)有幾個(gè)目標(biāo)：

將持續(xù)優(yōu)化的工作進(jìn)行落地；

作好數(shù)據(jù)分析，比如監(jiān)控的事件量是否突增，某些系統(tǒng)的事件是否陡增，誤報(bào)量是否過多，故障哪些不是通過監(jiān)控發(fā)現(xiàn)，未通過監(jiān)控發(fā)現(xiàn)的故障是否完成監(jiān)控覆蓋面整改，監(jiān)控功能有哪些不友好等等。