Roblox Cloud 上的网络数据包丢失与延迟监控

Roblox 网络工程团队负责维护一个规模庞大且快速增长的网络，其数据中心和接入点 (POP) 遍布全球。Roblox 平台能否提供卓越的用户体验，取决于该网络的性能和可靠性。网络运维人员必须能够排查和检测网络问题，并全面掌握网络性能状况，这一点至关重要。 网络监控通常通过定期收集设备统计数据、错误指标和系统日志，并将其存储在时间序列或日志数据库中来实现。数据收集采用推送或拉取模式，使用 SNMP、Netconf、REST API 或流式遥测等标准协议。

仅通过设备遥测进行网络故障检测存在若干缺陷，因为这是一种被动监控技术。它依赖于网络节点能否在异常情况发生时立即识别并上报。设备未必总能反馈数据，或者在某些情况下，其所有健康状态数据可能无法通过常规遥测收集方法获取。此外，网络设备有时可能会提供错误数据，或悄无声息地将流量黑洞化。 设备遥测的一个主要局限在于，它几乎无法提供网络端到端可达性、数据包丢失率及延迟统计数据的可视性。

如下图所示，通过定期在网状网络中传输合成探测数据，是主动监控网络的一种有效方法。

在排查生产环境故障时，网络运维人员经常会被问到诸如“网络是否存在丢包？”或“是否有正在发生的网络故障影响服务连接？”之类的问题。若无法获取历史丢包率和延迟数据，他们就需要对网络中的大量链路和节点进行排查。

设计可靠且可扩展的网络网格监控系统

要使“黑盒”网络监控系统有效检测数据包丢失或延迟突增，必须对网络的不同部分进行持续探测。数据中心网络利用节点间的所有链路传输用户流量。生产网络设备运行 BGP 协议，并通过多条等成本路径对流量进行负载均衡。在正常情况下，网络拓扑的变化通常会在几秒内通过路由表更新反映出来。 为了准确测量网络数据包丢失情况，测试探针应尽可能穿越覆盖所有网络节点和链路的路径。对于像我们这样横跨全球多个站点的庞大网络，对每对节点或机架之间进行探测并不具备可扩展性。我们选择的更可持续的解决方案是在不牺牲可视性水平的前提下，在每个站点内的机架之间构建一个 N² 网格，并在所有站点之间构建另一个 N² 网格。

我们使用什么工具对网络进行探测？

测试探针应模拟实际生产网络中的实时流量。我们网络上的大部分流量属于 TCP、UDP 或 HTTP 协议，这些协议均可用于生成探针。TCP 探针的一个问题在于其开销较大，难以扩展到监控大型网络所需的连接数量。 TCP的另一个问题在于，其内置的流量控制和基于滑动窗口的传输机制会导致探测发送速率波动，这不利于量化或检测瞬时数据包丢失。而ping和traceroute所使用的ICMP，通常在服务器或网络节点上受到速率限制，这限制了可用于ICMP探测的总速率。 HTTP请求位于应用层，且受网络外部因素（如服务器或应用程序性能）的影响。HTTP为结果引入了额外的变量因素，难以将其分离出来。本系统的目标是监控主要运行在OSI第4层及以下层级的底层网络基础设施的性能。基于这些原因，加上UDP是我们网络上的主要传输层协议，我们选择了UDP探针。

探针从何处发送？

要实现高聚合探测速率并覆盖大量网络路径，一种方法是尽可能利用更多计算节点来发送探测数据。这有两个优势：既有助于分担生成探测数据的系统负载，又能增加承载探测数据的网络端口数量。但这要求代理程序非常稳定，且对主机系统资源的占用尽可能少。 同时，代理应能够准确测量多条路径上的数据包丢失率和延迟，且不受主机系统 CPU、内存或 I/O 利用率波动的影响。代理必须在轻量级与高性能之间持续保持这种微妙的平衡。

我们如何测量网络丢包率和延迟？

对于单个探针流而言，这看似是一项简单的计算，但在大规模部署时会出现一些不那么显而易见的挑战。为了扩展到如此庞大的网状网络，代理需要同时对多个流进行快速且精确的计算，以获取带有时间戳的发送（Tx）和接收（Rx）数据包计数。 关键在于，网络丢包指标不应包含因代理运行主机 CPU 繁忙或网络缓冲区溢出而丢失的数据包。网络延迟的计算需基于探针在传输线路上或中间网络节点上的总时间，同时排除在 I/O 缓冲区中等待以及代理进程等待操作系统调度的时间。

Roblox 的 Ping Mesh 系统

自公共和私有云基础设施发展以来，对黑盒式网络丢包和延迟监控的需求一直存在。但要找到一款能够适应我们大型网络的现成解决方案却十分困难。多家大型云服务商和网络工具供应商都设计了各自的解决方案来监控网络丢包和延迟。 我们曾尝试过一些开源工具，但在稳定性与可扩展性方面遇到了问题，且对网络性能的可见性十分有限。这促使我们构建了自己的网状监控系统，该系统以较低的开销实现了对低频错误的更佳检测。我们系统的部分亮点包括：

