- 先拉取集群元信息（部署形态/parent_id/keyspace 等），据此确定指标路由范围  
- 按给定时间窗收集诊断证据（事件/重启、OOM/重启原因、关键组件资源与错误日志、TopSQL/慢查询概览）  
- 关联“重启→直接触发信号（OOM/killed/panic/eviction/升级）→资源/流量/查询变化”的证据链，给出最可能根因与影响面  
- 输出处理建议（止血、定位、长期治理）并标注需要你确认的信息（如是否发生扩缩容/变更）仅在确实缺失时询问**Root Cause**: 在该时间窗内，未观察到任何“异常重启（如 OOM / crash / 资源枯竭）”的证据；若确有组件重启，最可能是计划内的滚动重启/运维变更（升级、配置变更、手工重启），且对业务影响很小。

**Key Evidence**:
1. **资源与热点排除**：Infra gate 为 `INFRA CLEAR`；Hotspot gate 为 `not detected`，TiDB/TiKV CPU 利用率均处于低位（最高约 45% quota），不符合“负载打满导致重启/雪崩”的形态（`evidences/evidence_summary_for_agent.txt`）。
2. **OOM 排除**：该窗内 `oom_record` 诊断文件数量为 0（`evidences/files.json`）。
3. **异常日志排除**：按 “OOM/Killed/panic/fatal/restart/exit/signal” 关键字检索 TiDB/TiKV/PD 日志，结果为 0 行命中（`evidences/logs.json`）。
4. **用户侧性能影响轻微**：TiDB handle-query P99 峰值约 0.015s；TiKV gRPC P99 峰值约 0.194s（整体均值约 0.055s），未显示显著抖动（`evidences/evidence_summary_for_agent.txt`）。

**Causality**:（推断链）计划内滚动重启/变更 → 组件短暂重启但资源不紧张、无异常日志/无 OOM → 查询延迟与热点指标整体保持稳定 → 业务影响偏低。

**Ruled Out / Not Relevant**: 未发现 EBS/IO 问题、CPU 热点、OOM、panic/异常退出日志；慢查询里出现 `ANALYZE` 但按规则不作为主因（且本窗无 TopSQL 可用于证明其主导资源消耗）。

**Severity**: Low（从延迟与资源视角看，该窗更像“无明显性能事件”的运维动作窗口）。

**Recommendation**:
1. **补齐“重启”的直接证据**：当前 Activity Hub 事件查询返回 500（无法拿到变更/重启事件流），建议在 Clinic 侧修复后重跑该窗的 activity-events；同时检查运维记录/升级记录/K8s Event 以确认是否为滚动升级或手工重启。
2. **修复可观测性缺口**：TopSQL 拉取失败（Delta Lake 路径错误导致 500），建议先修复 TopSQL 数据链路，否则无法做“CPU 归因→根因 SQL/内部操作”的确定性判断。
3. **顺带的性能治理（非本次重启主因判断）**：慢查询 digest `7a1170...` 对 `account_ranking` 的 `joined_account_id = ?` 走了 `TableFullScan` 且 `indexes_used: None`，单次处理 keys 近 100 万；建议为 `account_ranking(joined_account_id)` 建立合适索引并复核执行计划，避免在高峰时放大 TiKV unified_read 压力。