淺談可量化的數據中心監控服務及運營方法
經過十多年的建設和發展，不管是老的數據中心或者新建的數據中心，後期的運維管理方法及手段已經考慮的比較成熟，當然運維管理工具已經成爲必備的產品。說起數據中心運維，其中的理論、方案、方法和工具會有很多很多中說法，今天主要討論主動監控工具所面臨的問題，以及解決之道。
監控系統面臨的主要問題是告警量過多的問題，導致用戶認爲系統不可信，雖然這些告警都是用戶自己配置出來的，但是用戶渾然不知。第二個問題是監控系統如何使用，值班團隊如何進行考覈，讓物盡其用，人盡其才。第三個問題是如何量化監控服務，體現監控服務的價值。
關於告警過多的問題，基於我之前項目的經驗，引起告警量高的兩個主因是監控策略過多和監控範圍過細。解決方法主要是通過定向配置策略和限制重複告警兩種方法來優化告警，這樣使得嚴重告警信息的準確率提高到80%左右，但是對於預警類的信息還是比較多，因爲不可能把閾值定製到一個恰到好處的數值、也不能能完全限制住網絡中頻繁發生的trap信息（trap是網絡設備和各OS都會觸發的信息），當然對於大多產品還是可以通過限制性策略限制無效trap的接收。而這幾種手段需要長期性的系統維護來完成。
對於監控系統的考覈主要是看系統功能、設備類型的覆蓋率、監控頻率粒度和穩定性等指標。當然對於故障的準確率這一個指標大家覺得非常重要，如果考慮工具是運維團隊自身的工具後，這個指標的定義意義就不大了，看後面對於工具的持續優化說明，可能就比較好理解。準確率和運維團隊的態度和能力相關，根據我做過的衆多項目總結，運維團隊對監控工具的重視程度，直接影響這個數據。
業內對於監控團隊的考覈沒有明確的約定，主要還是長期運維的一個經驗總結，普遍認可監控服務考覈的主要指標在於響應時間，告警數量；告警數量主要是覈算工作量和成本，數量會成爲覈算服務的基數。我們在不同的生產環境中，設備的負荷、運營時間、環境和業務系統等是千差萬別的，出現故障的數量和時間是不確定的，比如在思科高端交換機較多的網絡中，負載也很低，網絡全年不會出現任何問題。但對於網絡建設年限比較舊，設備比較陳舊的網絡，出現故障的頻率就比較高了。
監控服務考覈指標主要定義是漏報率、誤報率和上報率（15分鐘內），前兩個指標是考覈團隊對監控系統的運營能力，在下面告警質量的問題裏講。不能因有監控系統後運維團隊就高枕無憂，運維團隊需要不停的優化和改進監控系統，同時在網絡、業務系統發生變更後，對監控持續的優化。第三個指標是考覈團隊的執行能力，有告警是必須及時分析上報的。這樣從整個團隊的工作態度和能力兩個緯度進行考覈。
監控服務價值統計主要是覈算服務的費用，這個是量化現代化服務的一個普遍觀點，不管是甲方還是乙方，數字說話是普遍認可的一個觀點，根據上面提到的以告警量做爲覈算成本的一個基數，再根據告警的嚴重等級和相關業務項的等級，進行加權計算，例如同樣嚴重等級的告警，對於不通等級的業務系統，發現該告警的的價值是不一樣的。再在以上幾個指標考慮的基礎上，增加響應時間的計算，基本上可以計算服務的價值量。計算公式爲（需要CMDB的支撐）：
M=p（w1*a1*b1*r1+w2*a2*b2*r2+……wn*an*bn*rn）+基本服務價格（驗證誤報、巡檢等工作）
基本價格服務包括：網元數量*單價；網元是網絡管理中可以監視和管理的最小單位，包括軟件、硬件和應用等服務。這裏就包括常規告警監控和性能報告等。
用以上兩種緯度計算，主要是從服務團隊的態度和能力兩個緯度進行激勵。
簡稱 | 字符描述 |
M（money） | 服務價值 |
w（work） | 告警項 |
a（alert） | 告警級別 |
b （business） | 業務系統級別 |
r（response） | 響應時間 |
p（price） | 基本價格 |
例如：
告警級別：業務系統級別：響應時間：
嚴重告警 | 1.5 | XX生產系統 | 1.5 | 5分鐘 | 1.5 | ||
高級告警 | 1.2 | OA系統 | 1.2 | 10分鐘 | 1.2 | ||
初級告警 | 1.0 | 公司門戶系統 | 1.0 | 15分鐘 | 1.0 | ||
警告告警 | 1.0 | XX測試系統 | 1.0 | 30分鐘 | 0.9 | ||
初級告警 | 0.8 | 內部論壇 | 0.8 | 60分鐘 | -1 |
在目前瞭解到的國內幾家互聯網公司中，數據中心運維的成熟度比較高，運維考覈主要從五個緯度考慮，即響應時間、準備度（預防機制）、處理態度與能力、處理結果和後續措施。前三個跟監控相關，及時上報體現響應時間；對監控工具持續優化、巡檢和演練等體現準備度和能力。
告警常見問題
1、監控存在侷限，存在監控盲點。規避方法：在網絡層、應用層、系統層建立監控策略，儘可能的掃除盲點。防止漏報。
2、告警延時，在產生告警到接受告警的過程中，系統會經過告警轉換接口，郵件或短信接口，容易出現排隊和阻塞。規避方法：拓寬渠道、減少擁塞，嚴重告警發送短信，其他預警類告警發送郵件或頁面顯示等。防止漏報。
3、告警質量問題。提升監控策略和質量在運維過程中會一直延續。規避方法：核心思想是運營，通過規劃和統籌能力，既要全局規劃告警分類、告警模型、告警策略，還要持續按業務和人的告警數量、告警分佈持續優化。防止誤報
告警模型
1、告警分類，便於建立告警模型、方便歸納和分析定位外，最重要的是有一個完整、系統的故障檢測、告警響應機制。
2、告警模型，具備一定規則的預處理程序，比如定義一個閾值或多維度的組合條件。例如連續多次超過某個閾值後，產生告警，可以避免性能瞬時高而產生的告警。
告警優化
1、按照頻率收斂告警，按照頻率和次數設計告警策略
2、根據責任人、設備類型或時間來收斂告警、合併告警。
3、告警關聯，讓有相關關係的模塊之間不要產生重複告警。（在一些互聯網中心的自開發系統中有這樣的功能）
4、告警分析，還是主要是講運營過程中對告警的持續性分析，跟蹤，優化策略，使得告警數量保持在一個合理範圍。