log-diagnosis-controller-recovery-terminate

name: log-diagnosis-controller-recovery-terminate description: >- Controller 精度告警触发的实例「自杀」(terminate) 失败日志诊断。当 precision auto-recovery 应杀 P/D 却未杀、terminate_instance_for_recovery 失败、或 Recovery/NodeManager stop 报错时， 按 Coordinator→Controller→Recovery→NodeManager 链路定位根因。触发词：controller自杀、自杀失败、 terminate失败、precision-auto-recover、精度告警恢复、terminate_instance、Recovery:、实例终止失败、 auto-recovery failed、add_alarm、0xFC001107。 parent: log-diagnosis-framework

Controller 精度自愈 terminate（「自杀」）失败 — 日志诊断

问题描述

「自杀」在本场景的含义：Controller 收到精度问题告警后，主动对指定 P/D 实例执行 terminate_instance_for_recovery（先逻辑隔离 separate_instance，再对各 NodeManager 发 /node-manager/stop）。不是 Controller 进程自身 crash/OOM。

涉及仓库/组件：

典型表现：

• 精度链路已触发，但 P/D Pod/进程仍在跑
• 日志有 precision-auto-recover: failed 或 Recovery: ... partial/failed
• 只有 disabled by config / skip alarm_id / invalid instance_id，从未出现 terminating D

关联问题：

• 告警未到达 Controller → 先查 Coordinator Reporting alarm / Report alarms success
• 精度检测/拨测本身 → 见 Coordinator PrecisionReporter / InternalRouterProbe 日志
• 缩P保D、建链 → 本 skill 仅覆盖 收到精度告警后的 terminate 段

端到端因果链（先建立全局观）

Coordinator: PrecisionReporter threshold → PrecisionAlarm.probe → report_alarms
    → POST /observability/add_alarm (alarm_id=0xFC001107)
Controller: add_alarm → _maybe_precision_auto_recover (若 precision_auto_recovery_enabled)
    → terminate_instance_for_recovery(D, "precision_alarm")
    → terminate_instance_for_recovery(P, "precision_alarm")  # p_instance_id 非空时
Recovery: separate_instance → NodeManagerApiClient.stop × N

alarm_id 常量：PRECISION_ISSUE_ALARM_ID = "0xFC001107"（motor/common/alarm/precision_issue_alarm.py）

配置开关：motor_controller_config.precision_auto_recovery_enabled=true（Controller 启动日志也有 ControllerAPI: precision_auto_recovery_enabled=...）

诊断入口日志

确认问题类型：命中 precision-auto-recover 或 Recovery: 且与 precision_alarm / 0xFC001107 同时间段 → 继续本 skill。

诊断决策树

flowchart TD
  A[用户说自杀失败] --> B{Coordinator 是否上报成功?}
  B -->|无 Reporting alarm / 有 Exception| C[故障U1: 告警未到 Controller]
  B -->|有 Report alarms success| D{Controller add_alarm 是否处理?}
  D -->|无 add_alarm 日志| E[故障U2: 请求未到或日志不全]
  D -->|有 add_alarm| F{precision-auto-recover 分支?}
  F -->|skip alarm_id| G[故障C1: 非精度告警 ID]
  F -->|disabled by config| H[故障C2: 开关未开]
  F -->|skip D/P invalid id| I[故障C3: instance_id 解析失败]
  F -->|terminating D/P| J{Recovery 结果?}
  J -->|instance not found| K[故障R1: 实例不在 InstanceManager]
  J -->|missing after separate_instance| L[故障R2: separate 后丢失]
  J -->|NodeManager stop error| M[故障R3: NM 停失败]
  J -->|terminate ok| N[故障X: 下游未停或看错实例]

分阶段诊断流程

阶段 U：Coordinator 是否把告警送到 Controller

standby 注意：备 Coordinator report_alarms 直接 return，Controller 侧无任何日志。

阶段 C：Controller 是否进入 precision auto-recover

启动时核对：

ControllerAPI: precision_auto_recovery_enabled=True

阶段 R：Recovery / NodeManager 是否真停掉

代码注意：NodeManagerApiClient.stop 在 HTTP 无异常时打 Stop command sent，不校验 response 业务码；若 NM 返回 200 但 body 表失败，日志仍可能显示 sent → 需结合 NM 侧日志交叉验证。

阶段 X：日志显示成功但「看起来没死」

推荐 grep 一键串（Controller + Coordinator）

LOG=/path/to/logs   # 替换为实际目录或单文件

# 上游是否上报
grep -E "threshold reached|probe done|reporting alarm_id|Reporting alarm to controller|Report alarms success|Exception occurred while reporting alarms" "$LOG"

# Controller 是否接单并自杀
grep -E "add_alarm:|precision-auto-recover|Recovery:|Terminate instance|Error sending stop command" "$LOG"

# 排除：仅配置/告警类型问题
grep -E "disabled by config|skip alarm_id|invalid instance_id|skip D|skip P" "$LOG"

按时间戳把 同一次 instance_id / p_instance_id 串成一条时间线再下结论。

诊断输出格式（必须遵循）

## 结论
{一句话：自杀失败发生在哪一阶段，根因是什么}

## 证据链
1. {时间} Coordinator: {日志摘要}
2. {时间} Controller add_alarm: {摘要}
3. {时间} precision-auto-recover / Recovery: {摘要}

## 根因分类
- [ ] U 告警未到 Controller
- [ ] C 配置/告警ID/实例ID 未进入 terminate
- [ ] R InstanceManager 无实例 / separate 异常
- [ ] R NodeManager stop 失败
- [ ] X 日志成功但实际未停（杀错 id / NM 假成功 / 被拉起）

## 建议动作
{改配置 / 修 payload / 查 NM 网络 / 查 InstanceManager 同步 等，1-3 条}

快速诊断表

关联 skill

执行时注意

1. 先分清「没触发自杀」和「触发了但失败」：disabled / skip 属于前者。
2. Controller 与 Coordinator 日志都要看：一半问题在 report_alarms 之前。
3. P 实例 id 为空是设计允许（CDP/PD_SEPARATE 侧可能不感知 P）；若期望杀 P，查 Coordinator p_instance_id 上报。
4. 本 skill 只读日志诊断，不修改代码；除非用户明确要求修复。