能否让系统自己把 redis 重启了，而不是凌晨叫醒人？能，但前提是「安全边界」先设计好，否则自动化会放大故障。
监控的价值不止于「发现异常」，更在于「安全地自动处置」。但自动化处置的第一原则不是快，而是不闯祸------一次错误的自动重启可能比半夜叫醒人代价更高。
核心论点
本篇讲 monitoring-agent 如何把「detect → 根因(RCA) → decide → act → verify」闭环跑起来，且每一步都被安全边界拴住。
闭环状态机
detect（04 巡检的异常信号）
↓
根因 RCA（多源融合，详见下节）
↓
decide（是否处置、处置哪种动作，按 04 告警分级做决策输入）
↓
act（执行动作，默认"只建议不写操作"，写操作经审批后由授权通道执行）
↓
verify（回检指标是否恢复，未恢复则升级人工 / 升级 P0）verify 是闭环的关键：处置后必须回检，确认恢复；未恢复则升级，绝不"处置完就当没事"。
RCA 的数据源：只吃探活 + 指标做不出真根因
monitoring-agent 必须是多源融合器。按信息密度从低到高，应融合 8 类信号：
| # | 信号类型 | 回答的问题 |
|---|---|---|
| 1 | 存活信号（探活） | 谁挂了 |
| 2 | 时序指标（Prometheus） | 哪里劣化、速率多快 |
| 3 | 依赖拓扑（04 篇 /status 矩阵 + dependencies 依赖边，已打通级联归因） |
故障波及范围、根因候选收敛 |
| 4 | 调用链追踪（SkyWalking / Langfuse trace） | 慢请求卡在哪段、跨服务怎么传 |
| 5 | 结构化日志 | 具体报错堆栈/错误码 |
| 6 | LLM 业务信号 | 基础设施问题还是模型/路由层问题 |
| 7 | 变更事件（部署/配置/规则灰度/prompt 版本） | 是否"刚改了什么"触发 |
| 8 | 历史模式（过往同类告警归因结论） | 是否老毛病复发 |
性价比最高、最该先接的三类：
| 接入项 | 价值 | 示例 |
|---|---|---|
| 拓扑 × 时序联动 | 依赖边已进 RCA（04 方案 C），把「谁依赖谁」从展示变级联归因输入 | redis 死 → 看拓扑知 shop-agent 依赖它 → 对齐 shop-agent 错误率曲线 |
| 调用链追踪 | 把根因从"服务级"缩到"代码段级" | 知道 P99 飙了，不知飙在 gateway 调下游还是 agent 编排------trace 告诉你 |
| 变更事件 | 现实里大量故障源于此 | 故障前 10 分钟有配置/规则/路由变更 → 根因立刻收敛 |
接入方式：事件驱动 + 零持久化（呼应 04 篇设计原则）：
- monitoring-agent 不轮询、不存储任何监控数据，平时只在收到 Alertmanager webhook 时才被激活。
- 激活后临时查询多源做 RCA：时序查时序库、trace 查调用链后端、日志查日志系统、变更查规则版本------查完即弃，自身不落库。
- 后果：agent 是无状态的分析层，重启无损、可水平扩展；唯一真相源是各专有存储，避免平行存储与双源不一致。
安全边界（核心论点）
自动化处置能不能上线，全看安全边界设计。
| 边界 | 作用 |
|---|---|
| 幂等 | 同一异常重复触发不产生副作用（已重启则不重复重启） |
| 爆炸半径限制 | 单次处置只动故障组件，不动健康组件 |
| dry-run | 危险动作先模拟，确认影响面再执行 |
| 人在回路审批 | 破坏性动作（删数据 / 切流量）走审批闸门 |
| 防处置风暴 | 一次网络抖动不触发 50 次重启（分布式锁防重入） |
| 审计轨迹 | 谁、何时、为何处置，可追溯（含 PII 落点，写入前脱敏见 06 跨平面处置总表） |
防 LLM 滥用：双层去重冷却
自愈闭环的「RCA / 决策」要调大模型，比 act 更频繁、更易超量，必须节流入手。
第一道（推送层，交给中枢，零代码）：
| 中枢 | 机制 | 作用 |
|---|---|---|
| Prometheus alert rule | for: 2m |
过滤瞬时抖动 |
| Alertmanager | group_by: [alertname, instance] |
聚合同组告警 |
| Alertmanager | group_interval: 5m |
控同组重复推送 |
| Alertmanager | repeat_interval: 4h |
控再提醒 |
| Loki | ruler / Grafana 告警汇入 Alertmanager | 同享去重冷却 |
agent 收到的 webhook 已是低频聚合后的告警，不是每条原始抖动敲门。
第二道（LLM 调用层，agent 补轻量守卫，中枢做不到）：
Alertmanager 只管「推不推」，管不了「agent 调不调 LLM」。在 /ingest/alert 入口加极薄守卫：
- 指纹 =
hash(alertname + 主组件 + 根因候选)（同根因不同告警名也能合并） - 同指纹
LLM_COOLDOWN（默认 10m）内不重复调 LLM，直接复用上次 RCA 结论或标「已知、观察中」 - act 阶段仍用分布式锁防重入（幂等），与 LLM 调用层解耦
结论 ：90% 去重冷却由 Prometheus/Alertmanager/Loki 承担，agent 只补一个指纹 + 冷却小守卫，不过度设计；自愈决策因此从"每条告警烧一次 token"降为"同异常 10 分钟内最多一次 LLM 调用"。
运维 RBAC：审批落地
"人在回路审批"一句话不够落地------还得回答：谁审、审什么、审多久。
运维角色分三级：
| 角色 | 权限 |
|---|---|
| Viewer | 只看监控面板与告警，不可处置 |
| Operator | 可执行低/中风险处置（清缓存、重启），高风险需审批 |
| Admin | 可审批高风险处置（故障转移、切流量），高危动作需双人签收 |
分级审批映射：
| 风险等级 | 动作示例 | 审批要求 |
|---|---|---|
| 低风险 | 清缓存、触发业务降级 | 自动执行，事后通知 |
| 中风险 | 重启、扩容 | Operator 可直接执行，记录审计轨迹 |
| 高风险 | 故障转移 | 需 Admin 审批 |
| 高危 | 删数据、改拓扑 | 需双人签收 |
审批超时策略 ：凌晨无人响应时，审批 5 分钟超时自动拒绝，降级为告警升级（通知 on-call），绝不因无人审批而自动放行高风险动作------这是 05 篇核心原则"不闯祸"的延伸。
权限模型通用性：角色→权限→审批这套框架不限于运维------同一套「分级授权 + 审批闸门」思路适用于任何高风险操作面（业务侧看资金/数据，运维侧看爆炸半径/恢复难度）。本篇聚焦运维场景，不展开跨域治理。
动作目录
| 动作 | 风险 | 走审批 |
|---|---|---|
| 清缓存 | 低 | 免审批 |
| 触发业务降级 | 低 | 免审批（按 06 跨平面处置总表） |
| 重启网关 / monitoring-agent | 中 | Operator 可执行 |
| 扩容副本 | 中 | Operator 可执行 |
| 故障转移 | 高 | 需 Admin 审批 |
| 删数据 / 改拓扑 | 高危 | 双人签收 |
动作分级：可逆性是自治执行的前提
「只建议不写操作」不是能力限制，而是还没到可以安全放开的程度。真要放开自治执行，先按可逆性给动作分级（与上述风险分级正交，前者看爆炸半径、后者看能否反悔）：
| 类别 | 特征 | 能否自动执行 |
|---|---|---|
| read-only | 查日志、验状态，无副作用 | 随时 |
| reversible（可逆） | 重启、回滚、扩容，可反悔 | 限定条件自动（预检 + 事后 verify） |
| irreversible（不可逆） | 删数据、改配置，无法反悔 | 强制审批，绝不自动 |
外加三条硬约束：预检 （执行前模拟确认影响面）、verify （执行后回检，未恢复升级）、熔断 （同一动作连续失败 N 次 → 停止自治、转人工）。错误的自愈比半夜叫醒人更贵------这是「不闯祸」原则在"允许自动执行"这条线上的守门员。熔断与防处置风暴分工：熔断管"动作反复失败"（横向，单动作多轮），分布式锁管"并发重入"（纵向，多实例同一时刻），两层叠加才完整。
自研边界：不变量留给薄壳，深度调查交给成熟引擎
市面有成熟的 AIOps/RCA 产品（Aurora、IncidentFox、ninoxAI 等）------服务发现、依赖图谱、告警收敛、LLM 根因分析、Slack 通知它都有，甚至自动生成修复 PR。那自愈闭环为什么还自研？因为通用产品替代「功能」、替代不了「不变量」：
| 不变量 | 通用产品的默认行为 | 冲突点 |
|---|---|---|
| 只建议、不写操作 | Aurora 反而自动生成修复 PR | 与「RCA 只产建议、自愈由审批放行」直接冲突 |
| 无旁路 / 唯一计量点 | 不理解「网关是唯一 LLM 计量口」 | 引擎自身调模型也须走网关带 monitoring tag |
| 审计轨迹 | 写操作留痕，但 PII 边界需自配 | 处置动作写入前须脱敏（06 跨平面） |
边界划分 ：detect 巡检、级联归因的规则主线、审批闸门、审计轨迹留自研薄壳；agentic 深度调查、知识图谱、RAG 复盘交给成熟引擎（Aurora / IncidentFox）。若外购引擎，它的 LLM 调用必须走网关计量、它的自动执行必须挂在同一审批/熔断/审计之下------不变量不随组件外购而外移。
与「动作分级」的关系：薄壳默认「只建议不写操作」，但这不妨碍在满足全部前置（可逆性分级 + 预检 + verify + 熔断 + 审批闸门）后放开 reversible 类自动执行------「只建议」是默认态，不是永久态；自治执行不是薄壳的能力升级，而是同一套安全边界全部就位后的条件放行。
核心要点
- 自动处置的价值不在「快」，在「不闯祸」------安全边界（幂等 / 爆炸半径 / dry-run / 人在回路 / 防风暴 / 防 LLM 滥用 / 审计）设计决定它能否上线。
- 防 LLM 滥用用双层去重冷却 ：推送层交给 Prometheus
for:+ Alertmanagergroup_by/group_interval/repeat_interval（零代码），LLM 调用层由 agent 指纹 +LLM_COOLDOWN轻量守卫兜底------同异常 10 分钟内最多一次 LLM 调用，不过度设计。 - 自愈闭环能跑起来的前提是 RCA 多源融合：把"检测到异常"升级为"知道为什么"，拓扑 × 时序、调用链、变更事件是性价比最高的三类接入。
- 无状态 + 事件驱动 + 零持久化：monitoring-agent 不存储监控数据，只临时查询各专有存储做分析，重启无损、可水平扩展。
- 运维 RBAC 用三级角色分级审批兜底高风险动作，审批超时绝不自动放行------是"不闯祸"原则在权限层的延伸。
- 动作分级看可逆性：read-only 随时、可逆（重启/回滚）限定条件自动、不可逆（删数据/改配置）强制审批，外加预检 / verify / 连续失败熔断。
- 自研边界：不变量（只建议、无旁路、审计脱敏）留给薄壳；agentic 调查与自治执行可外购成熟引擎（Aurora/IncidentFox），但其 LLM 调用须走网关计量、执行须挂同一审批/熔断/审计之下。
- 「只建议不写操作」是默认态不是永久态：全部安全边界（可逆性分级 + 预检 + verify + 熔断 + 审批闸门）就位后，可条件放行 reversible 类自动执行。