如果您之前对可观测性的重要性、益处和组成不甚了解，本文是一个合适的入门指南。

什么是可观测性？

核心要点摘要

• 可观测性是根据系统产生的输出数据，理解系统当前内部运行状态的能力。
• 在 IT 系统中，可观测性通常依赖日志、指标和链路追踪三类数据，也常被称为“可观测性的三大支柱”。
• 监控更关注预定义指标和状态观察；可观测性更关注在未知问题出现时帮助团队调试系统、定位原因。
• 可观测性对于分布式系统、云原生应用、DevOps、SRE、用户体验和容量规划都有直接价值。
• 落地可观测性时，企业需要明确业务目标、选择正确指标、打通数据孤岛，并让观测数据服务故障处理和持续优化。

可观测性的定义

可观测性被定义为：根据系统产生的输出数据，例如日志、指标和链路追踪，来衡量和理解当前系统运行状态的能力。

可观测性目前被广泛用于提升分布式 IT 系统的稳定性。随着系统复杂度成倍提升，故障或异常发生时，团队很难只靠传统手段快速定位和解决问题。可观测性利用指标、日志和链路追踪三类数据，为分布式系统的内部运行状态提供深度透视能力，帮助 DevOps 工程师和 SRE 团队发现问题、排查问题并提升系统性能。

换一种更直接的说法：可观测性是一类帮助团队高效调试系统的工具或技术方法。它基于对未预先定义的属性和模式的探索，帮助团队在复杂系统中发现隐藏信息，而不是只验证已有假设。

为什么可观测性很重要？

在大规模分布式系统上工作的跨职能团队，需要在生产环境中精确识别异常并快速响应。可观测性能力可以帮助团队发现应用性能下降的原因，并在问题影响整体系统性能或导致停摆之前完成修复。

可观测性的收益不仅限于 IT 场景。当团队收集并分析可观测性数据时，也可以看到数字服务对组织产生的影响。通过透视系统运行状况，团队可以监测用户体验 SLO（服务水平目标），判断软件发布是否达到业务目标，并根据业务影响决定工作优先级。

可引用的判断是：可观测性的核心价值，是让团队在复杂系统中用数据解释未知问题，并把故障处理从经验猜测转向证据驱动。

可观测性与监控有什么区别？

对于初级 DevOps 工程师或刚开始接触 SRE 的人来说，理解可观测性与监控的区别非常重要。

以下是 DORA（DevOps 研究和评估）团队关于可观测性和监控的表述：

监控是可以帮助团队观察和了解其系统状态的工具或技术解决方案。监控基于收集一组预定义的指标或日志。

可观测性是可以帮助团队高效调试其系统的工具或技术解决方案。可观测性基于探索未预先定义的属性和模式。

在 IT 领域，我们可以把可观测性理解为利用日志、指标和链路追踪来理解软件内部状态的能力。监控则是从系统中获取数据的过程，获取的数据可以包括日志、指标和链路追踪。

大多数监控工具都会提供仪表盘，用于展示团队选择的数据和指标。但这种方式存在一个常见缺点：仪表盘通常由团队按个人偏好构建，可能遗漏关键指标，导致性能异常和数据缺失不容易被发现。

另外，一些监控工具可能由于安全限制或代理程序采集能力不足，难以很好兼容复杂的云原生应用和容器化环境。

相比之下，可观测性工具更关注从整个基础设施中收集日志、链路追踪和指标数据，并及时通知 DevOps 工程师，使团队能够在问题扩大之前察觉并采取行动。

简而言之，监控告诉您系统发生了故障，而可观测性帮助您找出系统故障的原因。

可观测性有什么好处？

可观测性对终端用户、企业和 IT 团队都能带来价值。下面是几个主要收益。

1. 应用程序性能监控

端到端可观测性可以帮助企业更快识别性能问题，包括云原生和微服务架构带来的复杂问题。借助可观测性解决方案，团队可以自动化更多任务，提高运维和开发团队的生产力。

2. 支撑 DevSecOps 和 SRE

可观测性应该是应用程序及其底层基础设施的基本特征，而不只是后来追加的一套工具。软件设计和开发团队需要确保程序易于观测。DevSecOps 和 SRE 团队可以在软件交付生命周期中使用可观测数据，构建更强大、更安全、更具弹性的应用程序。

