Zenlayer如何將萬臺裝置監控從Zabbix遷移到Flashcat

SRETalk發表於2024-03-18

作為全球首家以超連線為核心的雲服務商，Zenlayer 致力於將雲端計算、內容服務和邊緣技術融合，為客戶提供全面的解決方案。透過構建可靠的網路架構和高效的資料傳輸，Zenlayer 幫助客戶實現更快速、更可靠的連線，提升使用者體驗和業務效率。Zenlayer 在全球範圍內運營著超過 290 個邊緣節點， 骨幹網頻寬超過 50Tbps， 10000+ 的資料中心接入點，快速連線全球公有云與資料中心。

Zenlayer

監控現狀

Zenlayer 運營著全球數百個邊緣機房和龐大的骨幹網網路，我們的監控目標主要包括：

  1. 各種硬體裝置，如交換機、裸金屬
  2. 超大大規模網路的連通性和質量
  3. Kubernetes 雲原生技術棧

在 Zenlayer，監控系統不僅僅是作為一個內部工具服務於運維和研發團隊，我們的售後團隊高度依賴監控系統為客戶提供高水平的技術支援服務，監控系統是 Zenlayer 最重要的基礎服務和產品之一，是我們交付使用者價值的關鍵所在。

目前我們使用的監控工具有：Zabbix、Prometheus、夜鶯 Nightingale、ClickHouse：

  • 採用 Zabbix 監控各種網路裝置，將全球各個邊緣節點的監控資料，匯聚到中心統一處理。
  • 採用 Prometheus 收集 Zenlayer 的雲原生技術棧的監控資料，統一使用夜鶯 Nightingale 來配置和管理告警規則。
  • 使用 ClickHouse 對系統日誌進行分析。

痛點和挑戰

考慮到 Zenlayer 的裝置數量（近萬臺網路裝置）、裝置種類、全球化佈局，Zabbix 逐漸接近效能瓶頸：

  1. 海量資料的查詢、看圖、報警，對 Zabbix 資料庫有很大的寫入和查詢壓力，且無法有效擴充套件。
  2. 全球的監控資料彙總一處，會有頻繁的監控資料中斷、時延等問題，影響報警的及時性和準確性。
  3. 對網路專線強依賴，若專線發生異常，會導致相應邊緣節點的監控報警完全不可用，產生監控盲區。
  4. 資料合規性要求，某些邊緣節點的資料不允許匯聚到中心，目前的架構難以有效應對。

Zabbix

鑑於我們在 Zabbix 之外，也用到了另外多種監控工具：

  1. 工具多，體驗不一致，技術團隊學習成本很高。
  2. 資料孤島現象嚴重，關聯分析成本高，效率低（比如 Zabbix 、Prometheus、夜鶯之間的資料難以有效串聯）。
  3. 日誌分析的能力較為不足，比如缺少高效便捷的日誌報警等功能。

我們迫切需要對現有的監控方案做出改進，以支撐不斷增長的業務、適應不斷變化的使用者需求，提供可持續的服務能力，具體而言，有以下三個目標：

Zenlayer Next Generation Monitoring

解決方案

Zenlayer 技術團隊在調研技術方案的時候，關注到了快貓星雲的 Flashcat 平臺。使用 Flashcat，可以在一個平臺上完成指標、日誌、鏈路追蹤資料的統一採集、視覺化、告警、分析和 OnCall， 免去搭建和維護多套 Prometheus/Zabbix/Grafana/ELK/Jaeger 的工作量，遮蔽多雲監控的複雜度。Flashcat 平臺的定位和特點，與 Zenlayer 新一代監控方案的設計目標極為吻合：

  • 水平擴充套件的架構，高效能高可用，有上千家企業使用，經受了嚴苛的生產實踐檢驗。
  • 支援邊緣節點部署模式，可以在中心端高效、便捷的監控眾多邊緣節點，契合 Zenlayer 邊緣計算的業務特點。
  • 內建了故障處理的最佳實踐，當業務受損時，Flashcat 能第一時間發現，並輔助技術團隊快速展開調查，特別適合我們構建售後監控支撐平臺的目標。
  • 支援物理機、網路裝置、容器、K8s，微服務、主流雲產品，完全覆蓋我們的監控場景。

