Smarter onboarding and planning with Grafana Assistant: How to ensure observability is baked in from the start

周一的下午，你正在开发的那项功能已经基本完成。但工单底部还有一个未处理的待办事项：“添加监控”。

你清楚应该这么做。你也知道冲刺周期明天就结束了，团队里没有人是可观测性专家，更别提要确定该测量什么，或者如何编写 PromQL 查询了。这感觉就像一个独立的项目。于是，它和往常一样被搁置：“等出问题了再加”。

问题在于，这种“出问题”往往会在几周后的某个随机星期二凌晨两点发生。是的，你还是那个工程师，正在处理同样的服务，但此时没有仪表板，没有有用的信号，只能在高压下进行猜测。为了节省一个下午而跳过的监控，让你损失了一个夜晚，还伴随着缓慢而压力巨大的故障。

事实是：可观测性并非被推迟是因为工程师不关心，而是因为它被视为专家领域且难以提前规划。但考虑到软件开发的快速变化，这种假设值得挑战。

可观测性不是在项目后期才添加的阶段，而是软件构建和运行每个阶段都应做出的决策。而借助 Grafana Assistant，任何团队——无论是否有可观测性专家——都可以真正实现这一目标。

在本文中，我将向你展示如何从最早的阶段开始实现这一点：规划。

认识 Assistant——为什么开源是制胜关键

在讲解如何从一开始就整合可观测性之前，让我们先了解 Assistant——Grafana Cloud 中的上下文感知 AI 代理。你只需用自然语言描述需求，它就能对你的遥测数据采取实际行动：查询数据、起草仪表板、导航到正确位置，并协助你进行调查。

这使任何工程师都能轻松实现可观测性。例如，你是否一直想了解应用程序的问题所在，但苦于没有时间学习 PromQL？现在你只需输入“显示此服务按端点划分的错误率”，几秒钟内就能得到答案。

而真正让 Assistant 与其他 AI 工具区分开来的部分是：开源就是制胜关键。Grafana、Prometheus、Loki、Tempo 和 OpenTelemetry 都是开源、普及且文档详尽的工具。大型语言模型已经吸收了它们的查询语言、惯例和最佳实践。这种专业知识在你输入第一个字之前就已经融入模型。封闭的专有工具无法免费获得这种优势；而开源标准可以。

Assistant 在此基础上进一步将这些能力落地到你的具体环境：你的数据源、你的仪表板，甚至你此刻正在查看的 Grafana 页面。因此，你能够获得开源可观测性社区的集体知识，并将其应用于你的特定技术栈。缺乏专门的可观测性团队不再是障碍，可观测性可以从前端就深度融入，而非被临时附加在项目后期。

越来越多的这类工作在 Grafana Assistant Workspace 中完成，该空间为更复杂的对话和工作流提供了专属的全屏 AI 优先体验。你无需在侧边栏、仪表板和独立报告之间来回切换，Workspace 将对话内容、可视化输出和调查结果统一整合，使你在从规划到实施的整个过程中保持专注。

但这里有个关键点：规划很少从空白页面开始。大多数真实系统都是遗留系统——你构建的任何新功能或服务都需要对接已有的组件，其中一半你并未参与开发。因此，规划可观测性需要两个步骤。首先，你需要了解现状并掌握现有系统的运行情况。然后，你需要从第一天起就将可观测性深度融入到下一个组件的设计中。让我们逐步探讨这两个步骤。

第一步：对接现有系统

规划几乎从未从零开始。在合理添加任何内容之前，你必须先理解你要添加的系统——而这正是大量可观测性工作悄然流失的地方。因此，第一步就是完成对接。

为了说明这在你组织中如何成为现实，让我们通过一个假设场景进行演示。

你负责数十个服务的新团队已经进入工作的第一周。这些服务都不是你构建的，自然地，某些功能已经开始出错。你对架构不了解，不清楚哪个服务负责什么，也不知道关键信号来自哪里。通常情况下，这需要耗费数天在 Slack 中挖掘历史信息，并不断咨询那个记得系统整体架构的人，但如今这一切无需如此。