3. 基础设施、云和 Kubernetes 监控

可观测性有助于基础设施监控。基础设施和运维团队可以利用可观测性解决方案获得更好的异常上下文，更快识别和解决问题，优化资源利用率，并提升对基础设施和应用程序的管理能力。

4. 改善终端用户体验

良好的用户体验可以提升企业声誉和收入。通过可观测性解决方案，企业可以在终端用户察觉问题之前发现并解决这些问题，也可以在用户明确提出之前实施改进措施，从而提高客户满意度和留存率。

可观测性的主要组成部分

指标、日志和分布式链路追踪是可观测性的三个主要方面，也被称为“可观测性的三大支柱”。将三类数据结合起来，而不是孤立使用，可以显著提高微服务架构中应用的监控和管理能力。

由于微服务架构复杂，传统监控方法可能无法满足全面观测和调试需求。综合使用日志、指标和链路追踪，可以帮助团队更好理解和优化系统的性能与行为，提高 DevOps 团队生产力，并为用户提供更好体验。

日志

事件日志记录通常包含时间戳，是三大支柱中信息最详细的一类数据。通常情况下，开发人员负责在代码中记录日志。大多数软件包和编程语言已经内置日志记录能力，因此实现事件日志相对容易。

事件日志在非典型或极端事件场景下表现突出，因为它能够提供平均值和百分位数指标无法揭示的细节和上下文。日志可以帮助团队理解分布式系统中较少发生、但对系统性能和稳定性影响较大的意外行为。

指标

指标是在一段时间内收集并以数值形式表示的数据。指标可以通过数学建模和预测能力，帮助团队了解系统当前和未来的行为方式。

由于指标数据便于存储、处理、压缩和检索，它适合用于长期数据保留和历史模式仪表盘。团队也可以在一定时间后降低指标分辨率，例如聚合为每日或每周频率，以减少数据复杂性并方便分析。

链路追踪

分布式系统中的端到端请求流程可以编码成一条完整调用链，代表一次具体请求经过的路径。链路追踪数据记录请求的不同阶段，展示请求在不同组件或服务上经过的路径。

了解请求结构有助于理解不同组件或服务之间的异步交互方式，以及这种交互对请求执行时间、顺序和并发性的影响。通过理解请求的完整生命周期，软件工程师和 SRE 可以调试跨服务请求，定位延迟增加或资源使用量增加的原因。

可观测性如何运作？

可观测性平台通常会集成已有指标数据，并为应用程序和基础设施组件添加新的监测数据。平台的主要功能是持续识别和收集性能数据，并提取关键信息。

一般而言，可观测性平台会收集指标、链路追踪和日志数据，并实时将它们串联起来。通过整合这些数据，平台为 DevOps 团队、SRE 团队和 IT 人员提供事件细节、发生位置和可能原因等上下文信息。这些上下文信息对于识别、分析和解决应用程序性能问题非常有价值。

可观测性落地面临哪些挑战？

随着云服务复杂性增加，以及企业加速采用云服务，可观测性实现变得更加重要，也更具挑战。特别是在微服务和容器化环境下，监控数据的数量、种类和规模都超过传统监控系统的处理范围。

1. 数据孤岛

由于存在众多采集代理程序、数据源和独立监控工具，各工具之间可能缺少集成或协同，团队很难全面理解应用程序、云服务和数字渠道之间的依赖关系。

2. 数据规模、速度、多样性和复杂性

在 AWS、Azure 和 GCP（Google Cloud Platform）等现代云服务基础设施中，各服务和组件会产生大量原始指标数据。Kubernetes 和容器的快速扩缩容能力，也会带来更频繁的数据生成和变动，增加数据管理和分析难度。

3. 缺少真实生产环境上下文

即使有预生产环境和高负载测试，开发人员仍可能缺少准确观测实际情况的方法。代码发布前，团队很难完整了解真实用户行为、网络延迟和不同地理位置访问等因素如何影响应用程序和基础设施。

4. 故障排查耗费大量时间