Zenlayer 與快貓星雲技術專家一起，重點從全球化架構、邊緣計算、網路監控、Zabbix 替代等方面出發，根據 Zenlayer 自身的業務特點，結合快貓星雲在統一監控和穩定性保障方向的最佳實踐，構建起了「Zenlayer新一代的統一監控方案」，最終也實現了對 Zabbix 的完美替代，解除了困擾已久的難題。

落地效果

邊緣部署模式

首先，我們測試了 Flashcat 的邊緣節點部署模式，將 Zenlayer 全球劃分為 7 大 Region，其中以 HK 為中心 Region，其餘為邊緣端，我們採用瞭如下部署架構：

  • 在每個邊緣端，本地儲存監控資料，即使網路中斷，本地仍然能夠閉環工作，獨立告警。
  • 中心端進行告警規則、儀表盤、資料採集策略的集中式管理、集中查詢，降低多 region 運維成本，使用者只需要面對 Flashcat 中心端。
  • 中心端、邊緣端均採用叢集方式部署，可橫向擴充套件，以滿足本區域不斷增長的監控需求。
  • 當前主要採集儲存 Metrics 指標，接下來可在邊緣機房部署日誌元件，不適合傳輸到中心端的資料，可以本地化處理。

邊緣計算

利用 Flashcat 的邊緣部署模式，有效的解決了 Zenlayer 全球節點監控資料匯聚帶來的問題，提升了監控資料的時效性、可靠性，降低了監控資料匯聚帶來的網路傳輸成本，同時還減輕了整個監控系統的維護和配置成本。

Zabbix 替換

在 Zenlayer，我們深度使用 Zabbix，特別的，我們本質上是一家網路公司，背後有近萬臺各種型號的網路裝置，分佈在全球範圍內，所以重度依賴 Zabbix 對網路裝置的資料採集和報警能力，比如：

  • Zabbix 對網路裝置的自動發現能力
  • Zabbix 對各種網路裝置SNMP採集的配置模板
  • Zabbix 採集所支援的裝置型號更全面
  • Zabbix 報警中的宏模式
  • …

此外，我們的技術團隊對於 Zabbix 使用時間久，如果遷移到新的工具有一定的遷移成本。帶著以上的問題出發，我們對 Flashcat 進行了細緻的測試，發現 Flashcat 對 Zabbix 能力的相容性非常不錯，以網路裝置的監控資料採集為例，介紹如下。

網路裝置採集配置模板化

Flashcat 針對特定型號的網路裝置，支援使用者將採集該裝置 Metrics 的 SNMP 配置，以模板的形式在 WebUI 上管理和配置，然後下發給指定的採集器 Categraf。比如：

透過SNMP採集華為某型號交換機 uptime 和 sysname 指標的採集模板

oid = "RFC1213-MIB::sysUpTime.0"
name = "uptime"

[[instances.field]]
oid = "RFC1213-MIB::sysName.0"
name = "sysname"
is_tag = true

採集記憶體總量和使用量的採集模板

...
[[instances.field]]
oid = ".1.3.6.1.2.1.25.2.3.1.5.1"
name = "memsize"

[[instances.field]]
oid = ".1.3.6.1.2.1.25.2.3.1.6.1"
name = "memuse"
...

Zabbix 使用者，尤其是深度使用者， 之前在 Zabbix 中已經積累了很多模板，這個模板如果按照 Flashcat 的格式去人工配置一遍也是一個很大的工作量。為了減輕這方面的工作量，Flashcat 支援將 Zabbix 的 XML 格式轉換為 Flashcat 格式的採集模板，這樣就可以加速從 Zabbix 採集模板往 Flashcat 採集模板遷移的過程。在測試中，我們和快貓星雲的技術專家，在 Flashcat 中建立了30多種網路採集模板。

