Zenlayer如何将万台设备监控从Zabbix迁移到Flashcat

作为全球首家以超毗连为焦点的云服务商，Zenlayer 致力于将云计算、内容服务和边沿技术融合，为客户提供全面的解决方案。通过构建可靠的网络架构和高效的数据传输，Zenlayer 资助客户实现更快速、更可靠的毗连，提升用户体验和业务服从。Zenlayer 在全球范围内运营着超过 290 个边沿节点， 骨干网带宽超过 50Tbps， 10000+ 的数据中心接入点，快速毗连全球公有云与数据中心。

监控现状

Zenlayer 运营着全球数百个边沿机房和巨大的骨干网网络，我们的监控目的主要包罗：

• 各种硬件设备，如交换机、裸金属
  
• 超大大规模网络的连通性和质量
  
• Kubernetes 云原生技术栈
  

在 Zenlayer，监控系统不但仅是作为一个内部工具服务于运维和研发团队，我们的售后团队高度依靠监控系统为客户提供高水平的技术支持服务，监控系统是 Zenlayer 最重要的基础服务和产品之一，是我们交付用户代价的关键所在。
目前我们使用的监控工具有：Zabbix、Prometheus、夜莺 Nightingale、ClickHouse：

• 接纳 Zabbix 监控各种网络设备，将全球各个边沿节点的监控数据，汇聚到中心统一处理。
  
• 接纳 Prometheus 网络 Zenlayer 的云原生技术栈的监控数据，统一使用夜莺 Nightingale 来配置和管理告警规则。
  
• 使用 ClickHouse 对系统日志进行分析。
  

痛点和挑战

考虑到 Zenlayer 的设备数量（近万台网络设备）、设备种类、全球化布局，Zabbix 渐渐接近性能瓶颈：

• 海量数据的查询、看图、报警，对 Zabbix 数据库有很大的写入和查询压力，且无法有效扩展。
  
• 全球的监控数据汇总一处，会有频繁的监控数据中断、时延等问题，影响报警的及时性和准确性。
  
• 对网络专线强依靠，若专线发生异常，会导致相应边沿节点的监控报警完全不可用，产生监控盲区。
  
• 数据合规性要求，某些边沿节点的数据不允许汇聚到中心，目前的架构难以有效应对。
  

鉴于我们在 Zabbix 之外，也用到了另外多种监控工具：

• 工具多，体验不划一，技术团队学习本钱很高。
  
• 数据孤岛现象严峻，关联分析本钱高，服从低（比如 Zabbix 、Prometheus、夜莺之间的数据难以有效串联）。
  
• 日志分析的能力较为不足，比如缺少高效便捷的日志报警等功能。
  

我们急迫需要对现有的监控方案做出改进，以支撑不断增长的业务、适应不断变化的用户需求，提供可连续的服务能力，详细而言，有以下三个目的：

解决方案

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 指标的收罗模板

1. oid = "RFC1213-MIB::sysUpTime.0"
2. name = "uptime"
4. [[instances.field]]
5. oid = "RFC1213-MIB::sysName.0"
6. name = "sysname"
7. is_tag = true

复制代码

收罗内存总量和使用量的收罗模板

1. ...
2. [[instances.field]]
3. oid = ".1.3.6.1.2.1.25.2.3.1.5.1"
4. name = "memsize"
6. [[instances.field]]
7. oid = ".1.3.6.1.2.1.25.2.3.1.6.1"
8. name = "memuse"
9. ...

复制代码

Zabbix 用户，尤其是深度用户， 之前在 Zabbix 中已经积累了很多模板，这个模板如果按照 Flashcat 的格式去人工配置一遍也是一个很大的工作量。为了减轻这方面的工作量，Flashcat 支持将 Zabbix 的 XML 格式转换为 Flashcat 格式的收罗模板，这样就可以加速从 Zabbix 收罗模板往 Flashcat 收罗模板迁移的过程。在测试中，我们和快猫星云的技术专家，在 Flashcat 中创建了30多种网络收罗模板。

1. - Arista Device Status
2. - Juniper Device Status
3. - Juniper BGP
4. - Nokia Device Status
5. - Huawei BGP
6. - Arista BGP
7. - Ciena Optical
8. - Juniper Optical
9. - Ruijie Device Status
10. - Sintai Optical
11. - Ruijie Optical
12. - H3C Optical
13. - IDC Interface
14. - Network Status
15. - ...

复制代码

报警支持宏模式

宏变量是 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 等。

1. [[instances.table.field]]
2. oid = ".1.3.6.1.4.1.2636.5.1.1.2.1.1.1.11"
3. name = "peer_addr"
4. conversion = "ipaddr"
5. is_tag = true

复制代码

SNMP收罗支持返回多值

绝大部分 OID 返回值都是单值的，只需要考虑将返回值转换为合适的格式即可。但是光模块功率是一个典型的多值返回，Flashcat 针对光模块收罗做了扩展。比如下面这段配置是将返回值中4个部分分别对应rx_0_lane0 rx_0_lane1 rx_0_lane2 rx_0_lane3 这4个返回值，都按照 float 类型进行了转换。

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

复制代码

支持relabel/rename

比如 index 原始值如下, 想把这两个字段前3位1.1.4.和1.2.16.去掉,天生新标签 peer_addr

1. index="1.2.16.36.4.255.64.0.1.0.99.0.0.0.0.0.0.0.2"
2. index="1.1.4.103.140.146.151"

复制代码

增加如下配置即可：

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

复制代码

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

1. [[instances.relabel_configs]]
2. regex = "index"
3. 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. .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
2. .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
3. .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
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.2  = 3
5. .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
6. .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. .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.0.1.1 = 2071
2. .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的配置如下:

1. [[instances.table.field]]
2. oid = ".1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14"
3. name = "peer_index"
4. is_tag = true
5. secondary_index_table = true  # 这个表的index对应的值要被其他表使用

复制代码

receive表配置如下:

1. [[instances.table.field]]
2. oid = ".1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7"
3. name = "receive_total_prefix"
4. oid_index_length=1  # 只取关联index的第一位
5. secondary_index_use = true # 使用上面指定的index

复制代码

这样终极取到的指标，只有一个：

1. 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 的完善替换，排除了困扰已久的难题。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。