n9e-analyze-dashboard

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）。你要做的：

1. 跨面板关联：同一时刻多条曲线异动是最重要的信号。比如 14:32 CPU 突变 +312% 与 14:32 磁盘延迟离群 同现 → 大概率同一事件，合并成一个问题陈述，而不是罗列两条。
2. 结合指标语义判断影响：WAL fsync 延迟上升 → 写入受影响；连接数趋势上涨逼近上限 → 容量风险。讲"这意味着什么"，不是复读数字。
3. 复核"疑似周期性"标记：被标周期性的尖峰通常是定时任务，一般不算异常；但若用户问的就是"为什么每天这个点慢"，它反而是答案。
4. 必要时下钻：对关键可疑指标用 query_prometheus 缩小时间窗看细节（如突变前后 ±15 分钟、step 调小），或查相关指标验证假设。最多下钻 2-3 个最关键的，不要每条可疑曲线都查一遍。
5. 不要复述采样点：附带的"点:"序列是给你看形状的证据，结论里引用关键时刻和数值即可。

第四步：输出分析报告

## <仪表盘名> 健康分析（窗口 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），别自行换算时区。
• 数字保留工具给出的精度即可，重点是趋势和量级，不是小数位。
• 可疑 ≠ 故障：检测是统计性的，结论用"疑似/可能"的措辞，把判断依据讲清楚。