- Arista Device Status
- Juniper Device Status
- Juniper BGP
- Nokia Device Status
- Huawei BGP
- Arista BGP
- Ciena Optical
- Juniper Optical
- Ruijie Device Status
- Sintai Optical
- Ruijie Optical
- H3C Optical
- IDC Interface
- Network Status
- ...

報警支援宏模式

宏變數是 Zabbix 中很強大的一個特性，告警閾值可以透過宏變數來設定，這樣不同角色的裝置就可以分別設定自己的閾值了。Flashcat 平臺對宏變數也進行了支援。在測試中，我們從 Zabbix 中遷移了上百條告警規則到 Flashcat 中。

Pingmesh

Pingmesh 是一種用於測量和監控網路效能的技術，透過在一組通訊對等體之間執行 Ping 測試來評估網路的可用性和延遲。Flashcat中的 Pingmesh 功能，提供了 TCP、UDP、ICMP 三種協議，在裝置之間進行互相探測，並繪製各個層面的連通性檢視，從全域性視角觀測整個網路的連通性，這對於我們的全球化佈局特別有價值，能夠幫助我們一目瞭然的看清楚不同的邊緣節點之間、不同的機櫃之間的網路連通質量。如果你想了解更多 Pingmesh 的技術細節，請查閱網路問題排查必備利器：Pingmesh。

SNMP採集支援多進位制轉化

在網路裝置中,有些 OID 對應的值可能並不是數值，需要從 string 或者 hex-string 格式進行轉換。比如，某些裝置其 MAC 地址和 IP 地址都是以 hex-string 形式儲存和展示的，如果直接採集，在 Flashcat 平臺上展示的話會是亂碼形式。下面的示例就是演示如何配置將 BGP 對端的 IP 地址作為 tag 附加到指標上的。如果指定conversion="hwaddr"則是進行 MAC 地址轉換，指定conversion="float"則是將字元轉為 float 型別，還支援轉為 int、 hextoint 等。

[[instances.table.field]]
oid = ".1.3.6.1.4.1.2636.5.1.1.2.1.1.1.11"
name = "peer_addr"
conversion = "ipaddr"
is_tag = true

SNMP採集支援返回多值

絕大部分 OID 返回值都是單值的，只需要考慮將返回值轉換為合適的格式即可。但是光模組功率是一個典型的多值返回，Flashcat 針對光模組採集做了擴充套件。比如下面這段配置是將返回值中4個部分分別對應rx_0_lane0 rx_0_lane1 rx_0_lane2 rx_0_lane3 這4個返回值，都按照 float 型別進行了轉換。

[[instances.table.field]]
oid = ".1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32"
name = "rx_0"
conversion="lane0:float,lane1:float,lane2:float,lane3:float"

支援relabel/rename

比如 index 原始值如下, 想把這兩個欄位前3位1.1.4.和1.2.16.去掉,生成新標籤 peer_addr

index="1.2.16.36.4.255.64.0.1.0.99.0.0.0.0.0.0.0.2"
index="1.1.4.103.140.146.151"

增加如下配置即可：

[[instances.relabel_configs]]
source_labels = ["index"]
target_label = "peer_addr"
#separator = "/"
regex = "\\d+\\.\\d+\\.\\d+\\.(.*)"
action = "replace"
replacement = "$1"

如果不想保留老的index label那麼配置如下：

[[instances.relabel_configs]]
regex = "index"
action = "labeldrop"

BGP監控資料採集

假設有兩張表需要做關聯 , 比如 BGP 中 peer_index 對應的 OID 是 .1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14， 另一張 receive 表對應的 OID 是 .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7，想對兩張表做關聯，peer_index 表的 index 中第一位作為 receive 表的 index 的一部分。

先看peer_index的返回:

