1. 背景

1. 目前中间件容器节点故障、机器资源有余 (磁盘大小、内存大小、cpu) 等问题时有发生，接入自动化运维后可疾速的解决集群异样问题。

2. 以前解决问题须要人工染指，人力老本较大，运维流程不足标准。

2. 指标

1. 标准化，标准运维流程，制订规范的运维流程。

2. 可视化，运维流程可视化、平台化，做到可追踪，可回溯。

3. 自动化，容器重建，过程启停，局部指标通过根因剖析实现故障自愈。

3. 故障自愈架构图

故障自愈的监控数据采集模块，周期性将采集到的各实例指标数据上报给处理器，处理器通过调用元数据模块获取匹配规定、故障自愈解决流。匹配异样数据胜利并生成运维事件，再通过事件收敛过滤以确保没有大批量雷同属性(如同业务、机房等)，最初执行对应编排的自愈解决流，运维事件复原，发送告诉，业务恢复正常。

产品架构图：

整体流程图：

4. 方案设计

4.1 故障辨认

通过拉取实例监控数据、多指标聚合检测辨认出异样，并触发故障自动化流程。

计划一：过滤型检测监控数据

 过滤型检测匹配，只跟数据自身无关，工夫窗口设定没有要求，数据来一条解决一条。达到设定的异样阈值时触发运维事件。此检测计划过于粗犷，对于一些监控数据存在刹时突刺景象也会触发误运维，若频繁自愈会影响中间件稳定性。此计划个别用于告警触发，用作运维触发存在肯定危险。

计划二：基于窗口工夫检测

窗口抉择分类：

固定窗口(fixed windows): 设置一个固定的工夫长度，实时统计窗口工夫内的数据。通常状况会依据 key 做一些 Partition 划分，这样能够做一些并发解决，减速计算。

滑动窗口(sliding windows): 设置一个窗口长度和滑动长度，如果滑动长度小于窗口的长度，那么就呈现一部分窗口会相互笼罩，局部数据存在反复计算；如果窗口长度等于执行周期，那么就是固定窗口的模式；如果窗口长度小于执行周期，就是抽样的计算了。

会话窗口(session windows): 针对的是具体的某个事件，比方特定的人看的视频汇合等。会话要期待的数据是不确定什么时候到来的，窗口永远是不规整的。

论断：周期性监控数据能够看作绝对法则且无穷的数据，故而前两种窗口模式做流式计算比拟适宜。

窗口工夫抉择：

基于计算工夫的窗口解决问题是非常简单的，只有关注窗口内的数据就能够了，数据完整性也不必操心。然而理论的数据里必定带有事件工夫，这个工夫的数据通常在分布式系统中也是无序的，要是零碎呈现某些点的提早，那么失去的后果其准确性就大大降低了。基于事件工夫对于业务准确性有很显著的益处，然而也有很显著的毛病，因为数据提早，在分布式系统很难说这段时间内，数据曾经残缺了。

数据完整性保障：

显然无论窗口给的多大，永远无奈保障，合乎窗口内事件工夫的数据肯定可能准时到达，利用 watermarks（水位线）能够解决什么时候认为数据完结敞开窗口进行计算的问题。如下图：

设定固定窗口 2 分钟聚合计算，失去的 4 个窗口聚合后果别离是 6、6、7、12，但在第一个窗口 12:02 聚合完结后，其实该窗口数据在 12:03 才算残缺残缺，故而失去的后果不精确，引入 watermark 可失去正确的聚合后果 11。这里的 watermark 示意多长时间以前的数据将不再更新，也就是说每次窗口聚合之前会进行 watermark 的计算，首先判断这次聚合窗口最大事件工夫，而后加上所能忍耐的延迟时间就是 watermark，当一组数据或新接管的数据事件工夫大于 watermark 时，则该数据不会更新，可弹出窗口内的数据进行计算且在内存中不再保护该组数据的状态。

流式计算之固定窗口：

中间件监控数据周期性上报数据量不是很大，分布式系统中对于轻量级流能够思考利用 redis 做实时聚合，并实现滚动窗口触发。

