3. 告警自愈剧本架构：触发器、执行器、回滚机制中 PromQL 的角色
告警自愈剧本并非简单的“告警触发→执行动作”线性流程，而是一个包含触发器（Trigger）、执行器（Executor）、回滚机制（Rollback）三个核心环节的闭环系统。PromQL 在这三个环节中承担着截然不同但同等关键的职责：状态判定、参数提取、结果验证。理解 PromQL 在每个环节的角色，是编写高效、安全自愈剧本的前提。
3.1 触发器：PromQL 作为告警与自愈的“准入阀门”
触发器是剧本的起点，负责判断“是否应该启动自愈流程”。PromQL 在此环节的核心角色是状态判定——将原始指标转化为布尔信号，决定是否触发告警并进入自愈剧本。
关键原则：触发器的 PromQL 应保持“窄而准”，避免使用聚合函数掩盖单点故障，同时必须设置合理的
for 持续时间以防止抖动。
| 触发器类型 | 典型 PromQL 模式 | 角色说明 |
|---|---|---|
| 阈值触发 | node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1 |
直接比较指标值与阈值，产生布尔结果 |
| 变化率触发 | rate(http_requests_total[5m]) > 1000 |
基于速率或导数判断异常增长 |
| 预测触发 | predict_linear(node_filesystem_free_bytes[6h], 3600) < 0 |
使用预测函数提前发现趋势性风险 |
| 多条件组合触发 | up{job="api"} == 0 AND on(instance) rate(http_requests_total[5m]) > 0 |
通过逻辑运算符组合多个指标，减少误报 |
优化实践：触发器 PromQL 应避免使用
avg() 或 sum() 等聚合函数将多实例数据合并为单一值，否则会掩盖单实例故障，导致自愈剧本无法针对具体实例执行。
3.2 执行器：PromQL 作为“参数提取器”与“上下文注入器”
执行器是剧本的动作核心，负责执行具体的恢复操作（如重启服务、扩容、切换流量）。PromQL 在此环节的角色是参数提取——从告警上下文中提取执行动作所需的动态参数，例如故障实例 IP、端口、当前负载值等。
执行器通常通过 Webhook 或 Alertmanager 的模板系统接收 PromQL 查询结果。以下是一个典型的参数提取流程：
- 实例定位：使用
up{job="web"}或告警标签中的instance值确定目标主机。 - 上下文获取：执行
node_load1{instance="$instance"}获取当前负载，用于判断是否需要扩容。 - 动作参数注入：将 PromQL 结果作为变量传递给 Ansible、Kubernetes API 或自定义脚本。
# 示例：从告警中提取 instance 并查询当前连接数
# 告警标签：instance=10.0.0.1:9090
# 执行器 PromQL：
node_netstat_Tcp_CurrEstab{instance="10.0.0.1:9090"}
# 输出结果用于判断是否需要执行连接数清理动作
避坑指南：执行器中的 PromQL 应避免使用
offset 或 @ 修饰符指向历史数据，因为自愈动作需要基于“当前最新状态”做出决策。使用历史数据可能导致执行过时或错误的恢复操作。
3.3 回滚机制：PromQL 作为“结果验证器”与“状态确认器”
回滚机制是自愈剧本的安，确保当执行动作失败或产生副作用时，系统能够恢复到安全状态。PromQL 在此环节的角色是结果验证——通过查询指标判断执行动作是否达到预期效果，以及是否需要触发回滚。
回滚机制通常包含两个 PromQL 验证阶段：
- 执行后验证：动作执行后立即查询关键指标，确认故障是否消除。例如，重启服务后查询
up{instance="10.0.0.1:9090"} == 1。 - 稳定性观察：在验证通过后持续观察一段时间（如 5 分钟），使用
rate()或delta()检查指标是否保持正常范围。
# 回滚验证 PromQL 示例
# 阶段1：立即验证服务是否恢复
up{instance="10.0.0.1:9090"} == 1
# 阶段2：观察 5 分钟内错误率是否持续低于阈值
rate(http_requests_total{status=~"5..", instance="10.0.0.1:9090"}[5m]) < 0.01
回滚触发条件：如果执行后验证失败（如服务仍未恢复），或稳定性观察期间指标再次恶化，则触发回滚动作。回滚动作本身也需要 PromQL 验证其有效性，形成递归安。
3.4 三环节 PromQL 角色对比
| 环节 | PromQL 角色 | 查询特点 | 典型函数 | 性能要求 |
|---|---|---|---|---|
| 触发器 | 状态判定 | 窄范围、高频率、布尔输出 | rate(), predict_linear(), <, > |
高（每秒多次评估） |
| 执行器 | 参数提取 | 精确匹配、单实例、实时值 | label_replace(), 直接指标名 |
中（按需查询） |
| 回滚机制 | 结果验证 | 多阶段、时间窗口、趋势判断 | delta(), changes(), resets() |
低（仅在动作后查询） |
3.5 架构总览：PromQL 在自愈剧本中的流动
下图展示了 PromQL 在触发器、执行器、回滚机制三个环节中的流动路径与交互关系：
架构要点：回滚机制的反馈箭头（虚线）是自愈剧本安全性的关键设计。当回滚被触发时，执行器应重新评估当前状态，而非简单重复上一次动作。这要求执行器的 PromQL 必须能够区分“首次执行”和“回滚重试”两种场景，通常通过引入重试计数器标签或查询时间戳来实现。