什么是可观测性？可观测性成功指南

导读：可观测性三支柱的概念，在业内广为流传，为可观测性的传播起到了巨大的作用。三支柱的概念，更多是从可观测性数据底座的构成分类角度来描述，但是显然，我们需要更多视角，才能有更清晰的认知。

本文来自 Chronosphere，就是之前在 Uber 内部写 M3DB 的那帮人创业的公司，本文作者信息如下：

本文的核心观点和 Flashcat 的观点很像，都主张从目标出发，面向故障发现、定位的目标场景来构建可观测性体系。当然了，可观测性适用的场景很多，不止服务于故障发现、定位，但毫无疑问，这是其最大的应用场景。

原文：https://chronosphere.io/learn/are-the-three-pillars-of-observability-still-relevant/

可观测性的含义是什么？对一些人来说，可观测性被定义为一组不同的数据类型，即所谓的三大支柱——日志、指标和分布式追踪。虽然这些都是可观测性的关键输入，但它们本身并非可观测性解决方案。可观测性的孤立“三大支柱”方法过于关注技术工具和底层数据格式，而非结果。

• 日志：日志如何融入可观测性？日志描述系统内的离散事件和交易。它们由应用程序在特定时间段内生成的消息组成，这些消息可以告诉你正在发生的事情。
• 指标：指标由描述资源利用率或行为测量结果的时间序列数据组成。它们非常有用，因为能让人们深入了解系统的行为和健康状况，尤其是在进行聚合时。
• 分布式追踪：在可观测性中，分布式追踪是什么？追踪使用唯一ID来追踪单个请求从一个服务跳转到另一个服务的过程。它们可以向你展示一个请求是如何从一端传输到另一端的。

可观测性不止于三大支柱

尽管输出可观测性三大支柱中的所有数据类型很重要，但仅靠这些输入永远无法保证在云原生环境中获得更好的结果。例如，如果一个系统输出日志、指标和分布式追踪数据，也不能保证你能及时收到问题通知，也不能保证你能快速分类处理问题。

此外，许多公司发现，可观测性数据的产生量与从这些数据中获得的价值之间几乎没有相关性。也就是说，更多的日志或指标并不等同于更多的价值，尽管它们几乎总会导致成本增加。

虽然可观测性的三大支柱勾勒出了重要的数据功能，但真正基于结果的可观测性源于聚焦可观测性的三个阶段——即“了解、分类和理解”——因为团队能够从其数据中获取最大价值，从而快速解决问题。

可观测性的内涵与原因

可观测性既是一种实践（或流程），也描述了服务的属性（或状态）。与DevOps类似，可观测性是分布式系统工程的核心能力。这是云原生开发者在日益复杂的系统中日常开展的实践。可观测性也是系统的一种属性——即系统是否能生成可用于解答开发者所提任何问题的数据。维护和管理一个具备可观测性的系统要比非可观测性系统容易得多。

在云原生环境中，工程和SRE负责人不应专注于可观测性的三大支柱，而应考虑三个阶段。为什么呢？因为可观测性的三个阶段更有助于解答关于其所构建的代码和系统运行的关键问题。此外，作为较新系统的一个特性，可观测性解决方案生成的数据能够实时或近实时地回答开发人员的问题。

可观测性解决了哪些挑战？

对系统和服务进行内省与理解的需求并非新事物——可观测性的许多基本目标已经实践了数十年。而发生变化的、以及可观测性的三个阶段所介入的方面，是由运行现代应用程序和基础设施的本质差异所驱动的。

运行在容器和微服务上的云原生应用具有完全不同的架构，并且设计得比传统应用更具可扩展性、可靠性和灵活性。云托管监控和应用性能监控（APM）诞生于前云原生时代——那个时代有着截然不同的潜在假设。云原生迫使各组织重新审视他们进行监控和可观测性的方式，原因如下：

