《監(jiān)控體系建設（完整）》要點：
本文介紹了監(jiān)控體系建設（完整），希望對您有用。如果有疑問，可以聯(lián)系我們。

近年來,隨著計算機技術的飛速發(fā)展,以及行業(yè)信息的共享,傳統(tǒng)企業(yè)的運維己不再是固步自封,日新月異的計算技術的發(fā)展推動企業(yè)云平臺的建設,云平臺的計算能力為大數(shù)據(jù)分析提供了基礎、云平臺與大數(shù)據(jù)分析又將推動運維人工智能的發(fā)展.放眼云、大數(shù)據(jù)、人工智能的運維發(fā)展方向的同時,作為運維的生命線,安全生產(chǎn)保障的生命線仍需強調(diào).作為傳統(tǒng)企業(yè)的安全生產(chǎn)保障,主要以“監(jiān)”、“管”、“控”為核心,其中“監(jiān)”則主要指的的監(jiān)控.

一、監(jiān)控體系分層

1、概述：

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

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

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

3)各專業(yè)條線對各條線的監(jiān)控負責：各專業(yè)條線是最清楚自己需要什么監(jiān)控的團隊,各專業(yè)條線對監(jiān)控覆蓋率負責,監(jiān)控平臺的建設方負責平臺體系的建設,提供基礎技術支撐.

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

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

2、分層方式：

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

?1)基礎設施層：包括運營商專線、機房(機房內(nèi)的設施,比如制冷、安防等)、網(wǎng)絡設備,基礎設施層的監(jiān)控分為狀態(tài)、性能、質(zhì)量、容量、架構、流量分析等幾個層面.

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

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

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

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

3、各層職責

1)基礎設施

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

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

2)服務器層

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

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

3)系統(tǒng)服務層：

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

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

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

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

4)應用服務層

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

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

5)客戶體驗層

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

二、監(jiān)控整合

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

在監(jiān)控整合上,主要從事件匯總、統(tǒng)一可視化、監(jiān)控數(shù)據(jù)匯總3方面進行梳理.

1、事件匯總

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

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

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

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

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

• 事件匯總：匯總不同層次、不同專業(yè)條線、不同類型事件是監(jiān)控集中管理的基礎.
• 事件收斂：前面提到同一個故障會觸發(fā)多類指標的告警,同一個指標在故障未解除前也會重復產(chǎn)生大量的告警事件,如果將全部事件都展示出來,那對于監(jiān)控處理人員將是災難性的,所以需要進行事件收斂(關于收斂的思路可以見公眾號另一篇關于事件收斂的文章)
• ?事件分級：對于不同的事件需要有適當層次的事件分級,事件升級的策略.事件分級是將事件當前緊急程度進行標識顯示,事件升級是對于低級的事件當達到一定的程度,比如處理時間過長,則需要進行升級.
• ?事件分析：事件分析是建立事件的關聯(lián)關系,關聯(lián)分析可以從縱向和橫向關系進行分析,縱向是指從底層的基礎設施、網(wǎng)絡、服務器硬件、虛擬機/容器、操作系統(tǒng)、中間件、應用域、應用、交易；橫向是指從當前的應用節(jié)點、上游服務器節(jié)點、下游服務器節(jié)點的交易關系.事件分析是形成故障樹,自愈的基礎.對于事件分析重點在于關系模型的建立,互聯(lián)網(wǎng)公司有不少標準化的方案,但我個人認為需要開發(fā)團隊介入改造的標準化不可控,所以另外一方向是針對企業(yè)內(nèi)部特點,以CMDB、應用配置庫為中心,或以節(jié)點型的系統(tǒng)為中心去建立關系模型,具體介紹見第三章.
• 高性能：為了實現(xiàn)實時監(jiān)控,需要事件匯總模塊具備高性能.
• 對外提供采集事件數(shù)據(jù)接口：監(jiān)控作為一體化運維體系的一部份,需要對外提供服務化接口,支持事件數(shù)據(jù)的采集.

2、統(tǒng)一可視化

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

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

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

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

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