相反，你可以通过 Assistant 快速掌握情况。只需打开 Assistant，提出一个通常需要资深工程师才能回答的问题：_“绘制结账流程相关的服务图谱，并告诉我当前哪些部分性能下降。”_ Assistant 会逐步分析，从 [知识图谱](https://grafana.com/docs/grafana-cloud/knowledge-graph/?pg=smarter-onboarding-and-planning-with-grafana-assistant-how-to-ensure-observability-is-baked-in-from-the-start&plcmt=in-text)（Grafana Cloud 对服务、依赖关系和信号连接的实时映射）中提取上下文信息。你看到的不再是原始指标的长列表，而是清晰的系统交互图，以及真正存在问题的区域。

这种先发优势正是使用 Assistant 的团队所描述的：

“我很遗憾几年前没有这个工具，当时我们正在做系统对接。我认为它可能能解决我们当时遇到的问题的 50%。” ——Chris Carter，OutSystems 首席软件工程师

深入分析后，你发现真正的问题在于可观测性本身存在漏洞：一个关键服务缺少延迟面板；某个错误指标无人绘制图表。你立即填补这些漏洞。只需描述你的需求——_"展示结账流程的错误率和p99延迟"_——Assistant就会找到数据源，编写PromQL和LogQL查询，并在聊天中实时显示面板，让你在提交前验证真实数据。你只需说：_"将这些转为仪表板"_，它就会进入仪表板模式，构建面板、添加如$service选择器等变量，并直接保存到Grafana Cloud，同时生成返回链接。

在本例中，它真正擅长的几个具体细节：

• 自然语言 → PromQL、LogQL 和 TraceQL：你可以实时看到查询的构建过程，从而逐步学习技术栈。

• 在聊天中实时显示面板：在保存任何更改前就能看到真实数据；无需猜测Assistant的推荐是否正确。

• 仪表板模式：只需描述即可构建和编辑面板、变量及布局。

• @提及现有仪表板、数据源和查询：将任何请求基于你已有的内容进行。

最棒的是，你可以让整个过程——检查知识图谱、拉取仪表板、查找漏洞——变得可重复。通过使用一个Assistant [Skill](https://grafana.com/docs/grafana-cloud/machine-learning/assistant/platform/skills/?pg=blog&plcmt=body-txt)，你可以创建可重复使用的斜杠命令，如/onboard-service。这样一来，下一位新员工可以在几分钟内而非几天内熟悉你的系统，你也将一个痛苦的入职第一周变成了清晰的路径。

“它可能为我们节省了大约一周的入职时间……仪表板部分所花的时间可能只有原来的二分之一或三分之一。” ——Mark Cicoria，Transmute Data

第二步：规划新组件以防止出现缺口

现在你已经了解当前运行的内容，就可以合理规划新组件。而这也是从一开始就添加可观测性带来的最大回报——在服务尚未存在时，同一个帮助你理清思路的Assistant会变得更加有用。

先决定要测量什么，再构建它

在设计阶段，提出问题：_"对于新的支付服务，我应该监控什么?"_ Assistant会借助成熟的方法（如RED（速率、错误、持续时间）和USE（利用率、饱和度、错误））来告诉你哪些信号重要，以及“健康”应是什么样子。它本质上提供了与你原本需要依赖经验丰富的SRE提供的专家指导相同类型的建议。

然后，它将这个计划转化为Grafana的核心：仪表板，这是整个团队可以一目了然并据此进行推理的共享视图。历史上，这一部分需要最多的专业知识和耐心才能正确实现。但在仪表板模式下，Assistant会在你编写一行代码之前，通过聊天完成繁重的工作。它会编写查询语句、布局面板并添加变量，使单个仪表板能够跨所有实例和环境进行扩展。过去需要一周时间调整的初始仪表板，现在服务一上线就准备好了。

如果你已经启用了Assistant，可以通过下方链接立即尝试这个提示：_“为新的支付服务构建一个初始仪表板——按端点划分请求率、错误率和p99延迟，并包含一个$environment变量。”_

决定监控什么是同一对话的一部分，尽管警报规则和SLO本身仍建议通过基础设施即代码或Grafana Cloud UI进行配置。Assistant会帮助你做出判断；你现有的工作流程负责配置。

引入你堆栈的其余部分

由于你需要的上下文分散在代码、拉取请求和事故历史中，可观测性很少只在Grafana中存在。[MCP服务器](https://grafana.com/docs/grafana-cloud/machine-learning/assistant/configure/mcp-servers/?pg=smarter-onboarding-and-planning-with-grafana-assistant-how-to-ensure-observability-is-baked-in-from-the-start&plcmt=in-text) 将这些整合在一起：将Assistant连接到你已经使用的工具——GitHub、Jira、PagerDuty等——它可以通过阅读服务的代码来建议需要监控的内容，交叉参考最近的部署，或调取过去的事故，所有操作都可以在同一个聊天窗口中完成。

结合一个能自动批准所需工具的Skill，你的规划流程可以跨越整个堆栈——这样从一开始就能设计出完整的可观测性，而不是在事故发生后才添加。

回报：出现问题时更快得到答案

这又将我们带回那个凌晨2点的电话——但这一次情况不同，因为可观测性从一开始就已存在。

你在规划时构建的仪表板已经向你展示了当前状况。团队编码的Skill意味着运行手册只需一个命令即可调用。而且通过MCP将Assistant连接到其他工具，最近的部署或解释激增的相关事故也只需一个提问就能获取。只需用自然语言询问：_“过去一小时结账流程发生了什么变化？”_ 不再需要在压力下手动编写PromQL。

这回到了可观测性本应存在的位置：从一开始就内建其中。你沿途分散投入的前期努力——设计时花几分钟，配置一两个Skill——最终会转化为冲刺中最糟糕夜晚时显著加快的答案速度。

Grafana Assistant 是在 Grafana Cloud 中开始使用指标、日志、追踪、仪表板等的最简便方式。我们提供慷慨的永久免费层级，并为每种使用场景都制定了相应的计划。立即免费注册！

标签