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

如上图所示，通过大量观察，我们发现，按（*,*,db） 和(*,*,proxy) 粒度聚合后的采样点集合近似正态分布。但是，正态分布依赖平均值和标准差作为参数，如上文所述，这两个参数波动大，会造成严重误判。鉴于柯西分布与正态分布相似，且不依赖均值和标准差，可以使用中位数和MAD这种稳定的统计指标来进行回归。从上上图可以看到当历史时间窗口长度设定合适的时候，中位数和MAD在面对指标波动和异常的情况下，显得平滑且稳定，这样回归出的模型具有更强的稳定性。于是，我们使用中位数和MAD作为参数的回归柯西分布来拟合异常诊断模型。

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

[原创文章：www.11jj.com]

为了获取回归需要的样本集，我们通过对过去一段时间（比如：最近一个小时）的每一个时间点做采样，得到一段历史窗口的数据点集合S{x0,x1,x2,……}。根据历史窗口数据集，计算中位数M以及MAD，回归出这个数据集的柯西概率分布D。

主机异常检测

RDS主机上承载着众多实例，各实例通常隶属于不同用户的不同业务。在主机正常工作时，由于实例相互独立、并且对应的指标波动具有不确定性，所有实例呈现出一致性升高或降低的概率非常小。当主机发生异常时，由于该主机上的所有实例共享同一资源，某些关键指标会呈现出一致性趋势。当一台主机发生了IO Hang，主机上大部分实例的SQL处理延迟都呈现出升高的趋势，各实例的数据写入量呈现出下降的趋势。这启发我们利用实例趋势一致性概率来判断主机的异常。

首先，设定函数H(curentVal, prevMideanVal，metricType)作为判断指标metric1是否异常的函数,取值只能是－1，0，＋1。currentVal代表这一刻该指标的值，prevMideanVal代表过去一段时间（比如：1小时）采样点集合的中位数，metricType代表该指标的类型（比如：rt，rtt，qps，流量等）。取值为－1代表这个指标在跟过去一段时间指标做对比的时候呈现出明显下降的趋势，0代表这个指标没有明显波动，＋1代表这个指标与过去一段时间相比明显上升。

我们可以利用上文的算法来实现函数H，这样我们能算出（ins,*,dstIp,metricType）级别数据的函数H值，然后在按(ins,*,dstIp,metricType)->(*,*, dstIp,metricType)做map－reduce（agg类型为sum）。算出的值s反映了这个指标在这台主机上的突升，突降的趋势，用求和值s除以这个主机上的活跃实例数t得出突升／突降实例比例r，当r大于0是，总体趋势上升，当r小于0是，总体趋势下降，且绝对值越大概率越大。

那么我们如何利用r值来判断主机异常呢？如果机器突然由正常变为异常时，各实例由于都依赖这台机器的资源进行工作，或多或少要受其影响，因此相关指标发生突变的实例比例将会发生突变，比如主机上cpu资源突然不足，大部分实例都会受影响，他们的处理时间会突升，流量突降，请求数突降，因此可以通过判断r值是否突变来判断主机异常。 

我们可以利用上文的算法来对r值的突变进行判断，对过去一段时间的每一个时间点都做这样的计算，我们可以得到一段历史窗口的突升／突降实例比例r行程的数据点集合S{R0,R1,R2,…}。根据历史窗口数据集，我们算出数据集的中位数M，以及MAD值，回归出这个数据集的柯西概率分布D。

因为比例r的取值是－1～1，而柯西概率分布D的自变量x范围是负无穷到正无穷。我们需要对原来的比率r做转化让他的范围扩充到正负无穷。通过定义的映射函数求出这一时刻下该指标的柯西概率分布的CDF()，如果CDF()非常小，比如小于0.1%，主机hostA的指标metric1呈现总体下降趋势，或者非常大比如99.8%, 主机hostA的指标metric1呈现总体上升趋势。 但是这样做判断，只是判断出了r值的突升和突降，为了减少误判，我们还要判断出r值的突升和突降需要落到警戒范围。因此需要一个必要条件：r值的绝对值至少为20％。

