1. 背景
1.目前中间件容器节点故障、机器资源不足(磁盘大小、内存大小、cpu)等问题时有发生，接入自动化运维后可快速的处理集群异常问题。redis
2.之前处理问题须要人工介入，人力成本较大，运维流程缺少规范。windows
2. 目标
1. 标准化，规范运维流程，制定标准的运维流程。后端
2. 可视化，运维流程可视化、平台化，作到可追踪，可回溯。缓存
3. 自动化，容器重建，进程启停，部分指标经过根因分析实现故障自愈。网络
3. 故障自愈架构图
故障自愈的监控数据采集模块，周期性将采集到的各实例指标数据上报给处理器，处理器经过调用元数据模块获取匹配规则、故障自愈处理流。匹配异常数据成功并生成运维事件，再通过事件收敛过滤以确保没有大批量相同属性(如同业务、机房等)，最后执行对应编排的自愈处理流，运维事件恢复，发送通知，业务恢复正常。session
产品架构图：架构
总体流程图：并发
4. 方案设计
4.1 故障识别
经过拉取实例监控数据、多指标聚合检测识别出异常，并触发故障自动化流程。运维
方案一：过滤型检测监控数据
过滤型检测匹配，只跟数据自己有关，时间窗口设定没有要求，数据来一条处理一条。达到设定的异常阈值时触发运维事件。此检测方案过于粗暴，对于一些监控数据存在瞬时突刺现象也会触发误运维，若频繁自愈会影响中间件稳定性。此方案通常用于告警触发，用做运维触发存在必定风险。分布式
方案二：基于窗口时间检测
窗口选择分类：
固定窗口(fixed windows):设置一个固定的时间长度，实时统计窗口时间内的数据。一般状况会根据key作一些Partition划分，这样能够作一些并发处理，加速计算。
滑动窗口(sliding windows):设置一个窗口长度和滑动长度，若是滑动长度小于窗口的长度，那么就出现一部分窗口会互相覆盖，部分数据存在重复计算；若是窗口长度等于执行周期，那么就是固定窗口的模式；若是窗口长度小于执行周期，就是抽样的计算了。
会话窗口(session windows): 针对的是具体的某个事件，好比特定的人看的视频集合等。会话要等待的数据是不肯定何时到来的，窗口永远是不规整的。
结论：周期性监控数据能够看做相对规律且无穷的数据，故而前两种窗口模式作流式计算比较适合。
窗口时间选择：
基于计算时间的窗口处理问题是很是简单的，只要关注窗口内的数据就能够了，数据完整性也不用操心。可是实际的数据里确定带有事件时间，这个时间的数据一般在分布式系统中也是无序的，要是系统出现某些点的延迟，那么获得的结果其准确性就大大下降了。基于事件时间对于业务准确性有很明显的好处，可是也有很明显的缺点，由于数据延迟，在分布式系统很难说这段时间内，数据已经完整了。
数据完整性保障：
显然不管窗口给的多大，永远没法保证，符合窗口内事件时间的数据必定可以准时到达，利用watermarks （水位线）能够解决何时认为数据结束关闭窗口进行计算的问题。以下图：
设定固定窗口2分钟聚合计算，获得的4个窗口聚合结果分别是六、六、七、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个指标项metrics一、metrics二、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数智技术]公众号