从没想到监控可以这么做！阿里云RDS智能诊断系(3)

[转载出处：www.11jj.com]

[好文分享：www.11jj.com]

鉴于此，我们需要计算如下时间：

上行时间 = T1 - T0
处理时间 = T2 - T1
下行时间 = T3 - T2
查询时间 = T3 - T0
RTT时间 = T2 - T2"

现有的监控方案，通常在业务层面埋点进行服务耗时监控，但此方法既不能获得真正的数据接收和发送时间、也无法感知到网络链路的质量，更需要在业务代码中入侵式地添加埋点。因此，我们实现了一种通用、低开销的内核模块进行trace监控以得到上述时间。

首先，我们选择修改Linux内核的拥塞控制算法。此算法可以感知内核发送报文的上下文，并且支持热更新（只需增加一个驱动模块而无需更新线上内核）。

此外，拥塞控制算法提供了以下机制：
1. 每个TCP通信是独立的拥塞控制算法，不存在资源竞争情况
2. 可以感知到收到的每个ACK报文的上下文
3. 在已经发送的报文都已经被ACK的情况下，可以感知到当前发送的报文上下文

根据拥塞控制算法提供的事件回调，我们可以获取到每个TCP连接下述事件：
1. 客户端发送给服务端ACK报文
2. 在所有已经发出去的sequence都被确认的情况下，服务端发送报文
3. TCP连接建立
4. TCP连接断开

内核任何线程都可能调用到拥塞控制算法，因此为了性能，拥塞控制算法必须保证是没有数据争抢的。TcpRT内核模块保证了以下四点：

1. TcpRT所有的数据保存在每个TCP连接对象上，所有的数据读写都没有跨TCP连接的共享；
2. TcpRT在每个CPU core都有独立的写缓冲区，防止了多个内核线程争抢写缓冲区加锁；
3. 为了避免内存开销，又保证实时性，TcpRT的写缓冲区会在buffer满或者时间到的情况下，刷新写缓冲区到debugfs，供应用层采集端采集。由于写debugfs的频率很低，debugfs的锁争抢几乎不存在，最大限度保证了性能；
4. TcpRT回写的数据，是binary格式的，对比需要format的字符格式，在实测场景可以提高20%的性能。

此外，通过给linux内核添加setsockopt选项，通知内核一个不需要应答的请求交互过程已经结束，从而支持非停等协议。

针对TcpRT内核模块对用户数据库实例的性能影响，我们基于sysbench模拟了MySQL 400个客户端连接进行压测，结果如下图所示，TcpRT内核模块对系统的负载影响不到1%。

TcpRT聚合器

TcpRT内核模块，利用debugfs和用户态通信。每秒以千万的trace数据高速产出并吐入至debugfs中。为了减轻后台在线分析任务的压力，我们构建本地TcpRT聚合器，实现本地trace秒级聚合，并将聚合结果输出到/dev/shm中。Logagent从中读取聚合数据，发送至Kafka，并由后台ETL接手，进行实时数据分析，流程如下图所示：

在本地聚合器中，聚合操作需要保证可交换且可结合，我们采用均值、最大值、请求个数的三元组聚合方法来保证延迟时间类指标满足这一要求。此外，我们采用每秒同客户端出现的不同端口数对活跃连接数进行指标特征提取。同时，抽取请求数作为特征，建立用户长短连接的使用模型，进而对用户使用数据库实例的负载模式进行分析。根据历史数据，当前仍有众多用户采用短连接模式，这对于诸如MySQL线程网络模型的DB是非常不友好的，从而激发我们提供Proxy中间件将短连接转换为长连接服务。

为了最大化聚合效果，我们在内存中维护最近5s的聚合结果，将5s前的数据输出到/dev/shm的文件中。且为了提高查询性能以及长时间段的聚合操作，我们将三种粒度1s, 5s, 1m的聚合结果存入到库中。

TcpRT ETL