3. OPA策略引擎入门

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

3.1 OPA 核心架构

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

3.2 Rego 语言基础

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

3.2.1 核心语法元素

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
}

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（决策原因）等字段。

3.4 与 Prometheus 告警的集成点

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