3. OPA 策略引擎入门:OPA 架构、Rego 语言基础、策略决策模型

在容量规划场景中,告警规则往往需要根据集群规模、业务时段、预算约束等动态条件进行调整。Open Policy Agent (OPA) 提供了一种统一的、上下文感知的策略决策引擎,能够将“何时告警”、“告警阈值是否合理”等决策逻辑从 Prometheus 告警规则中解耦出来,实现策略即代码(Policy as Code)。

3.1 OPA 核心架构

OPA 采用客户端-服务器(C/S)架构,核心组件包括 OPA Agent、Rego 策略库 和 外部数据源。其核心思想是:将决策逻辑(策略)与决策所需的数据(上下文)分离。

架构要点: OPA 不负责执行动作,只负责回答“是否允许”或“应该怎么做”。在容量规划场景中,OPA 接收来自 Prometheus 告警管理器的查询请求,结合当前集群的节点数、CPU 配额、时间窗口等数据,返回“是否触发告警”或“告警严重级别”的决策。
OPA 策略决策架构(容量规划上下文) Prometheus 告警管理器 查询决策 OPA Agent 决策引擎 (Rego 运行时) 加载策略 Rego 策略库 告警阈值策略 容量约束策略 外部数据源 集群状态 / 配额 注入上下文数据 决策输出 allow / deny / severity

3.2 Rego 语言基础

Rego 是 OPA 的专用策略语言,灵感来源于 Datalog。它专注于逻辑推理和规则匹配,而非过程式编程。在容量规划中,Rego 用于定义“当集群 CPU 使用率超过 80% 且节点数少于 5 时,触发高优先级告警”这类规则。

3.2.1 核心语法元素

语法元素 说明 容量规划示例
规则 (Rule) 定义决策逻辑的基本单元,形式为 head := body high_cpu_alert := true { ... }
表达式 (Expression) 条件判断,支持比较、逻辑与/或、集合操作 input.cpu_usage > 80
迭代 (Iteration) 使用 some 关键字遍历集合 some node; input.nodes[node].cpu > 90
默认值 (Default) 为规则设置默认结果,避免未定义 default allow_alert = false
内置函数 提供字符串、时间、聚合等操作 time.now_ns() 获取当前时间戳

3.2.2 一个完整的 Rego 策略示例

以下策略用于判断是否应该触发“集群容量不足”告警。它结合了 CPU 使用率、节点数量和业务时段三个维度。

package capacity.alert

import future.keywords.if
import future.keywords.in

# 默认不允许触发告警
default allow_alert := false

# 定义业务高峰时段(UTC)
business_hours := {"start": 8, "end": 20}

# 规则:如果当前时间在业务高峰时段,且 CPU 使用率超过 75%,则允许告警
allow_alert if {
    current_hour := time.now_ns() / 3600000000000 % 24
    current_hour >= business_hours.start
    current_hour < business_hours.end
    input.cpu_usage_percent > 75
}

# 规则:如果当前时间在非高峰时段,且 CPU 使用率超过 90%,则允许告警
allow_alert if {
    current_hour := time.now_ns() / 3600000000000 % 24
    not (current_hour >= business_hours.start)
    current_hour < business_hours.end
    input.cpu_usage_percent > 90
}

# 规则:如果集群节点数少于 3,无论 CPU 如何,都允许告警
allow_alert if {
    input.node_count < 3
}

# 输出告警严重级别
alert_severity := "critical" if {
    allow_alert
    input.cpu_usage_percent > 95
} else := "warning" if {
    allow_alert
}
最佳实践: 在编写 Rego 策略时,始终为规则提供 default 值,避免因数据缺失导致决策未定义。同时,利用 import future.keywords 启用更简洁的语法(如 if 和 in),提升可读性。

3.3 策略决策模型

OPA 的策略决策模型遵循 输入-策略-数据-输出 的范式。在容量规划告警联动中,该模型被具体化为以下流程:

  1. 输入 (Input):Prometheus 告警管理器将告警上下文(如指标名称、当前值、阈值、标签)作为 JSON 对象发送给 OPA。
  2. 策略 (Policy):OPA 加载预定义的 Rego 策略文件,这些策略定义了不同场景下的决策逻辑。
  3. 数据 (Data):OPA 可以查询外部数据源(如 Kubernetes API、CMDB)获取集群实时状态,作为决策的补充上下文。
  4. 输出 (Output):OPA 返回一个 JSON 对象,包含 allow(是否触发告警)、severity(告警级别)、reason(决策原因)等字段。
容量规划告警决策模型 输入 (Input) 告警上下文 JSON OPA 引擎 Rego 策略评估 上下文注入 规则匹配 数据 (Data) 集群状态 / 配额 输出 (Output) 决策 JSON 决策示例 allow: true severity: warning reason: "高峰时段"

3.4 与 Prometheus 告警的集成点

在容量规划实战中,OPA 通常作为 告警路由的决策中间件 或 告警内容的增强器 存在。以下是两种常见的集成模式:

集成模式 工作方式 容量规划场景示例
告警过滤 Prometheus Alertmanager 将告警发送给 OPA,OPA 根据策略决定是否丢弃、抑制或继续发送。 在业务低峰期,抑制 CPU 使用率 80% 的告警,仅保留 95% 以上的告警。
告警增强 OPA 在决策输出中附加额外信息(如建议扩容节点数、关联的配额 ID),Alertmanager 将其注入告警通知。 当触发“内存不足”告警时,OPA 查询当前集群的剩余配额,输出“建议扩容 2 个节点”。
注意事项: 在集成 OPA 时,务必关注决策延迟。对于高频告警(如每 15 秒评估一次),建议将 OPA 部署为本地 sidecar 或使用缓存策略,避免因网络开销导致告警处理延迟。