系统可观测性(1)基础概念

系统可观测性(1)基础概念(Log/Tracing/Metrics)

Author: Once Day Date: 2025年2月8日

一位热衷于Linux学习和开发的菜鸟，试图谱写一场冒险之旅，也许终点只是一场白日梦…

漫漫长路，有人对你微笑过嘛…

全系列文章可参考专栏: 十年代码训练_Once-Day的博客-CSDN博客

参考文章:

• 分布式系统可观测性之应用业务指标监控 - 掘金

• blog-cn/observability-of-distributed-system.md at master · pingcap/blog-cn ·
  GitHub

• 可观测性和监控概览 | Documentation | Google Cloud

• What Is Observability?

• What is OpenTelemetry? | OpenTelemetry

• 分布式系统可观测性(Observability)系列: Distributed Tracing(一) - 知乎

• Metrics, tracing, and logging - Peter Bourgon

• Observability: the hard parts - Peter Bourgon

• Google SRE - Site reliability engineering book Google index

---

1. 引言

2017年的分布式追踪峰会(2017 Distributed Tracing Summit)结束后，Peter Bourgon 撰写了总结文章《Metrics, Tracing, and Logging》系统地阐述了这三者的定义、特征，以及它们之间的关系与差异。 文中将可观测性问题映射到了如何处理指标(metrics)、追踪(tracing)、日志(logging)三类数据上。

可观测性(Observability)是近年来在IT领域，特别是云原生应用和分布式系统中备受关注的话题。它源于控制论，是一个系统能够提供其内部状态信息的能力。这种能力让运维和开发人员能够从外部观察系统的内部工作状态，快速检测、定位和解决问题，保障系统的稳定运行。

可观测性可以解决什么问题？Google SRE Book 第十二章给出了简洁明快的答案：快速排障。

在传统的单体应用时代，系统通常没那么复杂，通过日志分析和监控工具基本可以满足排障需求。但随着架构向微服务和云原生方向演进，系统变得高度分布式和动态，错综复杂的服务调用链路给问题定位带来巨大挑战。同时，开发迭代和业务变化越来越快，传统的日志和监控方式难以跟上变化节奏。可观测性应运而生。

可观测性通常由3大支柱组成:

• 指标(Metrics)：系统的各种可度量指标数据，例如请求数、延迟、错误率、资源使用等。通常从系统各处收集汇总，供聚合分析和可视化。
• 日志(Logging)：各种离散的事件记录，包括应用日志、审计日志等。需要收集、存储、检索和分析海量的半结构化日志数据。
• 分布式跟踪(Distributed Tracing)：记录跨度多个服务的请求执行路径、时间戳等数据。利用这些数据可以发现服务间调用的瓶颈和异常，评估系统性能。

上图引用自：Metrics, tracing, and logging - Peter Bourgon。

将这三种数据有机结合，可以全面地洞察系统行为，快速发现和定位问题根源，做出相应优化。市面上出现了很多可观测性相关的开源和商业产品，例如:

• 指标监控和警报：Prometheus、Grafana、Datadog等。
• 日志管理：ELK Stack、Splunk等。
• 分布式跟踪：Jaeger、Zipkin、SkyWalking等。

以下是一些关于可观测性原理的推荐书籍和在线资源:

• 《Distributed Systems Observability》 - Cindy Sridharan著。这是关于可观测性的权威著作，系统全面地介绍了可观测性的概念、工具链、最佳实践等。

• 《Prometheus: Up & Running》 - Brian Brazil著。Prometheus是一个广泛使用的开源监控系统,本书详细介绍了如何使用Prometheus进行系统监控和告警。

• 《Mastering Distributed Tracing》 - Yuri Shkuro著。分布式追踪是可观测性的重要手段,本书深入剖析了分布式追踪的原理和实践。

• 《Database Reliability Engineering》- Laine Campbell & Charity Majors合著。本书讨论了如何对数据库系统进行可靠性设计,可观测性是其中的重要内容。

• OpenTelemetry官方文档，https://opentelemetry.io/docs/，OpenTelemetry 是一个新兴的开源可观测性框架，提供了一致的API、SDK等以实现metrics、logs、traces的标准化采集。官网包含了详尽的概念和使用文档。

2. 三大支柱(Metrics/Tracing/Logging)

（1）指标(Metrics)，是对系统某些属性(如请求持续时间、资源利用率等)的数值化表示，通常是时间序列数据。Metrics适合用于显示系统的整体健康状况和行为趋势。

关键特征：可聚合性，即一段时间内可以组合成单个逻辑gauge(计量器)、counter(计数器)或histogram(直方图)。

一些例子：队列的当前深度可以建模为gauge，更新遵循last-writer-wins(后写入者胜出)语义进行聚合。传入的HTTP请求数可以建模为counter，通过简单的加法进行聚合更新。请求的观测持续时间可以建模为histogram，更新聚合到各个时间桶中，生成统计汇总信息。

