一键导入
n9e-modify-dashboard
修改夜莺(n9e)上已存在的监控仪表盘。当用户要求改某个仪表盘的变量、检查并修复变量、修改图表/曲线(改 PromQL、legend、单位、增删曲线)、重命名图表、改图表类型(如数值图改曲线图)时使用。区别于"从零创建仪表盘"(那是 n9e-create-dashboard)。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
修改夜莺(n9e)上已存在的监控仪表盘。当用户要求改某个仪表盘的变量、检查并修复变量、修改图表/曲线(改 PromQL、legend、单位、增删曲线)、重命名图表、改图表类型(如数值图改曲线图)时使用。区别于"从零创建仪表盘"(那是 n9e-create-dashboard)。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
**创建告警规则**。优先复用 integrations 里验证过的规则(标准组件 Linux/MySQL/Redis/Kafka/PostgreSQL/Elasticsearch 等都有现成规则包),导入几条按用户需求来——单条、一批、或整套都行;integration 里没有贴合的规则时再手写自定义规则。支持 Prometheus / Loki / ES / OpenSearch / MySQL / PG / TDengine / ClickHouse / Doris / VictoriaLogs / Host 全部数据源。 ⚠️ **不要用这个 skill 做批量 YAML 导入**——用户给的是 URL 或 YAML 文件、awesome-prometheus-alerts、node-exporter.yml 之类,请改用 n9e-import-prom-rule。 触发:创建一条/加一条告警 / 帮我建个 CPU 告警 / 给 MySQL 加套告警规则 / 给主机配上常用告警 / 我要监控某个指标。
夜莺(n9e)告警屏蔽规则(alert_mute)的创建、编辑、排障一站式助手。当用户要求"创建屏蔽规则 / 屏蔽告警 / 静默告警 / 维护窗口免打扰 / 周期性屏蔽 / 每天凌晨屏蔽 / 调整或延长屏蔽 / 屏蔽不生效排查"时使用。屏蔽作用于事件评估阶段(被屏蔽的事件不落库不通知);要配"哪些事件通知给谁"用通知规则(→ n9e-notify-rule-copilot),要查"为什么没收到通知"走告警排障(→ n9e-alert-rule-troubleshoot)。
夜莺(n9e)告警订阅规则(alert_subscribe)的创建、编辑、排障一站式助手。当用户要求"创建订阅规则 / 订阅告警 / 告警事件转发 / 抄送另一个团队 / 告警升级(持续 N 分钟未处理再通知谁)/ 跨业务组收告警 / 订阅不生效排查"时使用。订阅是通知阶段对事件的"复制+二次路由";要配"事件直接通知给谁"用通知规则(→ n9e-notify-rule-copilot),要不收告警用屏蔽(→ n9e-alert-mute-copilot)。
夜莺(n9e)通知规则(notify_rule)的创建、编辑、复制、排障一站式助手。当用户要求"创建通知规则 / 添加通知策略 / 配置告警通知方式 / 编辑调整通知规则 / 分级通知 / 按业务组或标签路由 / 工作时间与非工作时间不同动作 / 恢复时不打电话 / 修复规则匹配不上"时使用——尤其擅长把自然语言路由需求拆成正确的 NotifyConfig 数组。本技能专注通知规则的路由层:不动通知媒介本身(→ n9e-notify-channel-copilot),不动消息模板(→ n9e-generate-message-template),不查"为什么没发出"(→ n9e-alert-rule-troubleshoot 流程 B)。
创建监控仪表盘。当用户要求创建仪表盘、监控大盘、Dashboard 时使用。
**批量导入 Prometheus 告警规则 YAML 文件**(一次性建一组规则)。专用于处理远端 URL 或本地 YAML 文本,自动解析 `groups` / 纯 `rules` 数组 / 单条 rule 三种格式。 ⚠️ **不要用这个 skill 做单条创建**——用户用自然语言描述一条告警需求时,请改用 n9e-create-alert-rule。 触发:导入 / import / 批量 / URL / .yml 文件 / .yaml 文件 / awesome-prometheus-alerts / node-exporter.yml / prometheus rule file。
| name | n9e-modify-dashboard |
| description | 修改夜莺(n9e)上已存在的监控仪表盘。当用户要求改某个仪表盘的变量、检查并修复变量、修改图表/曲线(改 PromQL、legend、单位、增删曲线)、重命名图表、改图表类型(如数值图改曲线图)时使用。区别于"从零创建仪表盘"(那是 n9e-create-dashboard)。 |
| max_iterations | 16 |
| examples | ["把这个仪表盘的 ident 变量默认值改成 web01","检查下这个大盘的变量有没有问题,顺手修一下","把 CPU 使用率这个图的查询改成只看总核","给内存图表加一条 swap 使用率的曲线","这个面板的单位改成百分比","把第一行的图表从数值改成曲线图"] |
| builtin_tools | ["list_dashboards","get_dashboard_detail","update_dashboard","list_busi_groups","list_datasources","list_metrics","get_metric_labels","query_prometheus"] |
帮用户用自然语言修改一个已经存在的仪表盘,不是新建。三类典型诉求:
| 诉求 | 你要改的东西 |
|---|---|
| 改变量 | 模板变量的取值表达式(definition)、默认值、是否多选(multi)、显示名(label) |
| 检查并修复变量 | 扫描变量定义和图表里对变量的引用,发现坏味道(图表引用了未定义变量、变量取不到值、数据源引用不一致等)并修复 |
| 改图表曲线 | 某个图表(panel)的曲线:查询表达式(PromQL)、legend、单位(unit)、增删曲线、改标题、改图表类型(如 stat→timeseries) |
曲线查询(
queries)编辑仅支持 Prometheus/VictoriaMetrics 面板;SQL/日志类面板(mysql、ck、es 等)只能改单位、标题、说明或删除,传queries会被工具拒绝。
update_dashboard 是提案式写入:你调用它(只传要改的部分)后,工具会计算改动、直接向用户展示改动清单并暂停对话;用户确认后由系统自动落库——确认环节不需要也不经过你。因此:
get_dashboard_detail(id, include_config=true) 读到当前的变量、图表摘要和变量健康检查。update_dashboard,只传要改的 variables/panels/fix_datasource。这一调用就是你本轮的最后一步,系统会接管展示与确认。proposal_id/confirmed(那是系统确认通道的参数)。update_dashboard 即可(旧提案自动作废)。dashboard_id(前端从 /dashboards/<id> 注入,或上轮已确定)→ 直接用,不要再 list_dashboards。/dashboards/<id> 链接 → 从里面取 id。list_dashboards(query="...") 按名匹配;多个候选或匹配不到就列出来问用户,不要乱猜。业务组、数据源都从仪表盘本身读,不要向用户索要。
get_dashboard_detail(id=<id>, include_config=true)
返回里:
variables:每个变量的 name / type / label / definition / multi / default_value / datasource_valuepanels:每个图表的 id / name / type / unit / queries(每条曲线含 ref / promql / legend / instant / step / hide,未设置的字段会省略);折叠行(row)里的图表已被拉平进来variable_lint:变量健康检查命中的坏味道列表(如「图表 X 的查询表达式引用了未定义的变量 $foo」)定位图表优先用 id(如 panel-3),名字可能重复。
改 PromQL 或修变量 definition 时,可先用 query_prometheus / list_metrics / get_metric_labels 验证新表达式确实有数据再提案,避免改完还是空。
修复变量类任务:把 variable_lint 命中项逐条确定修复动作(改 definition / 重命名引用 / 修数据源引用),一并放进同一次提案。
调 update_dashboard,只传要改的部分(其余配置原样保留,工具不会动)。工具会向用户展示改动清单并等待确认,本轮到此为止:
variables(JSON 数组,按 name 匹配):
[{"name":"ident","default_value":"web01","multi":false}]
name 不存在则视为新增一个 query 变量,新增必须带 definition(不带会报错——名字打错会落到新增分支,靠这个守卫拦下来);delete:true 删除。panels(JSON 数组,按 id 优先、否则 name 定位):
[{"id":"panel-2","unit":"percent","queries":[{"promql":"avg(cpu_usage_active{cpu=\"cpu-total\",ident=~\"$ident\"})","legend":"{{ident}}"}]}]
queries 传入即与现有曲线增量合并:按 ref(原曲线 refId)匹配,只覆盖你写的字段,其余字段(step/hide/mode、按 refId 关联的 overrides 等)原样保留;不带 ref 一律视为新增曲线(没有位置匹配)。未在 queries 里出现的现有曲线不会被删、原样保留——所以只改某一条曲线时,传那一条(带上它的 ref)即可,不必把整图所有曲线都列出来。ref(不带 ref 会新增曲线而不是改原曲线);要删某条曲线,在该曲线项上带其 ref 并写 delete:true。new_name 改标题,unit 改单位,description 改说明,type 改图表类型(仅 timeseries/stat/gauge/barGauge/pie/table,改类型会把该图表的类型样式选项重置为新类型默认值,改成 timeseries 时还会清掉曲线上的 instant 标志以恢复范围查询;row 布局行不能改),delete:true(在面板项上)删整个图表。不传 queries 就不动曲线。fix_datasource: true:把图表/变量里悬空或写死的数据源引用统一重指到大盘数据源变量。适合修「图表查不到数据 / 数据源引用不一致」类坏味道。update_dashboard,直接一句话说明原因并给出建议。工具返回的 changes 列表是实际落库的改动项,可据此向用户复述。
=~ 不用 =,如 ident=~"$ident"。{{label}} 形式,如 {{ident}}。list_metrics / get_metric_labels 探一下,别凭空编。update_dashboard 调用(variables 和 panels 一起传);改动清单与确认由系统把关,不会被跳过。