| name | n9e-analyze-dashboard |
| description | 分析夜莺(n9e)上某个仪表盘在一段时间内的数据健康状况。当用户要求"分析某仪表盘有什么问题"、"看看 xx 大盘最近 24 小时正不正常"、"巡检这个大盘"、"这个 dashboard 有没有异常"时使用。区别于修改仪表盘(n9e-modify-dashboard)和创建仪表盘(n9e-create-dashboard)。 |
| max_iterations | 12 |
| examples | ["分析下 etcd 仪表盘 24 小时内数据有哪些问题","看看 Linux 主机监控大盘最近一小时正常吗","巡检一下这个大盘","这个仪表盘里 web01 这台机器最近一天有没有异常"] |
| builtin_tools | ["list_dashboards","get_dashboard_data","get_dashboard_detail","query_prometheus","list_busi_groups"] |
| tags | ["internal"] |
Skill: 夜莺(N9E) 分析仪表盘
帮用户分析一个已存在仪表盘在指定时间窗内的数据健康状况，产出异常清单与建议。
核心工具是 get_dashboard_data：它在服务端完成取数与统计预筛（MAD 离群、突变、趋势、同比四种确定性检测 + 周期性降噪），返回分层结果。同比基准：窗口 ≤24h 比昨日同时段，更长窗口环比上一个同长周期（digest 头部会写明前移量，按它表述）。检测已经做完了，你的职责是归因、关联和解释，不是逐点重新扫描。
第一步：定位仪表盘
- 上下文里已带
dashboard_id（前端从 /dashboards/<id> 注入）→ 直接用。
- 用户贴了
/dashboards/<id> 链接 → 取 id。
- 只给了名字 →
list_dashboards(query="...") 按名匹配；多候选或匹配不到就列出来问用户，不要乱猜。
第二步：调 get_dashboard_data
get_dashboard_data(id=<id>, time_range="24h")
time_range 按用户意图传（"最近一天"→24h，"这周"→7d）；用户没说就用默认 1h，并在结论里注明分析窗口。- 用户限定了主机/集群等条件（"看看 web01 这台"）→ 通过
vars 传：vars={"ident":["web01"]}（变量名以 get_dashboard_detail(include_config=true) 里的变量定义为准，拿不准先查一下）。
- 一次调用就够。不要先调 get_dashboard_detail 再逐面板 query_prometheus 跑全量——那是工具已经替你做掉的事。
第三步：解读预筛结果（你的核心价值）
工具返回分层结果：⚠ 可疑曲线（特征+采样点）/ ✓ 正常摘要 / 略过清单（含平直线一类——值恒定的曲线单独计数；若平直但与昨日水平不同，会按同比异常进可疑区，如 qps 卡死在 0）。你要做的：
- 跨面板关联：同一时刻多条曲线异动是最重要的信号。比如
14:32 CPU 突变 +312% 与 14:32 磁盘延迟离群 同现 → 大概率同一事件，合并成一个问题陈述，而不是罗列两条。
- 结合指标语义判断影响：WAL fsync 延迟上升 → 写入受影响；连接数趋势上涨逼近上限 → 容量风险。讲"这意味着什么"，不是复读数字。
- 复核"疑似周期性"标记：被标周期性的尖峰通常是定时任务，一般不算异常；但若用户问的就是"为什么每天这个点慢"，它反而是答案。
- 必要时下钻：对关键可疑指标用
query_prometheus 缩小时间窗看细节（如突变前后 ±15 分钟、step 调小），或查相关指标验证假设。最多下钻 2-3 个最关键的，不要每条可疑曲线都查一遍。
- 不要复述采样点：附带的"点:"序列是给你看形状的证据，结论里引用关键时刻和数值即可。
第四步：输出分析报告
## <仪表盘名> 健康分析（窗口 24h）
**总体结论**：一句话（如：发现 1 起疑似磁盘性能事件，影响 etcd-2 节点；其余指标正常）
### 异常（按严重度）
1. **etcd-2 磁盘性能劣化（14:30 起）**
- 证据：WAL fsync 延迟 4ms→89ms（突变+312%@14:30，同比窗口无此现象）；CPU 同时刻冲到 96%
- 影响：写入延迟会被直接拉高
2. ...
### 关联分析
（多指标在时间上的关联推断）
### 建议
- 可操作的下一步（查 etcd-2 所在宿主机磁盘 / iostat / 是否有快照任务...）
- 无可疑曲线时明确说"未发现异常"，不要硬编问题；注明覆盖范围（窗口、被跳过的面板）。
- 输出被截断（超大盘）→ 用
panel_ids 对关键面板分批再调，最后合并结论。
边界与特殊情况
- 整盘没有 Prometheus 面板 → 工具会报错并列出数据源分布，直接向用户说明暂不支持。
- 变量未取到值时工具会注明"已用 .* 全匹配"，多实例大盘数据可能偏多，结论里带上这个前提。
- "昨日有、今日无"的曲线（实例消失）值得在异常里提一句——掉实例往往比指标波动更严重。注意窗口 >24h 时这一段实际比较的是上一个同长周期（如上个 7 天），表述时别说成"昨天还在"。
- 用户接着要改大盘（加图表/改阈值）→ 加载 n9e-modify-dashboard；要对异常指标建告警 → 加载 n9e-create-alert-rule。
注意事项
- 报告里时间一律用工具返回的时刻格式（HH:MM），别自行换算时区。
- 数字保留工具给出的精度即可，重点是趋势和量级，不是小数位。
- 可疑 ≠ 故障：检测是统计性的，结论用"疑似/可能"的措辞，把判断依据讲清楚。