另外，当r值足够高时，无论r值是否突升还是突降，都应该认为是异常，因此还需要一个充分条件：r值的绝对值大于AlarmRatio(主机上的活跃实例t),那么认为是异常。根据我们自己的实际情况，AlarmRatio(t)＝0.8*Pow(0.987, t) + 0.2. 曲线如图，当主机上的活跃实例比较少时，AlarmRatio值比较高，这样为了保证判断出异常的主机上异常的实例足够多，这样才有较高的说服力，而随着主机上活跃实例数变多，AlarmRatio值会相应得变小最后收敛到0.2，这样为了不漏掉r比较少但是异常实例数足够多的情况。

当r＝-1时，这台机器hostA上所有的实例的指标metric1都出现了下降趋势，当r=1时，hostA上所有实例的指标metric1都出现了上升趋势。除了独占实例，一台主机上有数十甚至上百的实例，他们分属不同的用户，运行着不同的业务，呈现出一致的趋势概率很小，因此在正常的时候r值往往稳定在一个较低的范围内，当r值很高的时候，极有可能主机问题了。 

但是这样的判断还不够，因为还存在这两种情况：1. 实例之间公用的某个组件出现了异常。比如网络中间件引起的异常，路由器的异常等等。也会引起r值变高；2.有的主机上因为实例数比较少（比如：小于3）时，单纯根据比例判断还分辨不出是否是主机的问题，因为样本数太少，不具有说服力。针对这两种情况，我们还用了多种方法来提高准确率，比如：

1.结合物理机的资源指标（load，iowait，dirty，writeback等）的加权和来协助判断。2.如果存在上游节点（比如：proxy），并且上游节点存在异常，则优先报上游节点的异常。因为上游节点往往还连接多个下游节点，如果是某个单独的下游节点出现了异常，一般上游节点是不会出现异常的，因为上游节点上连接的下游节点很多，这一个点并不会明显改变整体的指标趋势变化，而某个节点的多个下游节点都出了问题，他们的上游节点出问题的概率更大一些。假设上游节点完全正常，下游节点近似相互独立，一个节点出问题的概率为p，K各节点同时出问题的概率就是p^K,所以问题的原因很可能是概率更大的上游节点。

Proxy异常检测

我们的大部分实例在访问db前要经过proxy的转发，proxy可以帮用户做短链接优化，负载均衡，连接审计，注入检测等。proxy是我们生产集群非常重要的组件，一个proxy节点最多会有上千个实例的请求（requests of thousands of instances）经过。也就是说，如果一个proxy节点发生了故障，将会影响到上千个实例，这样的故障我们需要快速准确地发现并定位出来，否则后果不敢想象。

我们一开始对proxy的qps，连接数等设定阈值的方式来进行报警，但是由于不同分组的proxy业务量大小不一样，因此我们需要对不同分组设定不同的阈值，而且我们的业务增长迅速，proxy会经常进行扩容，这样阈值又要重新调整，维护起来费时费力。

我们虽然可以利用上边所讲的判断db主机异常一样的算法来判断proxy异常，但是由于proxy的处理时间包含了db本地的处理时间，应用这种方式我们是无法评估出请求在单纯在proxy中停留的时间。对于使用了proxy链路的用户，由于在网络中多了proxy转发的代价，所以SQL请求的延时会稍微比不用proxy链路的请求要慢。因此为了不影响用户的体验，我们希望SQL请求在proxy节点中停留的时间越短越好。因此我们以SQL请求在proxy节点中停留和proxy与db之间的传输总时间prT(proxy relay time)作为衡量proxy服务质量的重要指标。如果实例ins1的请求在proxy节点的prT>=ProxyRelayTimeLimit，对于该请求，proxy代价时间过长。

由于有现成的生产集群上proxy节点和db节点都安装了tcprt内核驱动，我们打算proxy节点和db节点的tcprt数据来做类似的工作。