NetNORAD：通过端到端探测对网络进行故障排除

Facebook的服务由其庞大的底层网络基础设施提供支持。保持此网络正常运行是基础架构团队的首要任务之一。我们的规模意味着设备故障可以并且确实每天都在发生，我们努力防止这些不可避免的事件影响使用我们服务的任何人。最终目标是自动检测网络中断在几秒钟内缓解它们。相比之下，人为驱动的调查可能需要几分钟，如果不是几小时。其中一些问题可以使用传统的网络监控来检测，通常是通过SNMP查询设备计数器或通过设备CLI检索信息。通常，这需要大约几分钟的时间来产生稳健的信号并通知操作员或触发自动补救响应。此外，在我们的实践中，我们经常遇到称为灰色故障的情况，其中传统指标无法检测到问题，或者设备无法正确报告其自身的故障。所有这些考虑因素激励我们构建NetNORAD--一个将网络视为“黑匣子”并对网络问题进行故障排除的系统独立于设备轮询。

测量损失率和延迟

从应用程序的角度来看，网络有两个主要特征：丢包率和延迟。这两者的变化会影响传输协议的行为，例如TCP。为了衡量这两个指标，我们让Facebook的服务器相互ping通，收集丢包统计数据和RTT，然后根据这些信息推断网络故障。该系统中的两个关键组件是在我们的服务器上运行的pinger和responder进程。该ping发送UDP探测包来响应，后者接收，时间戳，并发回探头。该过程以轮次进行，其中每个pinger将数据包发送到其所有目标，收集响应，然后重复该过程。我们运行多个ping过程，每个过程用于标记网络中不同QoS类的每个不同DSCP值。

您可能会问为什么我们会选择UDP进行网络探测。实际上，我们的绝大多数流量都是通过TCP传送的，但是当我们开始使用无状态TCP探测（SYN-RST）时，我们注意到从目标机器请求TCP RST会产生太多噪音并混淆应用程序监视系统。从操作系统的角度来看，使用TCP进行状态探测（SYN-SYN / ACK）是资源密集型的，特别是考虑到确保覆盖所需的探测数量。我们还排除了ICMP，因为ECMP场景中可能存在极化问题（缺乏熵）。

我们的经验是，在绝大多数情况下，UDP和TCP在网络中共享相同的转发行为。同时，UDP更简单，允许直接测量底层数据包丢失和网络延迟。UDP的使用还允许在探针中嵌入自定义信息，例如多个时间戳，以准确地测量RTT。对于后者，我们使用内核时间戳，允许我们补偿由Linux内核中的缓冲引起的延迟，这是端到端探测技术的常见问题。

部署系统

Facebook的网络是分层次结构的。在最低级别，服务器安装在机架中，这些服务器以群集形式组织。集成在同一建筑物中并由公共网络服务的集群形成数据中心（DC）。反过来，数据中心通过网络进行聚合，该网络将它们在同一区域内互连并连接到Facebook全球骨干网络。Facebook的基础设施遍布全球多个地区。

我们在每个集群中部署了少量pinger，但我们在所有计算机上运行响应程序。使用较少数量的pinger是有意识的选择，以减少我们通过探测这么多目标所获得的数据量。所有pinger共享一个全局目标列表，其中包含每个机架中至少两台计算机。pinger可以非常快速地发送数据包，最高可达1 Mpps，总的探测速率大约为数百Gbps。

分层结构还允许我们简化一些数据聚合技术。当pinger在给定的ping轮次中收到响应时，它会聚合属于同一群集的计算机的结果，并根据其与目标群集的接近程度对其进行标记。例如，对于具有1,000个目标的群集X，pinger会将这些主机上的所有丢失统计信息汇总为几个值：平均丢包率，损失差异以及返回的所有响应中的RTT百分位数。然后它使用邻近标记标记结果，具体为：

如果目标群集与pinger位于同一数据中心，则为DC。 区域， 如果目标位于DC之外但在同一区域内。 如果目标位于pinger区域之外，则为全局。

数据处理

结果带有时间戳并写入Scribe，这是一个分布式实时日志记录系统，最终将其发送到Scuba，这是一个用于数据分析和可视化的分布式内存存储。Scribe允许多个读者（也称为零售商）以发布者/订阅者的方式使用信息，而Scuba只是其中之一。

