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

下图描绘了ETL任务的拓扑结构：

在线ETL任务主要包括四个子任务：

数据转换

数据关联与聚合

数据存储

以及延迟和乱序处理

其中，延迟和乱序到达的处理是一个难点。TcpRT输出的时序数据是以SQL执行结束时间为时间戳，如何做到实时准确地对窗口内的时序数据进行聚合并将结果刷出是一个两难的问题。我们采用了“尽力聚合”的方法，即对窗口设定等待时间，待时间结束后将实时聚合结果刷出，若此后，还有该窗口的时序数据到来，则直接落入到数据库中。如TcpRT聚合器中所述，所有聚合数据具有可再结合特性，这样，我们可以对同时刻的聚合数据进行二次聚合。

在线异常监测

组件的异常往往伴随着相关指标的抖动。比如主机发生IO Hang后，load、dirty、writeback、某些core的iowait、被阻塞的线程数等指标会明显升高，而各实例的write，CPU使用率会明显变低，主机维度的PT指标会明显升高。在部分情况下，连接数会上升，长连接请求数会下降，流量会下降等。在Proxy发生异常的时候，PT可能会升高、CPU、流量、连接数均可能会下降。

传统方法下，我们通过设定阈值进行指标抖动的检测。然而阈值的设定强依赖于专家经验，维护成本高，且一刀切的设定常常会“误伤”健康指标。比如，有些数据库实例是专门用于OLAP，它们的SQL请求处理时间往往都是秒级的，若采用常用的SQL请求处理时间作为异常判定阈值，此类数据库实例就会触发报警。

鉴于此，我们需要一种通用且自适应的智能模型来解决云数据库的异常监测。

为了避免人工设定阈值，我们一开始尝试利用control charts来进行判断，根据样本时间段的均值和标准差，预测未来时间段的置信区间。若实际值超出置信区间，则判定为异常。然而，若样本本身为异常，则此时间段的参数均不可信。

如上图，左上图为(ins1,*,db1)的upsize指标时序图，可以看到(ins1,*,db1)的upsize指标会有周期性的波动。左下的两张图分别是历史时间窗口设定值为30min的(ins1,*,db1)的upsize指标mean&median时序图和SD&MAD时序图。可以清楚看到，当upsize指标发生波动后，mean值和标准差SD值都会发生窗口时间长度的跳变，但median和MAD却几乎不受指标波动的影响，显得更平稳、丝滑。

右上图为（ins2,*,db2）的newConn指标时序图，可以看到在03:40~04:00期间，指标发生异常，出现大量极端值，由于历史的时间窗口设定值为30min，所以可以从左下的图表中看到，很长一段时间内样本的均值和标准差便会发生较大的波动，而中位数和MAD指标却显得平滑，对极端值并不敏感，展出超强的鲁棒性。由于依赖均值和标准差进行预测，control charts具有不稳定性，易造成误判。这启发我们利用中位数和MAD替代均值和标准差作为预测模型参数。