運維監控如何做成 BATJ 的水準

導讀	我們知道監控系統的目標是：為保障業務 SLA，幫忙我們更全面、細緻的瞭解業務系統的執行狀態，更及時的發現系統風險，同時給技術運營的同學爭取更多化解風險的時間和解決問題的方向。

我們知道監控系統的目標是：為保障業務 SLA，幫忙我們更全面、細緻的瞭解業務系統的執行狀態，更及時的發現系統風險，同時給技術運營的同學爭取更多化解風險的時間和解決問題的方向。

為此有使用開源監控系統（例如 Nagios、Zabbix、Prometheus、Grafana等），也有為了滿足自己的業務需求，會使用自己開發的監控系統（例如小米的open falcon，騰訊內部的監控系統 tnm2【基礎監控】、cms【日誌監控】等）。

隨著業務系統對監控系統的依賴，我們對監控系統的高可用性、擴充套件性等能力都會有更高的要求，那我們應該如何來全面的、系統的看待和提高自身監控系統的要求呢？

如何進行全面、系統的進行看待監控系統的要求，有很多辦法，遇到問題的時候對照一些頂級公司的優秀監控系統，找出提升點。

也可以對照由 中國資訊通訊研究院牽頭 及 BATJ 等各大網際網路巨頭參與的專家《研發運營一體化（DevOps）能力成熟度模型》中關於 “監控管理” 能力評估內容，根據標準的評估內容我們可以看到 BATJ 公司是如何定義一個先進的監控系統的能力，下面我們來一起看看：

我們發現整個關於“監控管理”的能力項分成三個能力項，分別是“監控採集”、“資料管理” 和 “資料應用” 三個，能力項內又包括了相關的子能力項，我摘取一些我自己覺得很有代表性的點來進行分析：

1.能力點：“支援提供開放式、自定義的資料內容採集上報方案”

疑問：為什麼需要對上報方案有要求呢？

解讀：比如騰訊內部的自研日誌監控系統CMS，對擁有多種採集方案“Agent、SDK、Kafka、ES等”，各種不同的採集方案應對不同的場景

Agent：類似filebeat，指定伺服器的具體路徑，對檔案的inode節點進行偵聽，發現新增立即進行上報資料；

SDK：可以嵌入到業務程式碼邏輯裡面，應對一些敏感資料不落地但是又需要上報的場景，可以在業務邏輯中對敏感資料進行脫敏（染色），然後再進行上報，也可以應對一些日誌量太大，不想經過日誌落盤這個中間消耗效能環節的場景；

例如：金融交易場景，要對交易資料做監控，但是又有一些敏感資料不想進入監控系統，這個時候就需要使用SDK在產生日誌的時候進行脫敏，將使用者資訊隱藏掉，再上報到監控系統內部；

Kafka：可以應對一份日誌多份消費者的場景，可以讓業務將日誌放入Kafka後，多個消費者進行自行提取即可；

例如：還是金融交易場景，一份日誌可以做安全審計，同時也可以做監控系統，這時候就可以安全審計系統和監控系統同時拉取一份Kafka的主題資料，不用列印多份；

2.能力點：“支援多種傳輸方案 ，如同時具備推與拉資料”

疑問：為什麼需要具備推與拉資料呢？具備一種不可以嗎？

解讀：正常的監控系統一般都是採用拉資料的方案，因為由伺服器端發起，順序和過程可控，但是為什麼需要拉資料呢？

原因是在幾種場景下需要這種能力：網路限制，當出現網路限制時，如安全等保中規定，高安全等級區域可以發起對低安全等級區域的連結，反之則不可以，所以需要從高安全等級區域推送資料至監控服務；效能要求，如同 Zabbix 的 active模式 和 passive模式；服務特性，部分服務並麼有對外提供請求介面，則需要內部邏輯對外進行主動 Push 監控資料。為了保證對業務系統和流程全面的監控，我們需要有多種能力的滿足；

例如：某個業務中有個定時任務將離線資料統計並更新至資料庫，該定時任務並無任何請求訪問介面，我們如何能監控它的執行狀態呢？可以在定時任務邏輯內部加入一個心跳機制，定期向監控系統push自身的監控狀況，所以推的傳輸能力也是監控必不可少的；

1.能力點：“具備對原始資料進行規則化處理的能力”

疑問：為什麼在接收資料的時候需要有規則化的處理呢，落地之後進行規則化處理不行嗎？

解讀：基於效能高效及資料完整性的考慮，需要在接收過程具備這個能力，我們還是以騰訊自研日誌監控系統為例，當我們接收大量的日誌Agent上報的時候，可能日誌不一定是按照我們的規則進行上報，如果一旦有日誌格式錯誤，會導致大量的入庫資料異常，還會導致資料汙染，這個時候需要一個規則化處理的能力，將不滿足規則的資料進行清洗。同時如果大量的日誌異常，落地之後進行清洗和處理將會消耗大量的算力，對於後來也是很大的壓力，所以具備這個能力是非常有必要的。
2.能力點：“對異構資料來源的關聯分析處理能力”

疑問：異構資料來源關聯分析處理能力具體是指什麼？

解讀：異構資料來源廣義上是指“資料結構、存取方式、形式不一樣的多個資料來源”，我們還是以騰訊內部的 自研日誌監控系統CMS 為例，當 某個服務上報日誌裡面有 源IP地址 和 業務關鍵資料，我們簡單排重和排序就可以知道哪個源IP地址訪問最多，但是如果我們想知道某個城市、省份、甚至是運營商（電信、移動、聯通），那就需要這個關聯分析能力，我們知道有一種資料是IP地址對應城市、省份 和 運營商（由於不斷在更新，所以需要獨立維護），通過這個資料和日誌資料一關聯就可以清楚地看到我們要的結果；

3.能力點：“具備資料一致性、完整性和可用性等管理特性”

疑問：資料一致性、完整性和可用性好理解，但是管理特性是什麼？

解讀：我們還是以騰訊內部的 自研日誌監控系統CMS 為例，日誌監控系統是由使用者資料上報、資料格式化、處理、聚合（統計、維度分析）、入庫/投遞、寫入時序資料庫等多個環節組成，當使用者看到最終結果異常如何能快速知道哪裡出了問題呢？這個就需要有相關的管理特性來實現了，在每個環節都增加自監控的能力，清晰看到資料流和曲線圖，可以快速發現異常點；

1.能力點：“具備告警風暴管控的能力， 如抑制、收斂等”

疑問：告警收斂能力常用的方式都有哪些呢？

解讀：一般在告警收斂中常用的規則有“基於時間收斂”、“基於事件收斂” 和 “基於級別收斂”等，根據不同的業務需求可以有不同的收斂方式。基於時間是最常用的，Nagios 和 Zabbix 的基礎配置。基於事件，一般是需要有主動和被動呼叫關係的告警，比如Zabbix 的 trigger-Dependencies 的功能。基於級別的收斂更是在開源和自研的系統中被使用。

如何看待和提高監控系統的能力，不管是參照開源監控系統對比學習，還是從《研發運營一體化（DevOps）能力成熟度模型》中對比學習，都是一個不錯的方向，當然裡面的知識點是集合了多數大牛的智慧結晶，本文只是摘取了少量的點進行解讀。

原文來自：  https://www.linuxprobe.com/monitor-batj.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69955379/viewspace-2685656/，如需轉載，請註明出處，否則將追究法律責任。