分散式監控在三七互娛的應用與實踐

背景前言

監控系統是整個業務系統中至關重要的一環，它就像眼睛一樣，時刻監測機房、網路、伺服器、應用等運行情況，並且在出現問題時能夠及時做出相應處理。

在37監控的發展史，主要經歷以下幾個階段：

37當時主要使用的是Zabbix、DBA天兔等監控系統，隨著各業務線的發展，監控項越來越多，各種監控系統的問題也越來越突出，已經無法快速的支持業務的發展。

這裡整理了下我們主要用到的Zabbix核心問題如下：

1 性能：不支持擴展，本身是一個單點, 當機器規模超過萬台的時候會出現很明顯的性能問題(核心監控數據存儲用了MySQL)。

2 功能：深度二次開發改造難度比較大，不支持定製化功能。我們的目標要完全接入OPS，實現運維一體化。

3 體驗：配置比較複雜，學習成本較高。對外提供的API不夠豐富，很難與其他業務系統集成。

這個時候我們急於尋找一個替代的解決方案，經過篩選後，最終選擇引進最初由小米開源的Open-Falcon監控系統。

Falcon的官方連接：http://open-falcon.com/

問題分析

Open-Falcon當前存在的主要問題如下：

1. Falcon本身一套自己的CMDB(機器信息管理)，沒有與當前的運維平台體系的CMDB聯動，導致的核心問題：機器信息不一致，降低監控的準確性。

2. 國內海外Agent跨地域數據採集、傳輸，網路延遲，導致經常性誤報。

3. 核心策略模塊單點(Transfer->Judge->Alarm->Sender)，模塊掛掉會導致報警策略失效。

4. 國內、海外監控數據時區不一致等問題。

Falcon架構優化前後對比

官方架構圖：

37-FALCON架構圖：

前後架構主要變化:

1. 報警策略模塊分散式鎖高可用改造（Judge、Alarm模塊）

2. 海外數據傳輸，開發failover策略、引入專線提高Qos，保證網路傳輸可靠性。

3. WEB重構，Agent自關聯CMDB，統一運維平台體系

4. ...

下面本文將為大家詳細介紹37-Falcon在原來Open-Falcon的基礎上做出的一些改進。

二次改造：Agent改造，自動關聯CMDB

背景：

1. 當前CMDB的機器的唯一屬性SN，所以監控系統要和CMDB各個子系統打通，必須要推送SN信息。如果監控有獨立的機器資源數據，就會導致監控的機器、域名、網路設置等資源不準確，無法統一數據源，最終導致的結果就是監控數據不準確，運維成本居高不下。（存在多套CMDB）

2. 這個問題是所有監控系統存在的問題，必須經過二次開發與運維CMDB進行無縫結合，才能做到真正的運維平台體系的監控系統。

方案：

1. Agent在啟動過程中，自動從CMDB的介面中獲取SN。（這個過程一般在機器初始化的時候，已經完成Agent自動安裝，完成了自動關聯）

2. CMDB的服務樹元數據信息，定時與監控CMDB同步。（或者可以統一CMDB，這裡定時同步是為了減少CMDB的開發成本）

實現：

宏觀圖：

核心流程：

PS: 通過使用sn的cache file，來避免網路問題導致獲取SN失敗，導致數據採集失敗。(因為SN是機器的唯一屬性，非特殊情況不會輕易改變)

效果1 - 自關聯CMDB

效果2 - 監控自動化覆蓋

Agent數據傳輸優化

Agent轉發transfer/gateway的機器列表，通過ICMP延遲和埠連通性來進行排序，就近訪問，減少網路延遲，提高發送性能。（海外提升比較明顯）背景：海外Agent數據通過一系列流程最終落地到國內進行存儲，在經過國際線路的時候，經常會出現丟包的情況，導致發生誤報。

分析：1. 自動選擇延遲低的Transfer，分地區智能DNS。（主要是通過訪問CMDB獲取就近的代理，加入failover機制）

2. 引入海外專線，不丟包。

3. 優化Agent連接Transfer，rpc的超時時間，避免大並發下網路進行堵塞。（如果是高版本的，官方已經進行了優化，具體見：https://github.com/open-falcon/falcon-plus/issues/290）

實現：

優化思路整體展示

Agent->Gateway智能DNS,引入failover機制：

rpc timeout超時調優：

網路專線架構：

專線核心優勢：

1. 國際鏈路的丟包率平均70%降低至0。

2. 由於監控數據所需要的帶寬佔比小，現在4M基本足夠。（雙鏈路冗餘）

Judge,Alarm策略模塊單點改造

背景:Judge模塊是單點，如果掛掉則導致報警策略流失效。Judge模塊可以進行哈希分庫，但是每一個分庫都是單點。

架構：

架構解析：

核心的原理是通過REDIS的SETNX來設置KEY的過期時間，由於REDIS是單線程的，可以通過REDIS設置簡單的分散式鎖來達到模塊之間的高可用。(這裡要注意死鎖的問題處理)

1. 同一個分庫的兩台(或者多台)Judge，有一台提供服務搶佔分散式鎖，觸發策略插入REDIS。

2. Alarm去拉取Judge插入的策略數據之後，Alarm可以通過獲取鎖來進行服務，做到Alarm模塊高可用。

3. Transfer發送Judge的時候，需要進行雙寫高可用改造，默認版本是沒有使用Cluster模式發送。（和發送Graph模塊邏輯不一致。）

PS:

1. Judge目前線上只有01庫。（如果後面因為性能問題，橫向擴容的時候，可以橫向擴容02,03庫等等）

Transfer改造：跨時區監控數據時間優化

背景：

Agent分布在全世界，時區不一致，監控採集的時間默認都使用當地時間，所以推送給Transfer，並且後續推送到Judge-Alarm報警，報警時間會比較詭異！第二點就是數據進入Graph存儲之後，趨勢圖查看的時候也不符合在國內時區表現。

思路：

更改Transfer接收時間的邏輯，如果報警時間不合理（優雅處理），直接將報警時間更改為當前時間。

query改造：查詢Graph高可用改造

問題：

由於Query調用Graph介面採用哈希分庫的方式，但是每一個庫只支持一個地址，導致的問題如下：

1. 部分機器宕機的情況下，Nodata模塊調用query查詢agent.alive數據的時候，查詢失敗。導致機器宕機無法報警。

2. 所有通過Query模塊查詢Graph數據，到可能導致失敗。（前端趨勢圖數據無法查詢）

優化：

每個分庫，支持多個IP自動冗餘（因為graph現在每個分庫多有兩份一樣的數據，參考transfer的配置。

總結

1. 這個項目難點，並不在於技術問題，最主要是要推翻各個監控系統，統一監控平台。

2. 使用開源的系統我們需要進行深挖，推敲每一處代碼，才能夠真正的掌握這個系統，線上從此無懼風險，從而為業務更好的服務。

喜歡這篇文章嗎？感謝看官們打賞關注走一波。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！