.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14.0.1.128.1.130.176.1.128.1.130.178  = 0 
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14.0.1.128.1.130.176.1.128.1.130.179  = 1
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14.0.1.128.1.130.176.1.128.1.130.180  = 2
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14.0.2.38.4.9.128.224.5.47.255.0.0.0.0.0.0.0.1.2.38.4.9.128.224.5.47.255.0.0.0.0.0.2  = 3
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14.0.2.38.4.9.128.224.5.47.255.0.0.0.0.0.0.0.1.2.38.4.9.128.224.5.47.255.0.0.0.0.0.3  = 4
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14.0.2.38.4.9.128.224.5.47.255.0.0.0.0.0.0.0.1.2.38.4.9.128.224.5.47.255.0.0.0.0.0.4  = 5

再看receive表的返回:

.1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.0.1.1 = 2071
.1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.3.2.1 = 0

這兩張表關聯查詢，那就用 peer_index 對應的值 0/1/2/3/4/5 和 receive 表中的 index 0.1.1/3.2.1 關聯匹配，但是因為他們長度不同(peer_index的值只有一位)，所以長度對齊就用到了一個 oid_index_length 配置。 比如 oid_index_length=1 表示 receive 表的 index 的第一位只要匹配到 0/1/2/3/4/5 中任意一位就認為匹配成功。peer_index的配置如下:

[[instances.table.field]] 
oid = ".1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14" 
name = "peer_index" 
is_tag = true 
secondary_index_table = true  # 這個表的index對應的值要被其他表使用

receive表配置如下:

[[instances.table.field]]
oid = ".1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7"
name = "receive_total_prefix"
oid_index_length=1  # 只取關聯index的第一位
secondary_index_use = true # 使用上面指定的index

這樣最終取到的指標，只有一個：

snmp_juniper_bgp_prefix_receive_total_prefix{index="0.1.128.1.130.176.1.128.1.130.178"} 2017

從監控走向可觀測

除過對 Zabbix 替換的需求，突破擴充套件性瓶頸限制等問題。Zenlayer 對於建立全面的可觀測性體系，在過去的工作中，或多或少都有一些建設了，比如：

  • 我們使用 ClickHouse 儲存和分析日誌，製作報表
  • 我們使用 Prometheus 收集多套 K8s/K3s 雲原生技術棧的資料，並使用夜鶯 Nightingale 管理告警規則
  • 我們構建了網路層面的立體化的監測
  • 在某些特定場景下，我們藉助智慧監控提升效率，降低維護成本
  • 我們使用 on-call 工具管理告警的全生命週期過程，提高告警的處理效率，降低工作失誤
  • …

客觀講，我們不缺少工具，也不是缺少資料，困擾我們的反而是工具太多了，資料太多了！更多的工具意味著更多的學習成本，面對更多的資料，如果缺乏高效的分析能力，資料只能是負擔。我們在測試 Flashcat 的過程中，充分調研了 Flashcat 的多資料來源接入功能，包括 Metrics 源、Logging 源、Tracing 源、事件源四大類。在對接資料來源後，使用者就可以在 Flashcat 平臺上，對這些資料來源背後的資料，進行集中的查詢、視覺化分析、告警等。並藉助 Flashcat 的北極星和滅火圖，我們構建起了面向業務場景、層層下鑽的故障發現、定位體系。

比如，在故障發現層面，我們利用 Flashcat 提供的智慧檢測演算法，對骨幹網路流量進行實時監測，當流量出現異常波動，1分鐘就可以被檢測到，併傳送我們的技術團隊知曉和應急。

北極星

總結

Zenlayer 與快貓星雲技術專家一起，重點從全球化架構、邊緣計算、網路監控、Zabbix 替代等方面出發，根據 Zenlayer 自身的業務特點，結合快貓星雲在統一監控和穩定性保障方向的最佳實踐，構建起了 Zenlayer 新一代的統一監控方案，最終也實現了對 Zabbix 的完美替代，解除了困擾已久的難題。

相關文章