3、數(shù)據(jù)整合標準

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

1)報文解釋：

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

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

2)日志結構標準：

日志結構標準,主要分兩類,一類是直接建一個日志分析平臺,比如國外的splunk、國內(nèi)的日志易,或者開源的ELK(日志易也是用了ELK);另一類是重構日志標準組件,比如重構java企業(yè)應用中經(jīng)常使用的log4j開源包的標準輸出方法,對日志結構進行整合,并通過異步消息的方式將日志發(fā)送給監(jiān)控平臺,再提供可視化的IDE對不同系統(tǒng)的日格式進行進一步整理,將需要的數(shù)據(jù)抽取整合.

3)數(shù)據(jù)庫流水標準：

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

4)其它思路：

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

三、監(jiān)控指標

如前一章提到,監(jiān)控有賴于運維各專業(yè)條線協(xié)同完善,通過將監(jiān)控體系進行分層、分類,各專業(yè)條線再去有重點的豐富監(jiān)控指標.

1、指標分類

1)基礎設施層：

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

??? 網(wǎng)絡設備：路由器、二三層網(wǎng)絡交換機、多層交換機、負載均衡設備等

??? 安全設備：防火墻、入侵檢測、防病毒、加密機等

2)服務器層：

??? 虛擬化：虛擬網(wǎng)絡資源、虛擬主機、虛擬存儲資源等

??? 存儲設備：磁盤陣列、虛擬帶庫、物理磁帶庫、SAN、NAS等

??? 服務器：大中小型機、X86服務器

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)應用服務層：

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

??? 應用交易：交易整體情況、應用性能(重要交易或整個節(jié)點的交易量、耗時、成功率、響應率)、開業(yè)情況、批量交易狀態(tài)等

5)客戶體驗層：

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

具體的監(jiān)控指標內(nèi)容與閥值參考的明細不同的行業(yè),不同的系統(tǒng)會有不同的認識,這里不細列.

2、指標權重與閥值分級

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

1)指標權重：

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

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

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

對于升級,是指一個預警當長時間未處理時,需要有一個上升機制,轉化為告警,以督辦運維人員完成監(jiān)控事件的處理.

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

3、指標基線

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

1)基線的自我學習：

前面己提到指標的基線是動態(tài)的,基線動態(tài)就需要對系統(tǒng)運行的情況按一個指定的時間間隔粒度進行學習,理論上運行學習的時間越長,基線越準確(但如果業(yè)務做了推廣,歷史的基線數(shù)據(jù)則需要降低權重).

2)基線指標的組合：

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

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

3)性能：

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

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

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

另外,人工智能這么火,也提一點通過機器學習來實現(xiàn)監(jiān)控基線的思路(思路還不成熟,僅供參考)：

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

四、監(jiān)控事件

1、監(jiān)控事件：

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

前面提到了事件整合,下面主要講講事件關聯(lián)、事件應急、事件分析、智能處理方面的建設思路.

2、事件標準

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

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

靜態(tài)豐富信息包含描述豐富信息、拓撲豐富信息,描述豐富信息主要包含相關人員描述信息、服務器描述信息、工單信息等,這塊豐富數(shù)據(jù)可以通過CMDB消費獲取,這部份豐富數(shù)據(jù)有助于事件處理過程中關聯(lián)分析.事件現(xiàn)場信息包含指標信息、性能信息、系統(tǒng)資源信息等,這部份信息主要是反映事件的現(xiàn)場數(shù)據(jù).知識庫信息主要指相似歷史事件及其處理方式等信息,比如“建議如何做,己自動進行了什么動作”等.關聯(lián)信息主要包含從屬事件信息、關聯(lián)影響信息.

2)事件分級標準

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

??? 通知：指一般的通知信息類事件.

??? 預警：指已經(jīng)出現(xiàn)異常,即將要引起生產(chǎn)故障的事件.

??? 故障：指已經(jīng)發(fā)生問題,并且已經(jīng)影響到生產(chǎn)流程的事件,如果需要進一步細化故障級別,可以分為一般故障和緊急故障：一般故障不需要緊急處理的故障,緊急故障需要管理員緊急處理的故障.

