Home 技术文章 使用xTCP进行大规模套接字性能监控
Applications

使用xTCP进行大规模套接字性能监控

About The Author

Outline

背景

CDN和云提供商在互联网上提供大量流量,并采用广泛的监控工具来确保性能和可靠性。 这些工具包括涵盖各种流量交付层(如网络,服务器,应用程序等)的工具 TCP/IP占此流量的大多数(虽然基于UDP的QUIC在全球范围内呈上升趋势,但与TCP相比,它仍然只占总流量的一小部分)。

套接字是操作系统抽象,用于链接用于传输数据的客户端和服务器连接。 因此,网络问题直接反映在每个插槽存储的数据中。 例如,网络拥塞可能导致响应时间缓慢,往返时间(RTT)也会增加。 网络带宽也可能可用,但应用程序因请求过多而不堪重负,无法为缓冲区填充足够的数据以充分利用可用带宽,从而导致应用程序受限的异常。 服务器通常同时处理多个插槽,这可能会导致资源争用,从而对系统资源(如CPU和内存)造成压力。

因此,大规模监控TCP套接字的性能可以提供对通信行为(例如响应时间过慢或连接中断)的重要了解,并确定可以改进的情况。

现有工具

Linux中的”ss”实用程序是用于获取套接字统计信息的常用工具。 与”netstat “类似,ss通过允许对套接字状态,协议和地址进行筛选来提供更快,更灵活的获取信息的机制。 我们还与ss一起开始了套接字监控之旅。 虽然它是一个功能强大的工具,可以快速获取套接字列表和相关指标,但ss的主要挑战是它会消耗大量资源,尤其是在具有大量套接字的系统上使用时。 这会影响系统性能并减慢其他进程。 此外,由于密钥(值使用)不一致,ss输出不适合用于解析,并且使从数千台服务器传输收集的数据的能力变得非常复杂。

我们使用ss的第一个套接字集合版本是在选定的缓存服务器上运行的bash脚本,我们将”ss–tcp–info”的输出导出到文件中。 然后,该文件将被rsync绑定到一个堡垒主机,python脚本将从该主机读取该文件,解析并将其插入Elasticsearch。 这项工作已经完成,但远远不能达到我们所需的规模。 这项工作的下一个迭代是在缓存服务器上运行python脚本,该脚本将从HTTP接口调用,并返回聚合的统计数据以插入ElasticSearch群集。 这种方法将解析瓶颈从中央后台位置扩展到单个高速缓存服务器,但会导致具有大量套接字的服务器上的大量内存利用率。 最终,我们认识到需要对系统的ss部分进行轻量级更换。

我们对这款新工具的主要要求是,它应该是轻量级的,并可扩展到我们的CDN服务器拥有的大量套接字,并且能够使用协议缓冲区等高效机制流式传输数据。 来自MeasementLab的TCP-info 工具 是在Golang中实施的一个很棒的实用程序。 但是,它设计用于跟踪相同的套接字。 由于我们的插座连接量很大,因此我们在设计上选择了不跟踪单个插座。 而是让每个轮询循环独立,提供打开的套接字的当前状态快照。 此处的主要目标是跟踪系统的整体性能,而不是单个插槽。

xTCP

为了解决这些难题,我们引入了 开源xTCP (提取,导出,Xray TCP )。 xTCP是一个Golang实用程序,用于大规模捕获和传输套接字数据。 xTCP使用Netlink捕获套接字信息,将数据打包在protobufs中,并通过UDP端口(最终发送到Kafka等)将其发送出去,或写入 NSQ

NetLink 为用户空间和内核空间之间的通信提供了通用接口。 套接字监控工具ss,TCP-info使用NetLink_iNet_DIAG,这是Netlink协议系列的一部分,用于将套接字信息从内核获取到用户空间(手册页中的注释:NetLink_iNet_DIAG是在Linux 2.6.14中引入的,并且仅支持AF_iNet和AF_INET6套接字。 在Linux 3.3中,它被重命名为NetLink_sock_DIAG,并扩展为支持AF_UNIX套接字。

xTCP 以较高的速率提取内核TCP iNet_DIAG数据并通过protobufs导出该数据。 在具有大约~120k个套接字的计算机上,Netlink消息大约为~3595 -6,但是,ss的ASCII输出大约为~60MB。 此外,默认情况下,ss从内核读取~3KB块。 xTCP可读取32KB数据块,从而最大程度地减少系统调用。 xTCP使用多个工作器同时读取Netlink套接字数据,以尽可能快地耗尽队列,并并行解析Netlink消息以进行流化处理。 所有这些优化都使得xTCP的占用空间更小,无法在生产缓存服务器上运行。

在Edgio的用途

我们大量利用xTCP数据来分析客户端性能。 通常,我们跟踪RTT并按入网点(POP)和ASN聚合重新传输。

与老化率相比,TTL允许我们更改特定项目的缓存能力。 对于使用TTL函数设置的持续时间,项目在磁盘上时不会老化,因此被驱逐的可能性较小(甚至不太可能)。 TTL到期后,项目可以开始老化,采用传统的LRU方式,也可以使用快速老化或缓慢老化(具体取决于操作员的配置方式)。 在下图中,具有缓慢老化的TTL会将磁盘上的项目保留到不超过缓存清除阈值的程度。 相反,TTL确保实时视频流至少在事件的持续时间内被缓存,但在这之后,使用快速老化功能将其从磁盘中快速删除。

示例xTCP仪表板显示大型美国提供商的POPS AGA和CHB的RTT,重新传输和采样套接字数。

在之前的一篇博客文章中,我们介绍了动态拥塞控制调谐的管道,以自动为性能不佳的客户启用BBR,我们知道BBR的机制将是最有用的。 xTCP数据是分析的主要来源。

我们不断寻找新的方法来使用xTCP数据来回答复杂的问题,例如拥塞的影响,以及用于预测性能和检测异常的机器学习。 我们计划在未来的博客文章中报告此类套接字数据分析。

今天xTCP加入了我们的开源网络监控工具套件中的vFlow (sFlow,NetFlow,IPFIX收集器)。 我们希望这能为用于套接字数据收集的基础设施性能监控社区提供服务,并期待积极参与此工具的进一步开发。

确认

xTCP的成功和广泛的可用性是Edgio的个人和团队贡献的结果。 我们要特别感谢David Seddon,他是xTCP的最初开发者。 特别感谢所有内部代码审阅者和贡献者对xTCP的测试,摄取,仪表板和反馈。