背景 链接到标题 在我们内部产品中，一直有关于网络性能数据监控需求，我们之前是直接使用 ping 命令收集结果，每台服务器去 ping (N-1) 台，也就是 N^2 的复杂度，稳定性和性能都存在一些问题，最近打算对这部分进行重写，在重新调研期间看到了 Pingmesh 这篇论文，Pingmesh 是微软用来监控数据中心网络情况而开发的软件，通过阅读这篇论文来学习下他们是怎么做的。 数据中心自身是极为复杂的，其中网络涉及到的设备很多就显得更为复杂，一个大型数据中心都有成百上千的节点、网卡、交换机、路由器以及无数的网线、光纤。在这些硬件设备基础上构建了很多软件，比如搜索引擎、分布式文件系统、分布式存储等等。在这些系统运行过程中，面临一些问题：如何判断一个故障是网络故障？如何定义和追踪网络的 SLA？出了故障如何去排查？ 基于这几点问题，微软设计开发了 Pingmesh，用来记录和分析数据中心的网络情况。在微软内部 Pingmesh 每天会记录 24TB 数据，进行 2k 亿次 ping 探测，通过这些数据，微软可以很好的进行网络故障判定和及时的修复。 数据中心网络 链接到标题 常见的数据中心网络拓扑： 网络延时计算方式：server A 发送消息到 server B 接受消息的时间。最终使用 RTT 时间，RTT 一个好处是绝对时间，与时钟不相关。 在大多数情况下，大家不会去关心延时具体是什么导致的，都是直接归结于网络原因，让网络团队去排查，实际上是浪费了很多人力成本。延时变高有很多原因：CPU 繁忙、服务自身 Bug、网络原因等等。往往丢包会伴随着延时升高，因为丢包意味着会发生重传，所以丢包也是需要观察的重点。 因为 Pingmesh 运行在微软内部，所以依托于微软自己的基础架构，有自动化管理系统 Autopilot，有大数据系统 Cosmos，也有类似于 SQL 的脚本语言 SCOPE。 设计 链接到标题 根据上面的需求，Pingmesh 先评估了现有的开源工具，不符合的原因有很多，大多数工具都是以命令行形式呈现，一般是出现故障了去使用工具排查，而且工具提供的数据也不全面，有可能正在运行工具问题已经解决了。当然这并不是说已有的工具没有用，只能说不适合 Pingmesh。 Pingmesh 是松耦合设计，每个组件都是可以独立运行的，分为 3 个组件。在设计的时候需要考虑几点： 因为要运行在所有的 server 上，所以不能占用太多的计算资源或网络资源 需要是灵活配置的且高可用的的 记录的数据需要进行合理的汇总分析 Pingmesh 架构设计： Controller 链接到标题 Controller 主要负责生成 pinglist 文件，这个文件是 XML 格式的，pinglist 的生成是很重要的，需要根据实际的数据中心网络拓扑进行及时更新。