事件細分的粒度需根據(jù)各企業(yè)團隊的管理要求而定.

2、事件關聯(lián)：

1)事件壓縮及收斂

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

有了事件壓縮還不夠,因為觸發(fā)事件的指標往往是相互關聯(lián)的,這就需要對多項指標關系進行分析,減少相同問題產(chǎn)生的事件.比如這個應用場景：

-NAS監(jiān)控：NAS文件系統(tǒng)在各OS上都會有監(jiān)控,一個NAS文件系統(tǒng)出問題時,每個服務器的NAS文件系統(tǒng)監(jiān)控都會報警.如能對NAS進行掛載關系梳理,同一NAS的報警可以大量收斂.

-進程、端口、通訊檢測：一個進程宕掉時,該進程啟動的端口、關聯(lián)系統(tǒng)與改進程端口的通訊等都會同時報警.如能對進程、端口、通訊關系進行梳理,同一個進程引發(fā)的進程、端口、通訊監(jiān)控事件也能收斂明顯.

2)事件豐富

事件豐富包括事件描述豐富(通過CMDB豐富、拓撲豐富)、事件現(xiàn)場豐富(指標信息豐富、APM信息豐富、系統(tǒng)資源信息豐富)、知識庫豐富,提高運維人員分析問題的能力.事件主要豐富方法如下：

-與第三方監(jiān)控系統(tǒng)對接,獲取事件相關信息進行豐富.如與CMDB系統(tǒng)對接,獲取服務器等相關配置信息進行CMDB數(shù)據(jù)豐富；

-根據(jù)拓撲關系模型,進行拓撲豐富；

-指標信息豐富：獲取事件發(fā)生前后一段時間內(nèi)的相關指標信息數(shù)據(jù)(如CPU/內(nèi)存等),進行指標信息豐富；

-相關事件豐富：根據(jù)拓撲關系模型、應用關系關聯(lián)模型、交易流行關聯(lián)模型將相近事件時間范圍內(nèi)的事件進行豐富展示；

-知識庫豐富：建立事件處理方案知識庫,記錄事件處理的方法和流程,為事件處理人提供參考依據(jù),以及為后續(xù)自動化運維提供理論支撐.

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

???? 事件涉及的軟硬件的基本配置信息、人員信息,這一塊是基本CMDB的數(shù)據(jù)消費；

???? 事件報警的主體信息,包括時間、事件描述、事件可能原因、事件處理情況等；

???? 事件應急處理及流程工單鏈接；

???? 事件主體信息的具體指標數(shù)據(jù)展示,以及指標變化趨勢；

???? 最近30分鐘的事件情況,以備分析是否受其它事件關聯(lián)影響；

???? 該事件所在OS的CPU、內(nèi)存、IO的信息；

???? 事件涉及的性能信息,比如交易量、成功率、交易耗時；

???? 事件處理進展

3)事件擴散

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

縱向關系：

橫向關系：

4)事件觸發(fā)

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

??? 閾值觸發(fā)

系統(tǒng)支持指標的閾值觸發(fā)設置,當指標值達到設置的閾值時即可進行報警.

-閾值的設置范圍只能在該指標的數(shù)值范圍內(nèi)進行設置.

–?閾值在設置時需要指定數(shù)值單位,防止數(shù)值因單位不同出現(xiàn)判斷錯誤.

–?在設置閾值時系統(tǒng)支持實時查看指標當日折現(xiàn)圖和歷史基線,幫助運維人員正確判斷閾值的設置范圍.

????基線觸發(fā)

系統(tǒng)支持指標的基線觸發(fā)設置,當指標值達到設置的基線時即可進行報警.

-基線設置可按照昨日基線、月基線、周基線進行設置.

-系統(tǒng)支持在選定的基線基礎上進行上浮或下沉幅度的設置.

-在設置基線時系統(tǒng)支持實時查看指標當日折現(xiàn)圖和歷史基線,幫助運維人員正確判斷基線的設置范圍.

