grafana（Grafana与LGTM堆栈技能）Skill 是什么？如何下载安装？

Grafana与LGTM堆栈技能：让 AI 帮你把日志、指标、追踪拼成一块看得懂的仪表板

它是一个「可观测性可视化」专用技能：聚焦 Grafana 仪表板设计、面板配置、变量模板化、告警与数据源四大块，同时覆盖 Loki（日志）、Tempo（追踪）、Mimir（指标）组成的 LGTM 堆栈。
产出的是「可落地的配置文件」：仪表板 JSON、数据源 YAML、告警规则、LogQL/TraceQL 查询语句，而不是泛泛而谈的概念解释。
有明确的能力边界：编写 PromQL 查询、设计告警规则策略请交给 /prometheus 技能；一般可观测性架构设计请交给基础设施方向的高级工程师技能。
最适合两类人：需要搭建生产级可观测性体系的高级软件工程师，以及需要给自家服务做指标可视化的普通软件工程师。
一句话结论：把过去「翻文档 + 手写 JSON」的仪表板搭建过程，变成「说清楚需求 + 让技能生成」的两步流程。

1. 该技能叫什么？如何下载安装 AI 技能提升开发效率？

这个技能的中文名是 Grafana与LGTM堆栈技能，英文名 grafana，技能 ID 为 13500。

它解决的是一个很具体的痛点：Grafana 的仪表板本质上是结构化 JSON，面板类型、阈值、单位、图例格式、变量依赖链、数据源 UID 之间的关联极其繁琐。大多数人搭一块像样的仪表板，要反复在官方文档、社区面板 JSON、LogQL/TraceQL 语法页之间来回切换。这个技能把「仪表板设计规范 + 面板选型 + 查询语言 + 数据源供应 + 告警配置」沉淀成一套可被 AI 直接调用的知识，让你用自然语言描述需求，就能得到接近生产可用的配置。

安装前的前提条件：

你使用的 AI 编程助手或客户端需要支持「技能（Skill）」机制，并能加载外部技能包；
技能声明的允许工具为 Read、Grep、Glob、Edit、Write、Bash，安装后需确认这些工具权限已开启，否则技能无法读取仓库里的仪表板 JSON、也无法写入配置文件；
建议在一个已经有 Grafana 配置目录（如 provisioning/dashboards、provisioning/datasources）的项目中启用，效果最直接。

安装的基本思路（一键式）：

打开你所使用 AI 助手的技能市场 / 技能管理入口；
搜索技能英文名 grafana 或技能 ID 13500；
点击安装 / 启用，等待技能加载完成。

具体的安装命令、客户端入口、是否需要登录账号等细节，不同平台差异较大，请以官方说明为准。本技能详情中未提供任何安装命令，因此不建议照搬来源不明的命令行安装方式。

如何验证是否生效：

在对话中直接输入触发词，例如「帮我创建一个 Grafana 仪表板」「写一条 LogQL 查询统计错误日志」；
观察回复是否开始使用本技能的组织方式，例如主动按「概览 → 服务 → 组件」分层、主动询问数据源类型（Loki / Tempo / Mimir）、主动给出面板类型选型建议；
也可以让它输出一段带 templating.list 的仪表板 JSON，若结构符合 Grafana 的 schema，基本可确认技能已加载。

2. 该技能的主要功能和特点

仪表板整体设计：按「层次结构（概览 → 服务 → 组件 → 深挖）」和「黄金信号（延迟、流量、错误、饱和度）」组织面板，遵循 24 列网格、从上到下的信息流布局。
面板类型选型建议：针对时间序列、统计、仪表、条形仪表、表格、饼图、热图、日志、追踪等面板，给出「什么场景该用哪一种」的明确判断，避免出现「用饼图看时间趋势」这类常见误用。
面板细节规范：标题要带单位和上下文、图例用 {{label}} 动态命名、坐标轴必须标注单位、阈值用绿/黄/红三档表达健康度、面板之间用数据链接串起「深挖路径」。
变量与模板化：支持查询变量、自定义变量、间隔变量、数据源变量、常量、文本框六类变量，并支持 includeAll、allValue、正则过滤以及 $datasource → $cluster → $namespace → $app → $pod 这种依赖链式变量。
注释（Annotation）：把部署事件、告警事件以垂直标记叠加在时间序列上，让「指标突变」和「发布动作」在同一张图里对齐。
查询语言覆盖：LogQL（流选择、行过滤、JSON/logfmt/pattern 解析、unwrap、quantile_over_time、topk）与 TraceQL（按服务/状态码/耗时过滤、父子跨度 >>、后代跨度 >>+）。
数据源与告警的代码化供应：给出 Loki、Tempo、Mimir 数据源的 provisioning YAML 范例，以及统一告警的规则、联系点、通知策略配置；支持文件供应、Kubernetes ConfigMap、Grafana Operator CRD 三种 GitOps 路径。
性能与安全实践：单块仪表板面板数控制在 15 个以内、用 $__interval 做自适应采样、避免高基数分组、配置保留期与压缩、启用 RBAC 与多租户隔离。

