关于运维:网络问题排查必备利器Pingmesh

背景

当今的数字化世界离不开无处不在的网络连接。无论是日常生活中的社交媒体、电子商务，还是企业级应用程序和云服务，咱们对网络的依赖水平越来越高。然而，网络的可靠性和性能往往是一个简单的问题，尤其是在具备大规模分布式架构的零碎中。

在过来，网络监控次要依赖于传统的点对点（point-to-point）形式，通过独自的监控工具对网络门路进行测试。然而，这种办法往往只能提供无限的信息，并且无奈全面评估整个网络的健康状况。为了更好地理解网络的运行状况以及及时发现潜在的问题，Pingmesh 技术应运而生。

Pingmesh 的提出最后是来自微软，在微软外部 Pingmesh 每天会记录 24TB 数据，进行 2000 亿次 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 个级别：

1. 在机架外部，让所有的 server 相互 ping，每个 server ping 机架内其余 N-1 个 server
2. 在机架之间，则每个机架选几个 server ping 其余机架的 server，保障 server 所属的 ToR 不同
3. 在数据中心之间，则抉择不同的数据中心的几个不同机架的 server 来 ping

Pingmesh 架构设计

Controller

Controller 次要负责生成 pinglist 文件，这个文件是 XML 格局的，pinglist 的生成是很重要的，须要依据理论的数据中心网络拓扑进行及时更新。
在生成 pinglist 时，Controller 为了防止开销，分为 3 个级别：

1. 在机架外部，让所有的 server 相互 ping，每个 server ping（N-1）个 server
2. 在机架之间，则每个机架选几个 server ping 其余机架的 server，保障 server 所属的 ToR 不同
3. 在数据中心之间，则抉择不同的数据中心的几个不同机架的 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 来主动重启交换机，复原交换机的能力。

Flashcat-Pingmesh 计划

业界计划大都实现了各自的 ping-agent 的能力，但对于 controller 生成 pinglist 的能力并未有好的开源计划。同时咱们和一些客户交换，理解到目前数据中心架构与传统的 leaf-tor-server 架构不太一样，传统一个机顶交换机下 server 都在一个机柜下，当初数据中心一个交换机下机器可能在不同机柜，这种状况如果还是按交换机维度进行探测，当 server 机器探测故障后，无奈疾速定位到机器地位。因而，咱们在开发之前就针对 Tor 以及机柜维度进行了设计。

Pimgesh 应具备哪些能力？

1. 具备最根底的 Ping 探测能力，即 ICMP 协定反对，同时也应反对 TCP、UDP 等协定的端口探测；
2. 简化页面用户配置，用户只需配置数据中心名字、交换机 CIDR 值，数据中心反对的探测协定和端口等要害信息；
3. 数据中心会有很多机柜、交换机和机器，如何防止 ping 风暴，因而需反对配置选取局部机柜、替换和机器进行探测，及探测比例配置，用户可灵便配置数据中心参加探测的交换机或机柜比例数，以及每个交换机或机柜下参加探测的 Server 比例数；
4. 每个数据中心外部、默认所有机柜或交换机之间进行探测 (Server 比例数仍旧失效)
5. 每个数据中心之间，用户可配置默认规定，即两两数据中心之间，依照配置的协定进行探测。当然，用户也可自定义哪些数据中心之间依照所选协定进行探测，此时机柜或交换机以及 Server 比例数仍旧失效；
6. 探测后果进行无效聚合展现，多个数据中心有很多机柜或交换机以及机器，分三层构造展现探测后果，第一层展现所有数据中心之间的探测链路拓扑以及探测值、第二层展现数据中心外部每个机柜或交换机之间的探测拓扑和后果、第三层展现机柜或交换机上面所选 Server 之间的探测拓扑和后果；
7. Ping 故障一键进行探测的止损能力；
8. 探测机器故障后，主动从新选替补机器能力；
9. 数据中心配置变更后，能及时主动以新配置从新生成 pinglist；
10. 反对简便地配置报警规定；
11. 探测后果写入反对 prometheus 协定的时序库中；

