How to measure and improve instrumentation quality for better full-stack observability

现代工程团队对所有系统进行监控，指标、日志、追踪和性能分析数据同时从数百个服务中流动。但全栈可观测性并非真正关于收集更多遥测数据，而是要拥有一个统一的全局视图，展示服务如何连接到其下方的每一层，包括依赖项、运行的容器和节点，以及解释其行为的日志、追踪和性能分析。

但这些数据背后常常隐藏着一个静默的问题：并非所有监控数据的质量都相同，每个缺失点都会悄无声息地破坏这些连接。

例如，某个服务可能生成指标但没有日志，当你从"出现错误"切换到"展示原因"时就会陷入死胡同。另一个服务可能有日志但缺少有效的service.name或k8s.pod.name标签，导致关联关系断裂，从图谱中消失。第三个服务可能在事件发生前看似健康，但发现其追踪数据从未接入，最需要时追踪链却戛然而止。

为了解决这个问题，Grafana Cloud的知识图谱现在包含监控质量报告：这是一个自动持续更新的评估系统，用于衡量每个服务的监控质量，实质上就是评估它们如何融入全栈视图。

在本文中，我们将逐步讲解如何解读监控质量报告、评分机制的工作原理，以及如何利用它系统性地提升可观测性，确保你的技术栈各层在所有服务中保持连接。

什么是监控质量？

监控质量是衡量特定服务遥测数据完整性和正确性的指标，基于一组自动化检查进行评估。

每个服务都会通过一组由服务器计算的质量检查进行评估：这些检查是小型、聚焦的规则，用于验证服务遥测数据的某个具体方面。

几个示例：

• 服务是否生成日志？

• 是否存在服务图指标？

• 服务名称格式是否正确（无多余斜杠，service.namespace有效）？

• 是否附加了预期的Kubernetes标签，以便服务能与容器、节点和集群进行关联？

其他检查涵盖跨度指标、性能分析、指标基数等，每个检查验证不同的信号或连接。

将该列表视为连接网络而非合规性清单会更有帮助。服务拓扑图指标将服务与其上游和下游依赖项关联。跨度指标和追踪数据揭示了整个调用链路中的请求路径。Kubernetes标签将其锚定到运行的Pod、节点和集群。日志和性能分析则将其与自身的错误行和热点代码路径关联。而一个格式良好的service.name是将所有元素整合到图谱中的关键身份标识。若遗漏其中一项，整个全栈视图的一个层级将悄然消失。

根据这些检查的状态，每个服务会获得一个单一的质量评分，并映射到可读性更强的等级，使您能一目了然地判断服务是否已良好监控或需要改进。

质量等级 | 含义 | 分数范围 ---|---|--- 不完整/差 | 几乎未监控；大多数检查失败 | 0-10% 差/差 | 监控存在重大缺口 | 11-25% 一般/良好 | 核心监控存在，仍有改进空间 | 26-50% 良好/非常好 | 已良好监控，有少量改进建议 | 51-99% 完美 | 所有适用检查均通过 | 100%

因此，评分的提升不仅仅是让监控清单更整洁，更是衡量全栈可见性的指标，体现了在关键时刻您实际能追踪到的系统栈深度。