• 我们选择使用 Go 语言实现系统的所有组件，这有助于在占用极少系统资源的同时实现高性能。
• 我们的代理程序稳定性极高，可在各类生产环境主机上运行，包括那些在 Roblox 平台上提供关键服务的主机，例如流量、缓存和应用服务器。
• 代理经过优化，通过 Go 包装函数对 Linux 的 sendmmsg() 和 recvmmsg() 系统调用进行批量数据包 I/O 操作，从而能够以低开销传输高频率的探测数据。我们部署中的每个代理同时向多达 100 个其他主机发送探测数据，速率为每秒 100 个数据包（PPS）。代理每秒向每个目标发送数据包突发。
• 探针在发往各目的地的 IP 头中携带不同的服务类型 (TOS) 字段值，并分别统计网络中的数据包丢失和延迟情况。每个数据包突发包含发往其他所有目的地的多种 TOS 值组合。这有助于监控不同服务质量 (QoS) 类别的网络性能。
• 代理可在每个探针路径上检测到低至每分钟6000个数据包中丢失1个的网络丢包。网络核心或边缘持续时间不足1秒的丢包（例如BGP波动期间的丢包）均可被检测到。
• 当丢包由网络设备接口错误引起时，探针的丢包图表与网络设备接口的错误率图表相似。我们已成功发现网络中难以检测的流量黑洞（black-holing）缺陷。
• 代理利用网卡内核读取时间戳，实现高精度的网络延迟测量。在排除主机操作系统调度延迟和网络时钟漂移的情况下，可测得站点内一致的往返延迟为50–100微秒。
• CPU 占用率和内存占用极低。在峰值收发速率（各 5 kpps）下，代理程序对单核的占用率低于 25%。大多数已部署的代理程序仅占用约 5% 的核心资源。管理代理程序的发送和接收数据包缓冲区及计数器仅需 10MB 堆内存。当网络规模扩大时，我们可以通过调整限制或添加更多代理程序来实现纵向或横向扩展。
• 即使主机系统处于高负载状态，代理程序也极少受到影响。我们曾多次在主机 CPU 负载接近 99% 的情况下仍获得了准确的结果。
• 系统会从每个代理收集遥测数据以监控其运行状态。代理能够识别诸如主机系统重启、代理进程重启，或因套接字缓冲区溢出导致数据包丢失等问题。

代理通过 Chef 部署在广泛的服务器集群上，以确保有大量节点参与网络探测。代理二进制文件在 Linux 上通过 systemd 运行和管理，因此主机重启或代理升级后会自动重启。当任何一个代理下线或有新代理上线时，网格调度器会根据需要动态检测并调整数据流。 我们的调度器应用程序会定期轮询设备清单和服务发现系统，以检测新的代理和服务器健康状态，然后为 Pod 内、站点内和站点间探测分配目标。 通过消息总线将目标主机列表传达给每个正在发送测试探针的代理。起始或终止于特定机架的独立数据流，会被分配给该机架内所有可用的代理。这有助于我们在网络架构中测试大量等成本路径，如下图所示。

我们在首次部署时仅有150个代理，如今已成功扩展至10倍规模。该网状网络覆盖了我们的骨干网，将遍布全球的25个站点相互连接。 在其中一个主要数据中心站点，我们部署了覆盖200多个机架的站内网状网络，约33,000个数据流聚合后形成1.65 Mpps的探针速率。每个机架会接收来自其他机架的5–10 kpps探针。调度程序会计算并将超过35,000个目标均匀分配给不同站点的所有代理。

数据采集与可视化

我们运行一个独立的收集器应用程序，该程序会定期轮询所有 Ping Mesh 代理，以获取数据包丢失和延迟结果。系统会根据收集器本地缓存的健康状态自动过滤数据，排除无效结果。例如，我们会排除来自未响应健康检查的服务器上运行的代理，或刚重启的服务器上的结果。 我们的收集器能够同步轮询并过滤来自 1,500 多个节点的结果，随后在 2 秒内将数据导入时间序列数据库。

聚合结果和按流结果均借助 Grafana 仪表盘进行可视化展示。对于海量数据集（尤其是我们的大型数据中心站点），热力图网格往往难以有效使用。我们利用 Prometheus 的 topk() 查询，从数千条结果中筛选出单次数据包丢失率最高的路径，这类情况通常仅占极少数。 这些结果会与收集器频繁轮询的代理和主机系统健康统计数据进行全面比对。这使我们能够对每个单独的结果保持高度信心，无论数据包丢失的波动幅度有多大。综合查看这些单独结果，可以为我们提供网络故障发生位置的线索。以下展示了一些由我们的网状监控系统捕获的数据包丢失示例。

总结与后续步骤

我们的 Ping Mesh 系统一直是网络工程团队监控端到端数据包丢失和延迟的强大工具。这些数据可用于即时回答“网络是否丢包？”这一问题。根据我们的经验，通常由设备遥测监控系统检测并预警那些对客户影响重大的网络事件。 而那些影响较小但可能引发问题的网络缓冲或孤立流量黑洞问题，则通过该系统得以揭示。

我们的系统还能提供关于 Roblox 云网络整体可靠性的洞察。在我们的一个主要数据中心站点，每分钟有超过 1 亿次探测用于监控网络健康状况，且每分钟丢包数极少超过 50 次。这表明我们的数据中心网络可靠性达到了约 6 个 9（99.9999%）。 在数以亿计的数据包中，经常会出现零丢包的情况。当发生大量数据包丢失时，该系统能精准定位丢包发生的位置及持续时长。自动修复引擎会通过将用户流量重定向至网络中的其他路径，实现网络自愈，从而防止用户流量遭受进一步的丢包。Roblox 的网络团队已构建起一个极其可靠的云网络。

未来，我们计划利用分析引擎，将设备遥测数据、系统日志及其他数据集进行关联分析。随后，我们将把这些数据与 Ping Mesh 数据进行比对，以帮助定位网络故障发生的位置。随着 Roblox 云网络的持续扩展与演进，我们计划增强探测机制，以支持 IPv6 和巨型帧，同时增加更多代理节点以提升站点间的覆盖范围。