Facebook的案例证实了活跃路径测试确实有效。

我之前看到了一篇有意思的博客文章，文中介绍了Facebook的活跃路径测试工具NetNORAD。读者可从中了解Facebook为何会自己开发一个网络性能监控工具。NetNORAD基于一个发包与响应系统，它会测量服务器之间的丢包和延迟时间。另外，还有一个相关的工具叫fbtracert，当数据包出现问题时，它可用于详细诊断和定位错误来源。这两个工具都是发布到GitHub上的开源项目。而且，这个系统还依赖于消息日志系统Scribe和查询与报表系统Scuba。

可能有人会觉得：“它们确实很好，但它们是由Facebook公司有才能的软件工程师团队开发的，我们没办法在自己的环境中做出这样的东西，”先别着急，听我慢慢道来。

即使你所在的公司没有像Facebook那样雄厚的资源，你也一样可以利用类似的系统去实现适合自己企业的相同的功能。下面我们来看看Facebook是如何实现的。

该工具的关键设计

NetNORAD活跃路径测试网络监控工具的开发包含了几个关键设计，其中包括：

• 服务器之间的Ping。用一个端到端Ping去测试服务器、服务器网络连接及网络本身。我发现Facebook的方法所采用的网络端到端原理出自Jerome Saltzer、David Reed和David Clark在1984年发表的论文《端到端系统设计论证》和《活跃网络与端到端论证》。
• 在每一个机架上选择2个发包器和2个响应器。使用2个是为了实现冗余，从而帮助发现服务器层、机架层及更高层次上的问题。
• 使用用户数据包协议（UDP）。Facebook对于使用UDP而不使用传输控制协议（TCP）和互联网控制消息协议（ICMP）的原因进行了论证。除了这些原因之外，UDP更简单一些，它支持直接测量底层数据丢包情况。
• 使用可按需伸缩的工具来采集数据。在这种情况下，Facebook工程师开发了Scribe，因为现有的工具并不支持伸缩。大多数企业并不需要这样的规模，因此他们可以使用其他的数据采集工具。
• 将数据存储在非关系型数据库中。Facebook遇到问题是关系型数据库技术以及寻找支持更优伸缩性的实现方法。我总是看到一些网络管理供应商的开发人员认为关系型数据库管理系统是存储时间系列数据的正确方法。然而，大型（非超大型）企业的网络管理数据量对于其他类型数据库而言就是一种问题。在Facebook这样规模的公司中，他们不得不使用内存数据库，以实现预期的性能水平。
• 支持虚拟化和报表等基础功能的工具。基础工具能够解决用户社区中的大部分需求，从而不需要太多的定制开发。

活跃路径测试的优势

很多年以来，我都在自己的网络管理架构推荐清单中加入了活跃路径测试。这种端到端的可见性是非常宝贵的。它就像派出一组活跃测试人员，以网络的角度去检查和报告网络性能，我们可以将它看作是在监控网络的心跳。

能够准确识别出性能问题的路径是一种极大的胜利。一旦发现了有问题的路径，就可以轻松地使用来自少量接口的简单网络管理协议（SNMP）数据去确认问题根源是否容易找到。在使用NetNORAD时，一定要能够发送UDP数据包，也要能够添加服务质量（QoS）标记。

【编者按：如果需要专有QoS的测量，则建议将发包器和响应器所使用的网卡配置为支持QoS标记。】

企业实现

有几个供应商推出了支持类似功能的企业级产品，但一般只支持较小规模。除了少数企业之外，从成本效益上看大多企业更应该购买这样的产品，而不是自己投入人力去利用开源项目搭建一个系统。可以考虑的有AppNeta、NetBeez和NetScout（TruView Live）等公司的产品。【编者按：有这种产品的公司不仅限于这几家。】

这些供应商通常都有硬件和软件两个版本的探测产品，既支持安装在服务器和终端上，也支持独立安装。这些探测产品基本上都支持自助托管，可以根据需要自动下载更新。组合使用硬件和软件，可以发现网络问题及服务器端问题。例如，如果一个速度慢的服务器子网中并没有出现丢包、高延迟或高抖动（延迟变化）的问题，那么就要检查服务器链路、服务器内部功能及其他服务器上的应用程序依赖。

供应商正努力保证系统可以向上扩展以支持大多数客户的需求。此外，这也意味着非Facebook用户也可以不用自己做这些工作。

大多数活跃路径测试工具包括要支持网页访问，即提供对Web应用程序的程序层Ping操作。这个功能是监控使用Web接口的云服务的重要功能。要检查供应商执行其他（非Web）应用层Ping的能力。

我们并非一定要有Facebook的环境才能受益于其带来的经验，可以通过使用活跃路径测试供应商的产品来达到同样的效果。确定适合自己的监控需求和特性，然后再进行概念验证，以少量的探测器及合理成本搭建良好的系统。