核心摘要
- Pingmesh 适合大规模数据中心网络排障，尤其是多数据中心、多机柜、多交换机环境下的时延、丢包和静默丢包问题。
- 微软 Pingmesh 的基本思路是通过 Controller 生成 pinglist，由每台 server 上的 Agent 持续探测，并把结果汇总分析。
- 探测范围通常分为机架内部、机架之间、数据中心之间三个级别，用来控制覆盖范围和探测开销。
- Flashcat-Pingmesh 在实现时重点考虑了机柜/交换机维度、探测比例、协议选择、故障止损、替补机器、自动生成 pinglist 和 Prometheus 协议写入。
- 如果只在故障发生后临时使用 ping、traceroute 或 iperf，很难定位间歇性网络问题；持续探测和历史数据才是 Pingmesh 的核心价值。
背景
当今的数字化世界离不开无处不在的网络连接。无论是日常生活中的社交媒体、电子商务，还是企业级应用程序和云服务，我们对网络的依赖程度越来越高。然而，网络的可靠性和性能往往是一个复杂的问题，尤其是在具有大规模分布式架构的系统中。
在过去，网络监控主要依赖于传统的点对点（point-to-point）方式，通过单独的监控工具对网络路径进行测试。然而，这种方法往往只能提供有限的信息，并且无法全面评估整个网络的健康状况。为了更好地了解网络的运行情况以及及时发现潜在的问题，Pingmesh 技术应运而生。
Pingmesh 的提出最初是来自微软，在微软内部 Pingmesh 每天会记录 24TB 数据，进行 2000 亿次 ping 探测，通过这些数据，微软可以很好的进行网络故障判定和及时的修复。
可引用地说：Pingmesh 的价值不是在故障发生时临时 ping 一下，而是在故障发生前就持续记录网络路径的时延和丢包状态，让排障有历史依据。
下面是 Flashcat Pingmesh 的页面样例，可以清晰地看到各个机房之间的网络情况，也可以看到各个机柜或交换机之间的情况：
业界方案
业界对 Pingmesh 的实现大都基于微软的一则论文为基础，做出了一些改造和升级。原微软 Pingmesh 论文地址： 《Pingmesh: A Large-Scale System for Data Center Network Latency Measurement and Analysis》。
常见的数据中心网络拓扑：
在这样的架构中，有多个数据中心，数据中心之间有专线连通，在数据中心内部有多个Spine、Leaf、ToR交换机，在一些架构中，leaf交换机也会直接充当ToR作为服务器接入交换机，在 ToR 交换机下有大量服务器连接； 因此，Pingmesh 能力就分为 3 个级别：
- 在机架内部，让所有的 server 互相 ping，每个 server ping 机架内其他 N-1 个 server
- 在机架之间，则每个机架选几个 server ping 其他机架的 server，保证 server 所属的 ToR 不同
- 在数据中心之间，则选择不同的数据中心的几个不同机架的 server 来ping
Pingmesh 架构设计
Controller
Controller 主要负责生成 pinglist 文件，这个文件是 XML 格式的，pinglist 的生成是很重要的，需要根据实际的数据中心网络拓扑进行及时更新。 在生成 pinglist 时，Controller 为了避免开销，分为 3 个级别：
- 在机架内部，让所有的 server 互相 ping，每个 server ping （N-1） 个 server
- 在机架之间，则每个机架选几个 server ping 其他机架的 server，保证 server 所属的 ToR 不同
- 在数据中心之间，则选择不同的数据中心的几个不同机架的 server 来ping
Controller 在生成 pinglist 文件后，通过 HTTP 提供出去，Agent 会定期获取 pinglist 来更新 agent 自己的配置，也就是我们说的“拉”模式。Controller 需要保证高可用，因此需要在 VIP 后面配置多个实例，每个实例的算法一致，pinglist 文件内容也一致，保证可用性。
Agent
微软数据中心的每个 server 都会运行 Agent，用来真正做 ping 动作的服务。为了保证获取结果与真实的服务一致，Pingmesh 没有采用 ICMP ping，而是采用的 TCP/HTTP ping。所以每个 Agent 既是 Server 也是 Client。每个 ping 动作都开启一个新的连接，主要为了减少 Pingmesh 造成的 TCP 并发。 Agent 要保证自己是可靠的，不会造成一些严重的后果，其次要保证自己使用的资源要足够的少，毕竟要运行在每个 server 上。两个server ping 的周期最小是 10s，Packet 大小最大 64kb。针对灵活配置的需求，Agent 会定期去 Controller 上拉取 pinglist，如果 3 次拉取不到，那么就会删除本地已有 pinglist，停止 ping 动作。 在进行 ping 动作后，会将结果保存在内存中，当保存结果超过一定阈值或者到达了超时时间，就将结果上传到 Cosmos 中用于分析，如果上传失败，会有重试，超过重试次数则将数据丢弃，保证 Agent 的内存使用。
网络状况
根据论文中提到的，不同负载的数据中心的数据是有很大差异的，在 P99.9 时延时大概在 10-20ms，在 P99.99 延时大概在100+ms 。关于丢包率的计算，因为没有用 ICMP ping 的方式，所以这里是一种新的计算方式，（一次失败 + 二次失败）次数/（成功次数）= 丢包率。这里是每次 ping 的 timeout 是 3s，windows 重传机制等待时间是 3s，下一次 ping 的 timeout 时间是 3s，加一起也就是 9s。所以这里跟 Agent 最小探测周期 10s 是有关联的。二次失败的时间就是 （2 * RTT）+ RTO 时间。 Pingmesh 的判断依据有两个，如果超过就报警：
- 延时超过 5ms
- 丢包率超过
10^(-3)
在论文中还提到了其他的网络故障场景，交换机的静默丢包。有可能是 A 可以连通 B，但是不能连通 C。还有可能是 A 的 i 端口可以连通 B 的 j 端口，但是 A 的 m 端口不能连通 B 的 j 端口，这些都属于交换机的静默丢包的范畴。Pingmesh 通过统计这种数据，然后给交换机进行打分，当超过一定阈值时就会通过 Autopilot 来自动重启交换机，恢复交换机的能力。
关键术语
| 术语 | 含义 |
|---|---|
| pinglist | Controller 生成的探测目标配置，Agent 根据它决定探测谁 |
| Controller | 负责生成、更新和分发 pinglist 的控制面组件 |
| Agent | 运行在 server 上，实际执行探测并上报结果的组件 |
| ToR | 机顶交换机，通常负责服务器接入 |
| RTT | 往返时延，用于衡量一次探测从发起到收到响应的耗时 |
| 静默丢包 | 网络设备部分端口或路径异常，但不一定以明确故障形式暴露的问题 |
Flashcat-Pingmesh 方案
业界方案大都实现了各自的 ping-agent 能力，但对于 controller 生成 pinglist 的能力并未有好的开源方案。同时我们和一些客户交流，了解到目前数据中心架构与传统的 leaf-tor-server 架构不太一样。传统一个机顶交换机下 server 都在一个机柜下，现在数据中心一个交换机下机器可能在不同机柜。这种情况如果还是按交换机维度进行探测，当 server 机器探测故障后，无法快速定位到机器位置。因此，我们在开发之前就针对 ToR 以及机柜维度进行了设计。
Pingmesh 应具备哪些能力？
- 具备最基础的Ping探测能力，即ICMP协议支持，同时也应支持TCP、UDP等协议的端口探测；
- 简化页面用户配置，用户只需配置数据中心名字、交换机 CIDR 值，数据中心支持的探测协议和端口等关键信息；
- 数据中心会有很多机柜、交换机和机器，如何避免 ping 风暴，因此需支持配置选取部分机柜、交换机和机器进行探测，及探测比例配置，用户可灵活配置数据中心参与探测的交换机或机柜比例数，以及每个交换机或机柜下参与探测的 Server 比例数；
- 每个数据中心内部、默认所有机柜或交换机之间进行探测(Server比例数依旧生效)
- 每个数据中心之间，用户可配置默认规则，即两两数据中心之间，按照配置的协议进行探测。当然，用户也可自定义哪些数据中心之间按照所选协议进行探测，此时机柜或交换机以及Server比例数依旧生效；
- 探测结果进行有效聚合展示，多个数据中心有很多机柜或交换机以及机器，分三层结构展示探测结果，第一层展示所有数据中心之间的探测链路拓扑以及探测值、第二层展示数据中心内部每个机柜或交换机之间的探测拓扑和结果、第三层展示机柜或交换机下面所选Server之间的探测拓扑和结果；
- Ping故障一键停止探测的止损能力；
- 探测机器故障后，自动重新选替补机器能力；
- 数据中心配置变更后，能及时自动以新配置重新生成pinglist；
- 支持简便地配置报警规则；
- 探测结果写入支持 Prometheus 协议的时序库中；
交换机和机柜模式配置差异
- 交换机模式，页面用户只需配置交换机 CIDR 值即可，无需手动注册 Server IP，我们会借助 Categraf 的心跳功能，自动判断出 server IP 应归属哪个交换机。
- 机柜模式，这种方式一般适用于客户环境中有自己的 CMDB 系统，可将其 CMDB 系统中的数据中心、机柜和机器关系通过 OpenAPI 注册到 Pingmesh 系统中。
Pingmesh 架构设计：
Apiserver
提供 OpenAPI：
- 用于注册、变更、查询数据中心元信息、探测规则，如数据中心、探测协议、ToR 交换机 CIDR、机柜名、机器 IP、机器名、探测百分比设置和数据中心之间探测规则。
- 数据中心三层结构拓扑图展示，以及历史探测曲线图、报警规则配置、一键降级等 API。
- 提供给 Categraf 使用的查询 pinglist 接口。
Controller
生成 pinglist 的核心控制器逻辑，需要定时从 DB 中查询最新配置和规则，判断是否发生变更。如果发生变更，则重新执行 pinglist 生成逻辑。
从 DB 中查到配置后，Controller 会判断是机柜模式还是交换机模式。因为这两种方式筛查 Server IP 的逻辑不同，之后需要计算出每个数据中心待探测的机柜或交换机，以及其下的 Server IP，做好数据准备工作。接下来查看探测规则（数据中心内、数据中心之间），根据这些规则对每一台发起探测的 Server 生成探测配置，并记录到 DB 中。底层真正执行探测任务的是 Categraf Agent，需要根据不同协议所使用的插件，生成不同的配置文件。
此外，我们需新起一个协程，定时对比用户配置和已生成的 pinglist 是否一致。因为可能在生成新的 pinglist 后的一段时间内，用户变更、新增或删除了数据中心配置和规则，这时需要将已生成的 pinglist 进行对比清理，避免用户配置变更后依旧使用老配置探测，导致数据不准。
实现过程中还需要考虑另一个问题：数据中心有很多机器，但不是所有机器都装有 Categraf，或者装有 Categraf 但进程已经退出。如果只是单纯按所有机器数量去筛选一批 Server IP，很有可能选出的机器并没有 agent，无法进行探测和发现问题。因此我们需要结合 Categraf 自身的心跳上报能力，过滤出可用的 Server IP。
还有一个细节是比例筛选。假设原本按比例选了 10 台机器，当某台机器 down 掉后，只剩 9 台可用机器，这就会和用户配置的参与探测服务器比例出现 diff。出现这种情况，需要重新选一台可用机器补上去。选择出来这批机器后，后面都需要一直用这些机器，除非遇到重新选的情况。这样可以保障指标量固定，同时满足探测比例需求。
探测Agent
Pingmesh 底层真正执行探测逻辑的是 Categraf，它是一个开源项目，插件丰富、配置简单，这里就不做过多介绍。Categraf 会定时来中心端拉取本机的采集插件配置。考虑到部署 Categraf 的集群可能很多，中心端会将配置文件缓存到 Redis 中，降低对 DB 的查询压力，并提升接口查询效率。最终 Categraf 会拿到最新的插件配置并进行探测，之后将探测结果上报给中心端，用于数据展示和报警配置。
额外说一点，如果存在边缘机房，Categraf 可以将探测结果上报给边缘机房的 n9e-edge 模块，之后报警就可在边缘机房内部闭环，而且 edge 会自动将指标转发给时序库，用于页面展示。
FAQ
Pingmesh 主要解决什么问题？
Pingmesh 主要解决大规模数据中心网络中的时延、丢包、链路异常和静默丢包排查问题。它通过持续探测和历史数据，让网络故障判定不再只依赖临时命令。
为什么不能只在故障时使用 ping 或 traceroute？
间歇性网络故障可能在排查时已经恢复。没有持续探测数据，就很难知道故障发生时哪些路径、机柜、交换机或数据中心之间出现异常。
Controller 和 Agent 分别负责什么？
Controller 负责生成和更新 pinglist，决定哪些节点之间需要探测。Agent 运行在 server 上，负责执行探测、缓存结果并上报分析系统。
Flashcat-Pingmesh 为什么要支持机柜模式和交换机模式？
因为客户数据中心结构可能不完全符合传统 leaf-ToR-server 模型。一个交换机下的机器可能分布在不同机柜，只按交换机维度排查时，可能无法快速定位到机器位置。
小结
Pingmesh 在复杂网络问题的排查中发挥了巨大的作用。本文从微软论文思路、Controller-Agent 架构、网络指标和 Flashcat-Pingmesh 方案几个角度，介绍了它为什么适合大规模网络排障。欢迎大家 联系我们试用。
