Kubernetes 运维团队需要的不只是展示处理器和内存使用量以及错误率的面板。云原生环境的复杂性意味着，单个请求可能经过入口网关、服务、队列、存储和后台进程，而工作负载会不断移动，版本也会持续变化。因此，从 Deployment 层面看，部署可能一切正常，但后续依赖、重试循环，或控制平面某条路径上的压力，可能导致延迟升高。
在 CNCF 博客发表的一篇文章中，Stackgen 的 Neel Shah 解释说，传统监控回答的是预先设定的问题，例如：处理器使用率是否超过某个阈值？错误是否正在增加？而根据文章中的论述，可观测性旨在帮助团队调查一个此前未预料到的问题，从观察症状转向理解原因和范围。
指标开启调查，但不会终结调查
指标仍是自然的起点，因为它们是数字化的，在存储和查询方面高效，适合用于告警和趋势分析。在 Kubernetes 中，指标可以显示节点压力、容器重启、请求延迟升高、API 服务器变慢，或队列元素积累。
文章建议采用面向服务的 RED 模式，即请求速率、错误率和耗时，以及面向基础设施的 USE 模式，即使用率、饱和度和错误。这些指标有助于勾勒事故的初步图景：请求速率上升但延迟保持稳定，与耗时和饱和度上升而流量保持不变，是不同的情况。
然而，将每个细节都转化为指标标签会造成基数（cardinality）问题，因为大量唯一组合会增加成本并降低查询速度。文章特别警告，不要将请求 ID、用户 ID 或近似唯一的值放入指标中；这些细节更适合放在日志或追踪轨迹中。
每种信号回答不同的问题
日志增加了图表通常不会保存的本地上下文。当日志采用结构化格式，并使用一致的字段，例如时间、严重级别、服务名称、命名空间、容器标识、请求路径和追踪上下文时，就更容易将特定事件与生成该事件的服务或进程关联起来。指标可能显示支付服务受到影响，而日志则会揭示超时、异常或依赖失败。
分布式追踪轨迹回答的是另一个问题：单个请求如何在系统中流转，以及时间消耗在哪里？这在 Kubernetes 中尤其重要，因为故障可能分布在多个服务、重试、队列边界或数据库调用之间。传递追踪上下文可以在单个请求上下文中关联不同的跨度，而共享的语义约定有助于统一指标、日志和追踪轨迹中的字段与属性名称。
文章还将性能分析纳入整体图景。在指标确定变慢的服务、追踪确定受影响的请求路径、日志说明本地事件之后，性能分析数据可以帮助确定消耗处理器或内存的函数或代码路径。
事故期间实际会发生什么变化？
文章展示了一个 checkout 服务的示例：新部署后，该服务开始超出延迟目标，而处理器和内存指标仍然正常。指标揭示了问题的存在，随后，一条针对慢请求的追踪显示，大部分延迟发生在支付授权步骤。之后，日志显示出与同一请求上下文相关的重复超时消息。
这一过程将团队从“支付服务为什么变慢了”这一笼统问题，推进到更具体的运维选项，例如回滚依赖项中的变更、降低重试放大，或在调查期间临时转移流量。文章还强调，更好的告警应反映服务质量或可靠性目标面临的风险，而不是基础设施资源的原始异常；文章举例说明了一个告警：响应时间 p99 高于一秒并持续十分钟。
可实施的设计规则
- 从现有指标和日志开始，然后逐步扩大覆盖范围，而不是无目的地收集所有内容。
- 在指标中，优先使用与服务和工作负载相关的维度，而不是高度唯一的标签。
- 在指标、日志和追踪轨迹之间使用一致的元数据结构。
- 将请求 ID 或追踪 ID 添加到日志中，以便在不同信号之间切换。
- 围绕可靠性风险和服务质量构建告警，而不仅仅围绕资源压力构建告警。
- 将可观测性视为应用和平台设计的一部分，而不是部署后的附加功能。
certi.news 的编辑解读：这里的核心价值并不是呼吁购买某种工具或采用单一实现，而是重新定义可观测性的目标。真正发生变化的是数据的使用方式：指标捕捉偏差，追踪确定路径，日志解释事件，而性能分析可能在代码层面确定原因。实际限制仍然很明确；收集更多信号并不能保证获得更好的理解，缺少统一的名称和字段也可能使关联变得脆弱，而唯一性细节可能提高指标成本并削弱查询性能。因此，价值取决于设计质量以及信号之间的关联，而不是信息面板的数量。