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

作为客户业务的核心组件，保障云数据库7/24的稳定至关重要。我们通过对用户承诺数据库SLA服务等级协议，来保障用户的权益。然而，云数据库的服务质量受各种因素影响，例如突发性连接断开、数据库延迟发生抖动、吞吐骤然下降等，都有可能带来用户业务指标的下降。因此，快速发现云数据库性能异常，及时定位根因是云数据库厂商的一个挑战。

[原文来自：www.11jj.com]

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

可能造成云数据库的服务质量下降的原因很多，例如网络上的异常，比如DB主机的上联交换机tor发生丢包，或者load balaner出现TCP incast问题；或者用户侧的问题，用户端网络异常或者丢包；或者多租户机制，DB主机内核缺陷、硬件上SSD的硬件异常等等都会引起。在出现问题时，快速诊断定位解决问题是关键的问题。

传统数据库性能采集只需要采集DBMS内部处理SQL请求的延迟就够了，但云数据库需要end-end数据。因为对云上用户而言，他看到的云数据库的延迟是终端的延迟。真实的场景对trace工具提出这些需求，因此很关键的是要采集end-to-end数据，以及链路每段的延迟，终端用户感受到的延迟是所有路径上每个节点处理延迟以及网络上所有延迟的总和，不仅仅要采集DB上的延迟，还要采集proxy上看到的延迟。这需要在链路上引入trace。还要采集网络上的数据，主机上其实可以看到的上行乱序和下行的重传，这个信息对推测网络有无异常非常重要。发送和接收会走不同的网络路径。

传统的trace手段需要入侵式地在业务代码中添加埋点。第一，我们不能在客户端埋点，因为客户基本上都使用标准数据库客户端来访问，没有嵌入打点代码，我们也不能期望客户会修改自己的业务代码，加入打点逻辑，并将打点数据采集交给我们。因此我们需要一种非侵入式的方法来获取end-to-end性能数据。第二在服务器端埋点也有问题，应用层无法感知真正的数据接收和发送时间。应用层记录的时间是内核把数据交付给应用层和应用层把数据交付给内核的时间。在系统负载很高，应用层进程调度需要花费大量时间的场景下，会导致请求的实际处理时间计算不准确；应用层无法感知到网络链路质量。在网络出现拥塞，大量的重传报文，导致数据发送和接收过程大大延长，无法区分出是对端响应缓慢还是网络链路质量不佳。

在这种挑战下，TcpRT——阿里云数据库监控和诊断服务质量系统，孕育而生。

TcpRT从主机TCP/IP协议栈的拥塞控制采集trace数据，用于监测数据库延迟和网络异常，并利用先进的流技术，在后台实时计算..上进行大规模在线数据分析，结合离线模型，通过实时异常事件判定，以及RDS网络关系图谱中的趋势一致性概率探测，快速诊断出性能异常并定位原因。

架构

上图是TcpRT的概要架构图，其中包含以下个组件：

内核模块——用于采集指标trace数据，包括查询延迟、Proxy节点和DB节点的连接指标等

本地聚合器——负责将内核模块采集的trace数据进行本地聚合处理，推送至Kafka消息队列

流式ETL——利用流技术，在后台流式计算..上将Kafka中的时序指标数据进行清洗、多粒度聚合及在线分析，利用冷热技术将数据分离

在线异常监测——根据时序指标数据，拟合异常模型，通过实时异常事件判定，以及RDS网络关系图谱中的趋势一致性概率探测，快速诊断出性能异常并定位原因

TcpRT内核模块

内核模块主要负责对网络数据的传输进行整个生命周期的监控。在遵守停等协议的TCP通信机制下，服务端处理每个请求的过程分成3个阶段，接收阶段(Receive)、处理阶段(Handle)和响应阶段(Response)。如下图所示：