[为什么使用Grafana Cloud衡量监控质量：一个示例](https://grafana.com/blog/how-to-measure-and-improve-instrumentation-quality-for-better-full-stack-observability/#why-use-grafana-cloud-to-measure-instrumentation-quality-an-)

其他工具只能告诉您服务是否在生成数据。通过监控质量报告，Grafana Cloud的知识图谱会告诉您这些数据是否足够用于故障排查，以及在数据不足时需要修复哪些部分。

[一次值班经历](https://grafana.com/blog/how-to-measure-and-improve-instrumentation-quality-for-better-full-stack-observability/#a-day-on-call)

假设结账服务开始超出其延迟SLO。其监控质量报告显示为绿色：服务拓扑图指标、Kubernetes标签、日志和追踪数据都已就绪，说明您需要的关联关系完整无缺。

您通过服务拓扑图定位到一个缓慢的支付依赖服务。从那里，Kubernetes标签将支付服务连接到运行的节点，发现CPU已饱和。随后您可以跳转到服务日志查找超时错误，并通过追踪确认根本原因。结账 → 支付 → 节点 → 日志 → 追踪。由于监控已正确连接，您可以顺畅地跨栈追踪问题而不会遇到死胡同。

同周的一个兄弟服务则呈现相反情况。它在指标中出现，但在图谱中完全缺失：没有依赖项、没有邻居，追踪信息几乎立刻中断。监控质量报告解释了原因：service.name中一个多余的斜杠使其从图谱中消失，且该服务未生成日志。这两个断开的连接导致全栈视图无法构建。

两次事件之间唯一的实质性差异并非是每个服务生成的监控数据量，而是这些连接信号是否存在。质量报告使这些缺失的连接可视化，让您能在下次凌晨3点告警出现前就进行修复。

[查找并修复监控缺口](https://grafana.com/blog/how-to-measure-and-improve-instrumentation-quality-for-better-full-stack-observability/#find-and-fix-instrumentation-gaps)

监控质量报告将模糊的"提高可观测性"指令转化为优先级待办事项列表。监控质量标签页会对每个服务进行评分并显示其失败检查项，帮助您快速定位需要重点关注的服务。每个发现的问题都具备可操作性而非仅用于诊断：每个失败检查项都会附带影响说明、指向具体配置文档的链接，必要时还会提供Explore查询按钮，可在数秒内确认缺口。

该报告无需额外配置，且会随着服务变更自动保持最新。服务被发现时会自动评分。无需构建仪表板或编写规则，检查项内嵌了Grafana自身的监控最佳实践，因此评分提升是可观测性成熟度的客观衡量标准。

您可以在两个位置查看监控质量，覆盖从跨集群发现问题到单个服务修复的完整工作流：

列表视图（实体目录 → 监控质量标签页）：跨集群的表格视图，对每个服务进行评分并显示失败检查项，帮助您快速识别和优先处理需要关注的服务。

服务视图（实体抽屉/实体页面 → 质量报告标签页）：针对单个服务的报告，明确列出通过和失败的检查项、影响说明、相关文档以及验证每个缺口的查询语句。

以下是详细说明：

[列表视图：跨集群发现并优先处理缺口](https://grafana.com/blog/how-to-measure-and-improve-instrumentation-quality-for-better-full-stack-observability/#list-view-find-and-prioritize-gaps-across-your-fleet)

该视图提供可筛选的表格，展示每个服务及其监控健康状况。每行包含：

• 洞察：服务的健康/断言指示器（知识图谱"圆圈"图标）

• 名称：服务名称及其环境和命名空间作为副标题（由于相同名称可能存在于不同作用域中）。点击可打开实体抽屉。

• 质量：进度条加上分级标签（差/良好/非常好/完美）

• 失败检查项：第一个失败检查项，以及+ N徽章显示其他失败检查类型数量

• 质量报告：直接跳转到该服务抽屉质量标签页的按钮

您可以按失败检查类型筛选（支持多选）、按服务名称搜索，并按环境、站点和命名空间限定范围。标签页徽章显示当前筛选条件匹配的总服务数。如需在Grafana Cloud之外使用数据，下载CSV按钮可导出当前页面结果。页眉还包含重新运行检查按钮，可按需刷新整个堆栈的质量报告，而无需等待每日周期。

抽屉标签页徽章始终显示该服务当前的失败检查项数量。

通过 Grafana Assistant 和 gcx CLI 也可以访问检测质量报告。向助手询问某个服务的检测质量或哪些服务需要重点关注时，它会直接在对话中显示评分和失败检查项。

如需了解如何使用检测质量报告，请查阅我们的 技术文档。

总结

良好的检测是您依赖的每个仪表板、告警和调查的基础，但随时间推移可能会悄然退化。Grafana Cloud 知识图谱中的检测质量报告能清晰展示所有缺失项并提供可操作的建议，为每个服务分配质量评分、列出优先级缺失项，并提供修复指导。

您可以在事件发生前发现并修复遥测数据的缺口，而非在事件发生时才意识到这些问题。