交换机和机柜模式配置差别

1. 交换机模式，页面用户只需配置替换 CIDR 值即可，无需手动注册 Server IP，咱们会借助 Categraf 的心跳性能，主动判断出 server ip 应归属哪个交换机。
2. 机柜模式，这种形式个别实用于客户环境中有本人的 CMDB 零碎，可将其 CMDB 零碎中的数据中心、机柜和机器关系通过 OpenApi 注册到 Pingmesh 零碎中。

Pingmesh 架构设计：

Apiserver

提供 OpenApi:

1. 用于注册、变更、查问数据中心原信息、探测规定 (如：数据中心、探测协定、Tor 交换机 CIDR/ 机柜名、机器 IP 和机器名 ( 机柜形式)、探测百分比设置、数据中心之间探测规定设置 )。
2. 数据中心三层构造拓扑图展现，以及历史探测曲线图、报警规定配置、一键降级等 API。
3. 提供给 Categraf 应用的查问 pinglist 接口。

Controller

生成 pinglist 的外围控制器逻辑，它须要定时从 DB 中查问最新的配置和规定，判断是否有产生变更，如果产生变更则从新执行 pinglist 生成逻辑。
从 DB 中查到配置后，判断是机柜模式还是交换机模式，因为这两种形式，其筛查 Server IP 的逻辑会有差别，之后需计算出每个数据中心，待探测的机柜或交换机是哪些，以及其下的 Server Ip 别离是多少，做好数据筹备工作。接下来查看探测规定（数据中心内、数据中心之间），依据这些规定咱们对每一台发动探测的 Server 生成探测配置，并记录到 DB 中 (因为咱们底层真正执行探测工作的是 Categraf Agent，需依据不同协定所应用的插件，生成不同的配置文件)。

此外，咱们需新起一个协程，定时去比照新用户配置和已生成的 pinglist 是否统一，因为可能在咱们生成新的 pinglist 后的一段时间内，用户变更或新增、删除了数据中心配置和规定，那须要将已生成的 pinglist 进行比照清理，防止用户配置变更后，仍旧应用老的配置去探测，导致数据不准问题。

实现过程中还须要思考另一个问题，数据中心有很多机器，但不是所有机器都装有 categraf，或装有 categraf 但过程退出了等状况，如果咱们只是单纯地按所有的机器数量去筛选一堆 Server IP，那很有可能选出的机器都没有装 agent，那也就无奈进行探测和发现问题了，因而咱们须要联合 categraf 本身的心跳上报的能力，来过滤出可用的 Server IP。到了这里，咱们可能会想到另一个问题，因为咱们是按比例筛选机器的，而当某台机器 down 掉后，本来选了 10 台，当初只有 9 台可用机器了，这就会和用户配置的参加探测的服务器比例呈现 diff。呈现这种状况，那咱们就须要从新选一台可用机器补上去。当抉择进去这批机器后，前面都须要始终用这些机器，除非遇到从新选的状况，这样能够保障咱们指标量是固定的，同时也能满足探测的比例需要。

探测 Agent

Pingmesh 底层真正执行探测逻辑的是咱们的 Categraf，它是一个开源的我的项目，插件丰盛、配置简略，这里就不做过多介绍了，大家可在 github 上搜寻下即可。Categraf 会定时来核心端拉取本机的采集插件配置，当然，可能部署 categraf 的集群很多，这里核心端会将配置文件缓存到 Redis 中，升高对 DB 的查问压力，并晋升接口查问效率。最终 categraf 会拿到最新的插件配置并进行探测，之后将探测后果上报给核心端，用于数据展现和报警配置应用。

额定说一点，如果存在边缘机房，那 categraf 能够将探测后果上报给边缘机房的 n9e-edge 模块，之后报警就可在这边缘机房外部闭环了，而且 edge 会主动将指标转发给时序库，用于页面展现应用。

小结

Pingmesh 在简单网络问题的排查中施展了微小的作用，本文分享了 Pingmesh 的实现思路，欢送大家 分割咱们试用。