• 数据的规模和基数都在不断增长。云原生环境会产生大量的监控数据——其数量是传统基于虚拟机的环境的10到100倍。
• 系统变得更加灵活且短暂。其使用模式和留存要求都与云原生时代之前大相径庭。
• 服务和系统之间存在更强的相互依赖性。将服务拆分为微服务会导致更复杂的依赖关系，工程师必须理解这些依赖关系才能解决问题。这也导致更需要将基础设施、应用程序和业务指标关联起来。

所有这一切都导致了复杂性的激增，这使得在不显著增加开销或不找到新方法的情况下，可靠且高效地运行云原生服务几乎成为不可能。例如，可观测性的三个阶段是对“可观测性三大支柱”的一种替代方法，它关注的是结果而非输入。

指标、分布式追踪和日志如何协同工作

虽然日志、指标和分布式追踪这三大支柱各自提供了独特的见解，但它们真正的力量在于协同工作的方式。指标提供了系统性能的高层视图，帮助团队快速发现异常或瓶颈。日志则传递丰富的上下文信息，使工程师能够深入探究特定时间点发生的具体情况。

另一方面，分布式追踪记录了请求在各个服务之间的流转，将分布式系统不同部分之间的关联点连接起来。它们共同提供了一个全面的视图，帮助团队不仅能检测问题，还能高效地诊断和解决问题。这种协同作用有助于更快地进行根本原因分析，并使操作流程更加顺畅，尤其是在复杂的云原生环境中。

更好的结果：可观测性的三个阶段解析

可观测性三个阶段的每个阶段，其目标都是将对客户或员工体验的负面影响降至最低。开发运维团队通过快速找到他们所需的信息来实现这一点，以便迅速修复代码中出现的问题——甚至在了解根本原因之前就着手解决。值得注意的是，补救措施并不总是彻底消除某个难题，而是将服务恢复到客户和员工所期望的可用性和性能水平。每个阶段都对应着回答一个我们认为实现卓越可观测性所必需的关键问题。

以下是实现出色可观测性的三个关键阶段（以及所需工具）：

1. Know：识别存在问题

未知的问题是无法解决的。这就是为什么补救措施首先要从发现问题开始——理想情况下，要在客户发现之前。从技术（或可观测性解决方案）的角度来看，识别问题的最快途径是一个可执行的警报，其中包含相关指标、分布式追踪，甚至可能还有日志。

对系统进行变更会是引发生产问题的最大源头，因此，能够迅速将问题与变更关联起来至关重要。借助完整的可观测性平台，团队成员可以直接从警报过渡到问题修复——通常是回滚最新的部署。之后，他们便能进行根本原因分析，而无需承受客户期望带来的时间压力。

2. Triage：阻止问题产生更多负面结果

并非所有问题都能在警报阶段立即得到解决，许多问题必须进入分类处理阶段。分类处理是对问题范围的初步评估，并指出哪些是最重要的。这一步至关重要，因为它有助于确定更大规模修复工作的紧急程度。分类处理要回答的问题包括：

• 有多少客户受到了影响，影响程度如何？
• 谁是能提供帮助的最佳内部资源，他们是否有空？

3. Understand：深入探究问题的根本原因

在发现问题并进行分类后，团队需要能够迅速转向查明问题的起源和发生方式，以防止其再次出现。每个人都可以进行推测，但相互关联的分布式追踪、日志、指标和仪表盘将提供事后分析所需的数据，从而揭示依赖关系以及在最基本层面上真正出现的问题。

真正的基于结果的可观测性源于对可观测性三个阶段的聚焦——了解、分类和理解。

团队值得拥有的不仅仅是可观测性的三大支柱

主要目标是尽快从问题出现过渡到问题解决。技术输入，即可观测性的三大支柱，是有用的辅助工具，但它们并不能改善结果。借助可观测性的三个阶段来提高结果的成功率，首先要考虑“了解>分类>理解”这几个步骤。

出色的可观测性能够带来竞争优势、世界级的客户体验、更快的创新以及更高效的开发人员。但企业不能仅通过关注输入和数据（可观测性的三大支柱）来实现出色的可观测性。通过关注本文概述的三个阶段和成果，团队就能实现出色可观测性的目标。