我们运行专用的报警流程，该流程使用Scribe的实时数据并跟踪每个群集/邻近标记组合的丢包时间序列。对于每个群集/邻近对，该过程通过对来自所有pinger的结果求和来跟踪数据包丢失的演变方式。例如，对于集群X，我们将有三个时间序列反映来自不同视点的集群丢包：DC，Region和Global。这些来自所有认为自己分别位于相同数据中心，相同区域和区域外的pingers相对于探测集群。

对于每个时间序列，我们以10分钟为间隔跟踪百分位数。跟踪多个百分位数使我们能够识别网络上事件的性质。例如，第50百分位数的数据包丢失峰值意味着可能存在影响进出群集的大部分流量的故障，而第90百分位数的大数据包丢失值会告诉我们存在高水平的损失影响少数目标。对于每个百分位数和接近标记组合，我们设置上升和下降阈值以触发和清除相应的警报。

设计此管道的一个重要因素是检测有效网络故障的响应时间。Scribe写入/读取延迟通常为秒级，通过时间序列跟踪，我们通常会在20-30秒内看到警报。这个数字对于系统在生产中的成功至关重要，在事件发生时会发出警报。较大的延迟会使NetNORAD成为历史损失跟踪的良好工具，但会降低其作为前线警报系统的影响。

故障隔离

不容易判断数据包丢失是由终端主机故障还是真正的网络问题引起的，因为这些与端到端探测的角度无法区分。为了避免因重启服务器而导致的大量误报，pinger实现异常检测逻辑，帮助找到报告数据包丢失的目标，相对于一般人群来说，数据量过高; 来自这些目标的数据不包括在报告中。调度程序进程仅从已知的健康机器集中选择目标，例如，未发布已知会影响机器连接性的警报的机器，这一技术得到了补充。

类似的异常检测逻辑适用于过滤坏的 pingers：在可能存在连接问题的机器上运行的进程。警报过程会跟踪每个针对具有相同接近标记的所有群集报告的丢失，并且如果报告相对于其对等点的丢失过高则标记针对该针脚的丢失。然后忽略来自坏针的样品，直到它再次稳定。

使用邻近标记，我们可以通过运行警报关联分析来执行基本形式的故障隔离。我们遵循两个基本原则：

如果在DC，Region和Global proximity标签上报告丢失，则故障可能已在数据中心中进行了本地化。这是 根本原因隔离 的规则。 如果数据中心内的所有群集都报告丢包，则问题可能是群集上方的一层。这是 下游抑制 的规则。

通过将这些规则应用于警报，我们可以减少它们的数量并估计故障的位置。这不会，也不能确定确切的故障位置。就像常见的网络故障排除过程一样，为了本地化故障，我们需要运行一个额外的工具，我们称之为fbtracert。与流行的UNIX工具traceroute类似，fbtracert并行探索网络中两个端点之间的多条路径。此外，它还可以分析每一跳的数据包丢失情况，并将得到的路径数据关联起来，找出常见的故障点。

在许多情况下，特殊和有效，fbtracert并不普遍。它受到网络设备中控制平面监管和处理traceroute探测数据包的各种错误的限制 - 例如，使用错误的源IP地址进行响应。在底层转发路径频繁变化的情况下，它也不能有效地工作，因为它需要每个路径的稳定统计，这在一些骨干网络中就是这种情况。

在fbtracert无法找到故障的情况下，我们依赖于积极的人为参与，这通常始于挖掘我们存储在Scuba中的端到端数据包丢失数据，并使用数据过滤和对各种密钥进行分组（例如，ping源/目标，协议，QoS标记）。因此，我们将继续致力于探索新的故障隔离方法，以使其更加健壮并适用于更多情况。

开源NetNORAD

我们正在开源NetNORAD系统的一些关键组件，以推广端到端故障检测的概念，并帮助世界各地的网络工程师运营其网络。第一个组件是pinger和响应器（用C ++编写）和fbtracert实用程序（用Go编写）。虽然这不构成完整的故障检测系统，但我们希望您可以使用这些组件作为起点，使用您自己的代码和其他开源产品进行数据分析。

感谢网络基础设施工程和网络系统团队使NetNORAD成为现实。