规则引擎基础：核心组件、工作流与 PSI 告警结合点
规则引擎是 PSI 漂移告警系统的“决策大脑”。它负责将原始指标数据与预定义的告警逻辑进行匹配，并输出告警事件。理解其核心组件与工作流，是后续调优规则引擎性能、降低误报与漏报率的前提。
核心组件
一个生产级的规则引擎通常由以下五个核心模块构成，它们协同完成从数据输入到告警输出的完整闭环：
| 组件名称 | 职责描述 | 在 PSI 告警中的角色 |
|---|---|---|
| 数据接入层 | 接收来自 Prometheus、Zabbix、自定义 Agent 等数据源的时序指标。 | 接收 PSI 指标（如 cpu.pressure、memory.pressure、io.pressure）的实时流数据。 |
| 规则仓库 | 存储、版本化管理告警规则（YAML/JSON 格式），支持热加载。 | 存放 PSI 阈值规则、基线漂移规则、复合条件规则。 |
| 规则评估引擎 | 核心计算单元，周期性执行规则条件判断，支持滑动窗口与聚合函数。 | 计算 PSI 指标在窗口内的 avg/max/p99，与阈值或基线比较。 |
| 状态管理器 | 维护告警的“触发-恢复”状态机，防止重复告警与告警抖动。 | 管理 PSI 告警的 Pending → Firing → Resolved 状态转换。 |
| 告警路由与通知 | 根据规则标签将告警事件分发到钉钉、邮件、PagerDuty 等渠道。 | 将 PSI 漂移告警按严重级别、服务维度路由到对应负责人。 |
关键认知： 规则引擎的吞吐量与延迟瓶颈通常出现在“规则评估引擎”和“状态管理器”两个组件上。PSI 告警的高频计算特性（秒级窗口）对这两个组件的性能提出了极高要求。
规则引擎工作流
一次完整的 PSI 告警评估遵循以下 6 步流水线。理解每一步的耗时与资源消耗，是调优的起点。
- 数据摄取：数据接入层从消息队列（Kafka / NATS）拉取 PSI 指标点，进行格式校验与时间戳对齐。
- 规则匹配：根据指标名（如
node_pressure_cpu_waiting_seconds_total）查找关联的规则组。 - 窗口聚合：评估引擎从时间序列数据库中读取滑动窗口（如 5 分钟）内的原始数据点，执行
rate()、avg_over_time()等计算。 - 条件判定：将聚合结果与规则中的阈值或动态基线进行对比，输出布尔结果。
- 状态跃迁：状态管理器根据判定结果更新告警状态机（Pending → Firing 或 Firing → Resolved）。
- 事件分发：将状态变更事件封装为告警 Payload，推送到路由层。
与 PSI 告警的结合点
规则引擎与 PSI 告警的结合并非简单的“阈值比较”，而是需要针对 PSI 指标的独特语义进行深度适配。以下是三个核心结合点：
- 滑动窗口与压力累积效应：PSI 指标反映的是任务因资源匮乏而等待的累积时间。规则引擎必须使用
rate()或irate()函数将累积值转换为每秒压力率，再与阈值比较。直接使用原始 counter 值会导致误报。 - 多级阈值与状态机：PSI 告警通常设置“警告（Warning）”和“严重（Critical）”两级阈值。规则引擎的状态管理器需要支持多级状态跃迁，例如：
OK → Warning → Critical → Warning → OK，并配置不同的冷却时间。 - 动态基线 vs 静态阈值：对于业务流量波动的服务，静态阈值容易产生大量误报。规则引擎应支持基于历史数据的动态基线算法（如 3-sigma、移动平均），将 PSI 当前值与基线偏移量进行比较，而非固定数值。
实战建议： 在规则仓库中为 PSI 告警规则打上
psi_type: cpu|memory|io 标签，并在路由层根据标签进行差异化处理。例如，CPU 压力告警直接路由到 SRE 值班组，而 IO 压力告警需要同时通知存储团队。
规则引擎架构总览
下图展示了规则引擎各组件与 PSI 数据流的集成关系，帮助你在调优时快速定位问题模块。
常见陷阱： 不要将规则仓库直接放在共享文件系统上而不加缓存。每次规则评估都去读取磁盘 YAML 文件会导致严重的 I/O 抖动。建议将规则加载到内存缓存中，并通过 Watch 机制增量更新。