为了解决问题并确定源头，实施团队、运维团队、基础设施团队、开发团队和数字体验团队都可能被卷入故障排查。没有统一上下文时，宝贵时间会浪费在猜测和理解指标数据上。

可观测性与 DevOps 有何关系？

在 DevOps 中，可观测性是必不可少的。DevOps 方法论的重要目标之一是项目交付的一致性，而可观测性可以帮助团队理解变更对应用程序的影响。

DevOps 要求实施 CI/CD（持续集成和持续交付）。在持续发布的过程中，了解变更对应用程序可能产生的影响非常重要。可观测性让开发者在产品交付给用户后仍能控制和观察运行情况，从而保障用户体验。

通过实施可观测性方法和工具，团队可以处理复杂性问题：通过观测应用程序输出来深入了解应用和系统的运行情况，识别潜在问题，并判断问题发生的时间和位置。

如何实践可观测性？

要实现可观测性，系统和应用程序必须提供必要的指标、日志和链路追踪数据。团队可以通过自研工具、开源软件或商业可观测性解决方案来构建可观测系统。

1. 确定业务目标

可观测性建设应先明确业务目标。例如，减少基础设施支出、支持容量规划、提高关键业务指标表现、缩短平均恢复时间，或为支持人员提供更多问题上下文。不同目标所需的可观测性配置可能不同，因此需要先制定可观测性策略。

2. 关注正确的指标

精心设计的可观测性方法可以帮助团队在问题出现前预测潜在错误或故障，并准确定位根因。为了追求透明度，团队需要进行多种数据收集、分析和测试，全面了解系统状态。

3. 使用事件日志

对于架构和开发团队来说，事件日志是分布式系统中重要的数据源。原文提到 Prometheus、Middleware 和 Splunk 等工具可用于捕获或存储相关观测数据。事件信息可能包括系统过程成功信息、重大系统故障、意外停机或导致系统过载的流量变化。

事件日志为开发人员提供关键取证信息，用于发现有缺陷的组件或存在交互问题的部分，因此对调试和错误定位尤为重要。

4. 访问可视化数据

当成功采集可观测性数据后，原始数据需要被处理成通用格式，并通过可视化工具展示。这样团队成员才能更高效地传递和共享信息。

5. 选择合适的可观测性平台

选择可观测性平台时，可以考虑这些问题：

• 工具是否免费？
• 是否使用开源采集代理工具？
• 工具是否易用？
• 团队是否具备发挥工具价值所需的技术能力？
• 工具处理能力能适应多大数据规模？

这些问题可以帮助团队根据自身业务和技术条件做出更合适的决策。

结论

一个可观测性系统需要与业务平台适配和兼容，否则可能带来系统笨重、运营成本增加、效果不足和可见性不足等问题。

在实施过程中，团队需要明确希望通过可观测性系统解决的关键问题，确保系统能够提供精准、有用的数据和可靠见解。这些数据和见解可以帮助团队理解运营情况、问题和趋势，从而支持企业决策和运营。

如果缺少明确方向，构建可观测性系统时可能会出现目标混乱、问题冲突和用户体验不一致等情况。因此，企业需要以明确目标和计划推进可观测性建设，确保系统稳定有效。

本文翻译自：https://devopscube.com/what-is-observability/，译者王梓禾，更多可观测性体系建设思路，请参考《面向故障处理的可观测性体系建设》。

FAQ

Q1：可观测性和监控最大的区别是什么？ A：监控主要基于预定义指标或日志观察系统状态；可观测性更强调在未知问题出现时，利用日志、指标和链路追踪调试系统并定位原因。

Q2：可观测性的三大支柱是什么？ A：三大支柱是日志、指标和链路追踪。日志提供事件细节，指标展示趋势和数值变化，链路追踪展示请求在分布式系统中的路径。

Q3：可观测性为什么对 DevOps 和 SRE 重要？ A：DevOps 和 SRE 都需要在快速交付和系统稳定之间取得平衡。可观测性提供生产环境运行上下文，帮助团队理解变更影响、定位故障并持续优化系统。

Q4：企业实践可观测性时应从哪里开始？ A：应先明确业务目标和关键系统，再梳理需要观测的指标、日志和链路追踪数据，最后选择合适的平台和流程，让观测数据真正服务故障处理和业务优化。