監控與事件管理

基礎要點

定義：對服務或配置項（CI）有重要意義的狀態變更。

目標：建立適當的響應機制，通過主動或被動的自動化監控，記錄狀態變更，確定事件的優先級，啟動控制操作，最小化或消除其對業務的負面影響。

信息性事件：不需要采取行動，但要分析、收集數據，發現對服務有益的操作。

警告：在業務實際發生負面影響之前采取行動。

異常：確定違反已建立的規范，即使未影響業務也要采取措施。

應使用工具輪詢關鍵CI，但要控制整體的數據量。

應通過合同，規定第三方應予以配合，并提供監控的數據。

解讀

就各種服務的日常監控而言，我們默認需要對系統、網絡與應用三大方面開展各類事件的監控活動。通常，業界會采取如下三種模式：

對于實力雄厚的企業而言，他們會自行研發各種針對某些具體目標的監控軟件。這些軟件雖然會在界面或功能上較為粗糙，但是能夠針對痛點且實用有效。

對于開放務實的企業而言，他們會通過采用開源社區的工具，來不斷完善與豐富監控的項目與工具。此類工具雖能持續迭代，但難免會存在潛在的缺陷。

對于嚴謹合規的企業而言，他們會購置成熟的商業版監控服務，并利用第三方廠商所提供的豐富的API 接口，通過雙方技術人員的協作，實現與現有企業系統的二次開發與集成。此類監控產品通常擁有友好的界面、完整的流程以及周到的技術支持。

在實現了監控服務的搭建之后，IT 技術人員需要針對當前系統與服務的實際情況，設置好監控項、參照基準以及門限閥值。

為了有效地實現事件的分類、分級以及剔除誤報，我們應當事先對于在監控過程中捕捉到的事件信息，根據其重要程度來進行如下區分：

1.信息性事件

例如，某個用戶登錄了人事管理系統，郵件系統向內部群發了一封郵件，物流系統的全量數據備份已完成等事件。

2.警告

例如，Web 服務器的CPU使用率接近設定閾值，網站大促時用戶的訪問量接近系統設定的穩定性能拐點等。

圖1 事件管理流程

3.異常

例如，上述Web 服務器的CPU 使用率已經超過了設定閾值，需要立即給虛擬機增加CPU。

由于各類事件都是從自動化監控中捕獲而來，因此我們在系統的響應能力方面，需要能夠達到如下“兩個快”。

快速生成：由于是系統自動化監控所產生，因此事件應迅速實現分配編號；初步判斷類型；過濾重復與無效；根據標準分級自動關聯處理措施以及分派給相應的角色，這樣既節省了時間，又提高了準確性。

快速處置：系統除了能夠根據現有的“問題和已知錯誤知識庫”以及CMDB，進行事件的自動匹配與流轉之外，還應當設定一些預定義的處理路徑、并能準確地讀取組織內不同的IT 角色信息，以實現多部門按需聯動，此外，系統也應該為重要事件自動設置倒計時，以及截止時間，以方便后期對處置的KPI 進行評估。

實務

在自動監控方面，我們通過開源軟件——Zabbix 的自動化注冊與發現特性實現了：

1.機房環境、物理設備、網絡流量、虛擬化、數據庫、業務應用、存儲狀態、備份作業以及日志等方面的實時自動化巡檢。

2.通過自動發現和現場核對，分層、分級整理出了2D版的機房拓撲圖、3D 版的機架視圖、地域鏈路實時圖、網絡架構圖、系統邏輯框架圖、應用間數據流轉圖、流量歷史曲線圖以及各類應用的儀表盤。

自動跟蹤監測項目包括：標準的CPU、內存、磁盤、I/O，以及定制化服務（如Nginx、PHP 頁面等）的KPI 性能。

對于監控到的事件，系統能夠自動區分事件的來源，分配事件編號，區分類別，通知人員，以及跟蹤處理狀態。

同時，在運維人員的二次審驗方面，他們只需通過進一步點擊，便可細致地觀察與獲悉到每個服務的詳細狀態，進而迅速開展各種人工分析以及異常跟蹤與診斷。

另外，對于那些自動化監控管理流程無法解決或是簡單人工干預無法糾正的事件，我們會根據前面提到的IT 資產的分類標準，依次轉入事故管理、變更管理，以及馬上要討論到的問題管理流程。

總的說來，我們在實際操作中，參考了如圖1 所示的事件管理流程。