和「直接问通用大模型」相比，它的差异化在于：输出是成体系的结构化产物，而不是零散的知识点；并且明确标注了不该做什么（不写 PromQL、不做告警策略设计），避免技能越界给出不专业的建议。

3. 如何使用该技能？

第 1 步：用触发词唤起技能。 直接说需求即可，不必记命令。可用触发词包括 grafana、dashboard、panel、visualization、logql、traceql、loki、tempo、mimir、data source、annotation、variable、template、heatmap、gauge、logs panel、traces panel、LGTM stack 等。

第 2 步：把需求描述成「对象 + 信号 + 读者」。 例如：

输入示例：「帮我为订单服务做一个 Grafana 仪表板，数据源是 Mimir 和 Loki，读者是值班同事，需要看请求率、P95 延迟、错误率，以及最近的错误日志。」

第 3 步：让它先给设计，再给配置。 好的输出通常包含：面板清单与类型、每个面板的查询语句、变量定义、阈值设定。你可以先确认面板选型是否合理，再让它落地成 JSON。

第 4 步：要求输出变量定义。 例如要求「用命名空间和应用两个级联变量，支持多选和全部」。技能会按 templating.list 的结构给出 label_values 查询、multi、includeAll 等字段。

第 5 步：让它生成查询语句。 例如：

输入示例：「写一条 LogQL，统计 api 服务里 JSON 日志中 level=error 的每秒条数，按 namespace 分组。」

输出示例：sum(rate({app="api"} | json | level="error" [5m])) by (namespace)

第 6 步：配置数据源与告警。 让它产出 provisioning 目录下的 YAML，例如 Loki 数据源开启 derivedFields 把日志中的 trace_id 链接到 Tempo；告警侧给出规则、联系点（Slack / PagerDuty / 邮件）与通知策略的路由匹配条件。

第 7 步：让它写入文件并自检。 技能具备 Write / Edit 与 Bash 权限，可以把 JSON/YAML 直接落到仓库里，再用 Read / Grep 复核 UID 引用是否一致（数据源 UID、面板 UID 写错是仪表板「空图」的头号原因）。

第 8 步：上线前做验收。 检查三项：单位是否标注、时间范围是否合理（不要默认查几个月）、面板数量是否超标。

4. 同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
本技能（Grafana与LGTM堆栈技能）	面向 Grafana + LGTM 的可视化专用 AI 技能	仪表板设计、面板选型、变量模板化、LogQL/TraceQL、数据源与告警供应	需支持技能机制的 AI 客户端，安装入口以官方说明为准；上手成本低	从零搭仪表板、批量改造存量仪表板、配置 GitOps 供应	优势：产出结构化成体系，内置最佳实践与边界约束；不足：不覆盖 PromQL 深度调优与告警策略设计，需配合 `/prometheus` 技能
Grafana 官方文档 + 手工配置	权威参考与手工搭建	全量功能说明、示例 JSON	无需安装，但需要较强 JSON 与查询语言功底	精细定制、疑难问题排查	优势：最准确、覆盖最全；不足：检索成本高，跨文档拼装耗时长，容易漏掉最佳实践
通用大模型直接问答（不带技能）	通用编码助手	可生成大致可用的仪表板 JSON 与查询	最低，开箱即用	快速草稿、概念答疑	优势：无需安装；不足：面板类型容易选错、UID 与变量依赖链常出错、缺少 LGTM 专项细节
Helm / Grafana Operator 等纯 IaC 工具	基础设施即代码	声明式部署仪表板、数据源、实例	需要 Kubernetes 与 Helm 基础	平台团队统一管控、多集群分发	优势：可重复、可审计；不足：只负责「怎么部署」，不负责「内容怎么写」，仪表板内容仍需人来设计
商业 SaaS 可观测性平台（如托管式监控服务）	一站式商业方案	采集、存储、可视化、告警全托管	开通即用，通常按量计费	不想自建存储与运维的团队	优势：省运维；不足：成本随数据量上升，自定义灵活度与数据自主性弱于自建 LGTM 堆栈

5. 该技能的典型应用场景与实际体验情况

