WeOps干货：运维告警CEP窗口机制的3种类型与实战案例

上次我们讲到复杂事件处理（CEP，Complex Event Processing）技术在IT运维告警领域较为惊喜的落地效果，与现在大部分厂商基于重复性规则的方式进行降噪不同，CEP可以挖掘事件里面蕴含的价值。接下来我们来看看在这种流式事件处理的场景中，事件数据是如何处理的。

首先回顾一下告警场景中最基础的元素event，指系统中发生的任何可观察到的变化 ，是最基础的概念，比如服务器CPU使用率发生了变化，它从各个系统中源源不断的集中到统一告警系统中，CEP通过“窗口”的机制把这种无限的事件流划分成有限的 “数据块”，然后系统对这些数据块进行分析处理，下面介绍一下三种窗口类型：固定窗口、滑动窗口、会话窗口。

01. 固定窗口

也叫做滚动窗口，特点是时间长度固定（即系统每一次会处理这个窗口内的数据），并且窗口之间不会重叠。打个比方，设定一个 10 秒的固定窗口，那么就会依次生成[0-10]、[10-20]这样的窗口。

这种窗口处理机制常适用于对时间范围有明确要求的聚合类计算，比如每分钟的用户访问量统计就可以用固定窗口。

02. 滑动窗口

滑动窗口有两个关键参数，分别是窗口大小和滑动步长。它会以固定的步长向前滑动，窗口之间是存在重叠的。例如，窗口大小为 10 秒，滑动步长为 5 秒，那么就会生成[0-10]、[5-15]、[10-20]等窗口。

滑动窗口适用于需要进行实时趋势分析的场景，比如检测 5 分钟内的CPU变化趋势。

03. 会话窗口

会话窗口的边界是由事件之间的间隔时间（会话超时时间）来确定的。如果在规定时间内没有新的事件到来，当前窗口就会关闭，后续的新事件会开启一个新的窗口。说的可能有点抽象，我们举两个例子可能就清楚了：

1. 分析用户的在线会话时长。当用户 A 登录网站后，就会开启一个会话窗口。如果在 30 分钟内用户 A 有持续的操作，那么这个窗口就会一直保持开启状态。一旦超过 30 分钟没有操作，窗口就会关闭。通过这种方式，就能统计出用户 A 的在线会话时长。
2. 流水线构建打包场景，研发提交代码后手动触发CI自动构建流水线，但是流水线执行失败，此时不需要发出告警，因为研发会进行调整重新打包，当流水线最后一次执行失败，然后30分钟内这个流水线没有新的打包记录时，意味着代码侧出现了问题，研发无法短时间内完成出包流程，此时系统识别并触发告警。

在统一告警中心场景中，综合三种独特机制从海量事件中快速定位真正需要关注的问题，减少无效告警的干扰，提升运维效率。