如上图所示，设定匹配的窗口大小为 2 分钟，容许数据最大延迟时间为 2 分钟，则 watermark = 窗口工夫的最大值 +2，通过往 redis 缓存实时聚合两个窗口后果即可实现窗口继续滚动，当事件工夫大于 window1 窗口的 watermark threshold 工夫时，立刻弹出 window1 窗口给 process 处理器判断是否超过异样阈值，若超过则产生运维事件期待自愈，同时将第二个窗口 window2 的数据挪动至第一个窗口 window1 中，从而实现继续滚动成果。

总结：滚动窗口占用缓存空间较少，聚合速度快，有余中央可能存在匹配不精准，如果设置窗口工夫较大，聚合后果达到配置阈值的数据刚好位于两个窗口相连的数据集中，此时是不会触发运维事件的，其次多指标（一个监控指标对应一个固定窗口）匹配运维事件时，会存在多窗口达到水位线后的弹出工夫对不齐的状况，可能存在永远匹配不上的状况。这个时候还需减少窗口之间匹配期待来解决该问题。基于滑动窗口形式可解决以上两个问题。

流式计算之滑动窗口：

多指标滑动窗口; DataEvent 为某个实例监控数据，每分钟上报一次或屡次，数据蕴含 3 个指标项 metrics1、metrics2、metrics3，若配置三个指标项周期聚合后果超过设定阀值则触发运维事件，其周期窗口大小别离为 6 分钟、5 分钟、3 分钟，滑动窗口工夫 1 分钟，容许最大延迟时间为 1 分钟，则在 12:08 分后同时弹出三个窗口数据进行聚合匹配运维事件规定。同时窗口向前挪动，不再参加统计的数据则可不在缓存中保护，如上图带虚线的指标项数据。

4.2 事件收敛及 自愈 管制

事件收敛：

  雷同事件在短时间内屡次产生，自愈事件可能会产生并行执行或在短时间内屡次触发。自愈往往会波及到容器或者服务重启，频繁自愈影响集群稳定性，对此可设置一个静默工夫对事件做收敛，静默工夫未过不再往自愈服务发送事件。

自愈管制：

1. 同一集群下，集群事件与实例事件互斥，即保障在同一时刻只容许集群中的一个节点进行自愈行为。若集群中的实例都在自愈（如垂直扩容），则会导致集群不可用。同集群实例实现串行化自愈可通过 MQ 发送端利用集群 ID 做路由到指定队列上，生产端拉取队列按程序生产实现。如下图所示：

2. 当有新节点增加 / 下线时，会给节点 2 分钟的容忍工夫，避免因为节点刚刚增加到集群 / 或下线的不稳定性导致谬误自愈。

3. 针对自愈解决不了的场景设置自愈次数下限，避免循环自愈，并发告诉。

4. 历史过期事件过滤，每个事件有过期工夫，示意这个事件在产生多久后，会认为过期，事件在决策流程时会先判断是否无效，过期的事件不必再解决。

4.3 故障起因剖析

运维事件触发回调进行故障剖析，剖析根本原因，辨认误运维。拉取运维事件对应的根因剖析策略，次要利用动静指标 + 决策树实现自愈，整个剖析自愈模块可视化。指标：次要是监控项的指标，如零碎负载、cpu 使用率、内存使用率、网络 I /O、磁盘使用率、系统日志、gc 日志等

 e.g 决策树模型

 e.g 节点离线总结论断

4.4 故障自愈

利用根因剖析及异样论断总结，在元数据模块进行可视化的事件处理流程编排以及决策动作、执行动作的配置，当检测到运维事件产生后，联合当时编排的事件处理流，并执行相干的流程动作，实现服务自愈成果。

节点异样解决流编排如下：

5. 总结

通过拉取监控数据，检测匹配异样数据触发运维事件，再联合编排的事件处理流主动实现一些比拟繁琐的自愈行为，整个执行流程可视化、串行化。以上仅例举节点异样事件编排，还可编排磁盘清理、扩容等运维场景，同时积淀故障解决教训造成知识库，回溯过往产生的异样监控数据来提前发现问题，并解决潜在故障。

作者简介

Carry  OPPO 高级后端工程师

目前在 OPPO 中间件个人负责中间件自动化运维的研发，关注散布式调度、音讯队列、Redis 等中间件技术。

更多精彩内容，请关注 [OPPO 数智技术] 公众号