场景一：新服务上线，值班同学要从零搭一块仪表板。 角色是 SRE 或后端负责人。过去要先翻一遍「黄金信号」方法论，再逐个面板试类型。现在只需说明服务和数据源，技能会按「概览 → 服务 → 组件」给出面板清单，并直接标注延迟面板用时间序列、错误率用统计加阈值、延迟分布用热图。 实际体验：上手几乎无门槛，第一版仪表板成型速度快；注意要主动补充「读者是谁」，否则默认按通用模板输出，业务语义会偏弱。

场景二：线上报错，从指标一路查到日志再到追踪。 角色是值班工程师。痛点是错误率面板飘红后，还要切三个系统找证据。技能给出的方案是在仪表板里用数据链接把面板串起来，并通过 Loki 的 derivedFields 把日志中的 trace_id 直连 Tempo，形成「指标 → 日志 → 追踪」一跳到底的路径。 实际体验：跨数据源的关联配置是这个技能比较亮眼的部分，能省掉大量查文档时间；但要注意 datasourceUid 必须与数据源配置里的 uid 完全一致，写错会静默失效。

场景三：平台团队把仪表板纳入 GitOps。 角色是可观测性平台工程师。需求是仪表板不让人在界面上改，全部走代码评审。技能能给出文件供应（providers 配置）、Kubernetes ConfigMap 打标签、Grafana Operator CRD 三条路径，并提示「只读环境可设置 allowUiUpdates: false 与 editable: false」。 实际体验：适合有一定 IaC 基础的团队；初次配置需要理顺目录结构与 folder 映射关系。

场景四：仪表板越加越卡，需要治理。 角色是团队技术负责人。技能会从面板数量（建议单板 15 个以内）、时间范围、$__interval 自适应采样、高基数分组四个方向给优化建议，并指出「热图上过度分组会直接打爆查询」。 实际体验：属于「隐性价值」场景，建议在改造存量仪表板时使用；注意优化建议需要结合自家数据量级校验，不能盲信默认阈值。

6. 该技能能为用户带来的价值

效率层面：把「查文档 → 写 JSON → 调 UID → 改布局」的多轮往返压缩成一次对话，仪表板从想法到可运行版本的周期显著缩短；批量改造存量仪表板时，模板化与变量方案的复用价值更大。

门槛层面：Grafana 的难点从来不是画图，而是「该用什么面板」「变量怎么级联」「数据源怎么串」。技能把这些隐性经验显性化，让不熟悉 LGTM 堆栈的工程师也能产出结构规范、单位清晰、阈值合理的仪表板。

质量层面：内置的最佳实践（24 列网格、单位标注、绿黄红阈值、单板面板上限、避免高基数）会直接体现在产出里，减少「图能看但不可用」的返工。

长期价值：仪表板、数据源、告警全部以代码形式沉淀，配合 GitOps 供应形成可评审、可回滚、可复制的资产；同时因为技能明确了边界（PromQL 与告警策略交给 /prometheus），团队在分工上不容易出现职责混乱。

7. 常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？ A：通过你所使用 AI 助手的技能市场或技能管理入口，搜索英文名 grafana 或技能 ID 13500 启用即可，安装后确认 Read、Grep、Glob、Edit、Write、Bash 工具权限已开放。具体命令、入口与是否收费因平台而异，以官方说明为准。

Q2：它能直接写 PromQL 吗？和 /prometheus 技能什么关系？ A：按技能定义，编写 PromQL 查询与告警规则策略应交给 /prometheus 技能；本技能聚焦 Grafana 侧的仪表板、面板、可视化、变量、数据源、告警配置，以及 LogQL / TraceQL 查询。实践中常见做法是：指标查询思路找 /prometheus，把结果放进 Grafana 仪表板找本技能。

Q3：它适合谁用？新手能用吗？ A：主要面向高级软件工程师（生产级可观测性搭建、LGTM 部署、仪表板架构）与软件工程师（应用仪表板、服务指标可视化）。新手也能用，因为技能会主动给出面板选型与布局规范；但涉及集群部署、存储与保留策略的部分，仍需要基本的运维知识。

Q4：生成的东西能直接上线吗？ A：结构通常可直接使用，但上线前建议验收三点：数据源 uid 是否与你的供应配置一致、时间范围与刷新间隔是否合理、阈值是否符合你业务的真实水位。技能提供的是规范与骨架，业务语义仍需你自己校准。

Q5：和直接用通用大模型问「帮我写个 Grafana 仪表板」有什么区别？ A：通用模型容易在面板类型、变量依赖链、跨数据源链接这些细节上出错，也缺少 LGTM 堆栈的专项配置经验。本技能以内置的设计原则、面板对照表、供应模板与性能安全实践为底座，输出更接近生产可用；同时它明确声明了不该做什么，避免越界给出不专业的建议。