（2）日志(Logging)，Logging是以结构化或非结构化的文本形式记录离散的事件。Logging适合用于记录specific domain的事件，供事后审计、分析、排障等。

定义特征：处理离散的事件。

一些例子：应用程序的调试或错误信息通过旋转文件、syslog发送到Elasticsearch(或OK Log)。审计跟踪事件通过Kafka推送到像BigTable这样的数据湖。从服务调用中提取特定请求的元数据发送到像NewRelic这样的错误跟踪服务。

（3）分布式追踪(Tracing)，Tracing记录了一个请求在分布式系统中的端到端路径，包括经过的所有服务、每个服务内部的关键操作等。Tracing适合用于理解系统的行为，优化性能瓶颈，定位异常请求的根因。

定义特征：处理请求范围内(request-scoped)的信息，即任何可以绑定到系统中单个事务对象生命周期的数据或元数据。

一些例子：对远程服务的出站RPC调用的持续时间；发送到数据库的实际SQL查询的文本；入站HTTP请求的关联ID。

综上，三者的侧重点各不相同：

• 指标(Metrics)强调可聚合性，用于生成统计信息和图表。
• 日志(Logging)强调离散事件，用于记录独立的消息。
• 追踪(Tracing)强调请求上下文信息，用于分析和优化分布式系统性能。

同时，它们又是相辅相成的，指标和追踪数据常常带有一定程度的离散性，日志经过聚合也可以生成统计信息。

上图引用自：Metrics, tracing, and logging - Peter Bourgon。

虽然在故障定位过程中，大部分检测目标与请求或者流量有关，但这并不意味着所有检测目标数据都要与追踪上下文生命周期绑定。例如，进程的CPU和内存使用率，队列的缓存数量和延迟等。因此，并非所有指标或日志都适合硬塞进追踪(Tracing)系统，这也能避免额外的工作资源消耗。

直接在应用程序中统计指标(Metrics)更有好处，可以根据设备或者集群的实时视图进行健康状态评估。相比之下，如果将指标(Metrics)硬塞进日志管道，可能会迫使我们放弃其中一些优势(灵活性和快速迭代能力)。

在三个领域中，指标往往需要最少的资源来管理，因为就其性质而言，它们的"压缩"效果相当好。相反，日志记录往往非常繁琐，其数量往往超过其所报告的生产流量。

因此，可以绘制出一种数量或操作开销梯度，从指标(低)到日志(高)，而追踪可能处于中间位置。

3. 可观测性与监控

可观测性(Observability)是指基于系统暴露的外部数据来理解系统内部发生的情况的能力。通过收集系统运行时的表层数据，而不是拆开系统来暴露其内部状态，就可以充分理解一个可观测的系统。

举个例子，假设房间的灯突然无法打开了。其中一种解决办法就是把墙壁撬开跟踪电线，直到找到问题的根源。但这种方法既耗时又把家里破坏的不成样子。而更有效的方法是收集电表系统的可见数据，或者灯附近的其他电器的状态。如果数据足够观测，那么足以引导找到问题的根源。

在IT系统中，可观测性意味着能够根据从复杂环境表面收集的信息来解释环境的内部状态。表层数据包括软件和基础设施日志、跟踪和指标，以及CI/CD管道或服务台等互补系统的数据。

为什么在现代复杂的分布式系统中，需要可观测性(Observability)？

• 复杂系统本质上是不完全健康和不可预测的。无法预测系统每个部分可能出现的所有故障状态。因此，从设计到操作的每个阶段，都必须考虑到失败和易于调试。可观测性可以在系统设计时作为一种特性纳入，以应对这种不可预测性。

• 通过可观测性，系统可以先在真实环境中测试后再构建。在测试过程中就可以发现一旦部署后会导致警报的失效模式，这有助于在问题影响生产环境之前发现和解决问题。

• 可观测性允许系统增量部署。如果关键指标偏离基线，就可以触发回滚。这确保了系统可以在出现问题时快速恢复，将影响降到最低。

• 运行时的可观测性可以报告足够多的关于系统健康和行为的数据点，有效反映其内部状态。这使得系统能够被更好地理解、调试和发展，这对于复杂的分布式系统至关重要。

Observability的目标则是提供关于无法被监控或者被测试的不可预测的故障和异常的信息。Monitoring的目标是监控可预测的故障和异常并生成警报。

简而言之，Monitoring监控的是已知的故障，而Observability观测的是未知的故障。

上图引用自：What is observability?

监控(Monitoring)是驱动可观测性的一个过程，但可观测性远不止监控。监控只告诉你表面发生了什么，而可观测性利用数据深入内部，获得对系统的理解。监控类似检查脉搏，可观测性类似做核磁共振。

