可观测性三支柱：日志、指标、链路追踪的统一之道

一个用户反馈"网站很慢"。你的系统有五十个微服务，一个请求可能经过其中十几个。问题是出在网关？数据库？还是某个中间服务？你怎么找到瓶颈在哪？

这就是可观测性要解决的问题。

从监控到可观测性

传统的监控思路是"预设问题"。你预先定义好要监控的指标（CPU 使用率、内存占用、响应时间），然后设置阈值告警。当指标超过阈值时触发告警。

这种方式的问题是：你只能监控你预料到的问题。如果出现了你没有预料到的异常模式，传统监控就无能为力了。

可观测性的思路不同。它不是预设问题，而是提供足够的信息让你能够诊断任何问题。就像医生不只是量体温（监控），而是通过各种检查手段（血液检查、CT、核磁）来全面了解病人的身体状况（可观测性）。

可观测性基于三个支柱：日志（Logs）、指标（Metrics）、链路追踪（Traces）。

日志：记录发生了什么

日志是最原始、最直接的可观测性数据。它记录了系统中发生的每一个事件：一个请求被接收、一个数据库查询被执行、一个错误被抛出。

日志的优势是信息丰富。一条日志可以包含时间戳、日志级别、请求 ID、用户 ID、错误详情、调用栈等大量上下文信息。当问题发生时，日志通常是最先被查看的数据源。

但日志也有明显的劣势。首先，日志的量巨大。一个中等规模的系统每天可能产生几十 GB 的日志，存储和查询的成本很高。其次，日志是非结构化的。不同服务的日志格式可能不同，难以统一分析。第三，日志是孤立的。一个服务的日志只能看到这个服务内部发生的事情，看不到整个请求链路。

结构化日志是解决非结构化问题的方案。把日志输出为 JSON 格式，每个字段都有明确的含义。这样可以用机器高效地解析和查询。ELK（Elasticsearch + Logstash + Kibana）是目前最流行的日志管理方案。

指标：量化系统状态

指标是数值型的时间序列数据。CPU 使用率、内存占用、请求 QPS、响应时间 P99、错误率，这些都是指标。

指标的优势是体积小、查询快。一个指标一天的数据量可能只有几 KB，可以高效地存储和查询。指标也天然适合告警，当某个指标超过阈值时触发通知。

指标的劣势是信息有限。一个指标只能告诉你"响应时间变长了"，但不能告诉你"为什么变长了"。要找到原因，还需要日志和链路追踪的配合。

Prometheus 是目前最流行的指标采集和存储方案。它采用拉取模式，主动从各个服务拉取指标数据。配合 Grafana 进行可视化，可以构建出直观的监控大盘。

链路追踪：还原请求全貌

链路追踪是可观测性中最有价值但也最复杂的一个支柱。

它记录了一个请求从入口到出口经过的所有服务，以及每个服务的处理时间。当一个请求的响应时间异常时，链路追踪可以精确地告诉你是在哪个服务、哪个操作上花了太多时间。

链路追踪的工作原理是：请求进入系统时被分配一个唯一的 Trace ID，这个 ID 会随着请求在各个服务之间传递。每个服务在处理请求时记录自己的 Span（一段操作的时间和状态）。所有 Span 通过 Trace ID 关联在一起，形成一个完整的链路。

链路追踪的劣势是侵入性。每个服务都需要集成追踪 SDK，在关键操作处埋点。虽然有一些自动埋点的技术，但要获得完整的链路信息，通常还是需要手动埋点。

Jaeger 和 Zipkin 是最常用的开源链路追踪方案。云厂商也提供了托管的链路追踪服务。

OpenTelemetry：统一的未来

三个支柱各自为政的问题很明显：日志用一套系统，指标用一套系统，链路追踪又用一套系统。数据之间难以关联，工具之间难以互通。

OpenTelemetry 试图解决这个问题。它是 CNCF 的一个项目，目标是提供统一的可观测性数据采集标准。它定义了日志、指标、链路追踪三种数据的标准格式和采集协议。

使用 OpenTelemetry，你只需要在服务中集成一个 SDK，就能同时采集三种可观测性数据。数据可以发送到任何兼容 OpenTelemetry 的后端（比如 Prometheus、Jaeger、Elasticsearch），不需要绑定特定的厂商。

OpenTelemetry 已经得到了各大云厂商和可观测性工具厂商的支持，正在成为可观测性领域的事实标准。

实际落地的建议

对于想要建设可观测性的团队，我的建议是分阶段推进。

第一阶段：先做好日志。结构化的集中日志是最基础的可观测性能力，也是排查问题最直接的手段。用 ELK 或者类似的方案把所有服务的日志集中收集和查询。

第二阶段：加上关键指标。监控每个服务的 QPS、延迟、错误率。设置合理的告警阈值。这一步能让你在问题发生时快速感知。

第三阶段：引入链路追踪。从核心链路开始，逐步扩展到所有服务。链路追踪能让你在复杂系统中快速定位性能瓶颈。

第四阶段：统一到 OpenTelemetry。用 OpenTelemetry 统一数据采集，减少维护多套采集系统的成本。

我的判断

可观测性是微服务架构的必需品，不是可选项。没有可观测性，微服务就是一个黑盒迷宫，出了问题只能靠猜。

OpenTelemetry 的统一标准是大势所趋。未来几年，大部分可观测性工具都会支持 OpenTelemetry 协议。现在投入学习 OpenTelemetry，是一个不会出错的选择。

但工具只是手段，关键是要建立可观测性的文化。团队需要习惯在开发时就考虑可观测性（而不是事后补救），需要习惯用数据来诊断问题（而不是靠直觉猜测）。

可观测性的终极目标是：当问题发生时，你能在几分钟内定位到根本原因，而不是花几个小时翻日志。