-系統(tǒng)支持按照平均基線進行設置.

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

????智能預測

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

3、事件應急

1)應急恢復

運維最基本的指標就是系統(tǒng)可用性,應急恢復的時效性是系統(tǒng)可用性的關鍵指標.通常來講應急恢復的方法有不少,比如：

???服務整體性能下降或異常,可以考慮重啟服務；

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

???資源不足,可以考慮應急擴容；

???應用性能問題,可以考慮調(diào)整應用參數(shù)、日志參數(shù)；

???數(shù)據(jù)庫繁忙,可以考慮通過數(shù)據(jù)庫快照分析,優(yōu)化SQL；

???應用功能設計有誤,可以考慮緊急關閉功能菜單；

???還有很多……

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

2)現(xiàn)場保護

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

3)問題排查

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

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

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

???是否進行過相關變更

大部份故障是由于變更導致,確定故障現(xiàn)象后,如果有應的變更,有助于從變更角度出現(xiàn)分析是否是變更引起,進而快速定位故障并準備好回切等應急方案.

???是否可縮小范圍

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

???關聯(lián)方配合分析問題

與第(3)點避免同時各關聯(lián)團隊同時無頭緒的排查的同時,對于牽頭方在縮小范圍后需要開放的態(tài)度去請求關聯(lián)方配合定位,而對于關聯(lián)方則需要有積極配合的工作態(tài)度.

???是否有足夠的日志

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

???是否有core或dump等文件

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

4)應急文檔

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

(1)系統(tǒng)級：

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

(2)服務級：

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

(3)交易級：

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

(4)溝通方案：

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

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

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

1、整體思路

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

2、措施

1)目標分解：

??? 不漏報

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

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

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

-100%的覆蓋率是否從技術默認設置,如果技術無法默認設置,能否從技術上主動發(fā)現(xiàn)

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

??? 減少誤報

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

2)心得：

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

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

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

主要工作：

??? 抓突出的報警指標,調(diào)整閥值,比如CPU、內(nèi)存、空間、應用性能這幾塊大頭,如果閥值不合理將帶來大量告警,對這幾類指標閥值做優(yōu)化會有事半功倍的效果；

??? 抓每個指標突出的組、系統(tǒng)進行針對性整改,可能就是某個團隊或某些管理員不重視監(jiān)控,解決刺頭的成效也很明顯；

??? 針對重復性的告警,優(yōu)化監(jiān)控系統(tǒng),減少重復報警；

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

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

主要工作：

??? 區(qū)分監(jiān)控級別,告警即故障：分析確認哪類監(jiān)控報警必須作為事件處理,并將交易量監(jiān)控設置為告警,非故障調(diào)整為預警；

??? 所有預警即關聯(lián)工單,對預警工單閥值進行分析調(diào)整；

??? 優(yōu)化監(jiān)控短信內(nèi)容,提高短信對事件定位；

??? 完成動態(tài)基線的監(jiān)控功能上線功能,提高監(jiān)控準確率；

??? 完成應用部署與監(jiān)控維護期關聯(lián),減少未設置維護期導致的監(jiān)控報警；

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

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

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

主要工作：

??? 每周分析生產(chǎn)事件的發(fā)現(xiàn)環(huán)節(jié),對于非監(jiān)控發(fā)現(xiàn)的故障進行專項分析；

??? 其它方案(針對第一、二階段實施情況完善)

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

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

主要工作：

??? 對監(jiān)控報警耗時進行分析,并通報；

??? 針對無法快速恢復的監(jiān)控報警優(yōu)化功能處理；

??? 其它方案(待定)

3、團隊

因為有持續(xù)優(yōu)化的工作,所以最好能夠有一個橫向的監(jiān)控優(yōu)化團隊,區(qū)分于監(jiān)控系統(tǒng)工具建設團隊,作為監(jiān)控的使用角色,這個團隊有幾個目標：

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

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

整理的內(nèi)容有點長,有點羅嗦,稍整理了整篇總結的思維導圖：

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

轉載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4202.html