可见性(Visibility)是通往可观测性的一步，但还不够。可见性意味着孤立地了解系统的离散部分，而可观测性通过关联数据提供对整个系统的理解。

可观测性的程度可以用系统可以被调试的程度来衡量。调试通常是一个迭代过程：从高级指标开始，通过系统各组件报告的各种细粒度上下文进行深入研究，正确排除并验证理论是否成立。对于分布式系统，调试需要的是证据，而不是猜测或假设。

可观测性(Observability)不是灵丹妙药，并不能让人们摒弃思考行为，它主要是通过数据引导开发人员思考并找到答案。

4. 可观测性与运维

Google SRE(Site Reliability Engineering)手册是Google工程师多年实践经验的结晶，是一本关于如何运行和管理大规模分布式系统的宝典。这本书涵盖了SRE工作的方方面面，从基本原则到具体实践，为我们展示了Google如何确保其服务的可靠性、可维护性和可扩展性。

这本书的核心价值在于，它提供了一套完整的、经过实践检验的方法论，用于管理现代复杂的分布式系统。它强调以工程的方式来解决运维问题，主张通过自动化、数据驱动和持续改进来提高系统的可靠性。同时，它也强调人的因素，讨论了如何建立良好的工作文化和实践，如何在团队中建立共识和协作。

在这些理念中，可观测性是一个重要的主题。尽管书中并未明确使用"可观测性"这个词，但其中许多讨论都与可观测性的理念紧密相关。

首先，书中强调全面和有效的监控是管理分布式系统的基础。没有对系统行为的深入洞察，就无法实现可靠的运维。Google SRE手册详细介绍了Google的监控实践，包括如何选择监控指标，如何设计监控系统，如何设置合理的警报等。这些都是建立可观测性的基础。

其次，书中提倡白盒监控，即对系统内部的关键指标进行监控，而不仅仅依赖于黑盒监控。这与可观测性的理念高度一致。可观测性要求我们不仅要知道系统是否正常工作，还要知道为什么，需要对系统内部有深入的理解。

再次，书中讨论了如何设置SLO和SLI，如何建立事件响应机制，如何进行混沌工程实验等。这些实践都有助于提高系统的可观测性，使我们能够更快地发现问题，更准确地定位根因，更有效地进行故障处理。

《SRE Book》自2016年发布以来，影响了无数企业的可靠性实践。Google也在持续更新这本书的内容，目前已发布了第二版《The Site Reliability Workbook》，进一步扩展了相关主题。

5. 可观测性项目(OpenTelemetry)

OpenTelemetry是一个开源的、独立于供应商的遥测数据收集和管理框架,旨在帮助实现系统的可观测性。它为创建和管理追踪、指标和日志等遥测数据提供了一套标准化的工具和API。

OpenTelemetry是由OpenTracing和OpenCensus这两个项目合并而成的，目标是成为可观测性领域的标准。

OpenTelemetry与供应商和工具无关，可以与多种开源和商业的可观测性后端兼容，如Jaeger、Prometheus等，避免了供应商锁定。OpenTelemetry关注遥测数据的生成、收集、管理和输出，让用户能够轻松地监测应用程序或系统，而无需考虑其语言、基础设施或运行时环境。遥测数据的存储和可视化则交由其他工具处理。

OpenTelemetry主要由以下几部分组成:

• 一套规范，定义了所有组件的标准。
• 一个标准协议，定义了遥测数据的格式。
• 语义约定，定义了常见遥测数据类型的标准命名方案。
• API，定义了如何生成遥测数据。
• SDK，实现了规范、API和遥测数据的输出。
• 工具生态系统，为常见库和框架提供了检测功能。
• 自动检测组件，无需更改代码即可生成遥测数据。
• OpenTelemetry Collector，一个接收、处理和输出遥测数据的代理。

OpenTelemetry的一大特点是高度可扩展。例如，可以为Collector添加自定义数据源的接收器，为SDK加载自定义检测库，为特定用例定制SDK或Collector发行版，为不支持OpenTelemetry协议(OTLP)的自定义后端创建新的输出器，以及为非标准上下文传播格式创建自定义传播器等。虽然大多数用户可能不需要扩展OpenTelemetry，但该项目在几乎每一层都提供了扩展的可能性。

OpenTelemetry是云原生计算基金会(CNCF)的一个项目，由OpenTracing和OpenCensus两个先前的项目合并而成。这两个项目都旨在解决代码检测和将遥测数据发送到可观测性后端方面缺乏标准的问题。由于任何一个项目都无法独立完全解决这个问题，它们合并成立了OpenTelemetry，结合了各自的优势，提供了一个统一的解决方案。

Once Day

也信美人终作土，不堪幽梦太匆匆......

如果这篇文章为您带来了帮助或启发，不妨点个赞👍和关注，再加上一个小小的收藏⭐！

(｡◕‿◕｡)感谢您的阅读与支持~~~