1. 可观测性工程导论

在传统运维体系中，“监控”几乎等同于“看仪表盘”：我们预先定义好 CPU 使用率、内存占用、磁盘 IO、接口成功率等指标，设定阈值，超过就告警。这套方法在系统规模有限、故障模式可枚举的时代非常有效。但当系统演进为微服务、容器化、动态扩缩容的分布式架构后，故障的形态发生了根本变化——很多问题不再是“某个指标越界”，而是“某个请求在跨越七个服务后变慢了 300ms，但每个服务的平均延迟都正常”。此时，预先定义的仪表盘无法回答“为什么”，因为问题本身在定义监控项时并不存在。

可观测性（Observability）正是为应对这种“未知的未知”而提出的工程能力。它源自控制论：一个系统若能从其外部输出推断出内部状态，就称其具有可观测性。落到软件系统上，可观测性意味着：不需要提前预测故障模式，仅凭系统产生的数据，就能提出新问题并逐步定位根因。监控回答“系统是否正常”，可观测性回答“系统为什么不正常”。前者是已知问题的检测，后者是未知问题的探索。

三大支柱在 Elastic 数据平台中的定位

可观测性工程通常由三类遥测数据支撑，业界称为“三大支柱”：日志（Logs）、指标（Metrics）、追踪（Traces）。它们不是三个独立工具，而是同一系统在不同维度上的投影，各自回答不同的问题。

• 日志：离散的、带时间戳的事件记录，回答“发生了什么”。在 Elastic 中通常以 ECS（Elastic Common Schema）字段规范写入，存储于数据流（data stream），如 logs-app.production-default。日志信息量大、语义丰富，但结构松散，适合事后取证与异常细节还原。
• 指标：按固定时间间隔聚合的数值，回答“系统整体表现如何”。Elastic 通过 Metricbeat、Elastic Agent 或 OpenTelemetry Collector 采集，写入 metrics-* 数据流。指标成本低、适合长期趋势与告警，但缺乏单次请求的上下文。
• 追踪：一次请求在分布式系统中完整路径的因果链，回答“这次请求慢在哪一段”。每个 trace 由多个 span 组成，携带 trace_id、span_id、parent_id 与服务名，写入 traces-apm-* 数据流。追踪能精确还原跨服务调用关系，但采样后并非全量。

三者的融合价值在于“关联”。在 Elastic 可观测性平台中，一条 trace 的 span 可以直接跳转到对应时间窗口的日志，一个异常指标可以下钻到具体 trace，而日志中的 trace_id 又能反向定位完整调用链。这种以 trace_id、service.name、host.name 等 ECS 公共字段为纽带的关联，把三份孤立数据变成一张可导航的证据网。

从“看板”到“探索”：工作方式的转变

理解三大支柱的定位后，实际工作中最关键的是转变排查思路。传统监控是“先有假设，再看数据”：怀疑数据库慢，就打开数据库监控面板。可观测性则是“先看数据，再形成假设”：从一个异常指标出发，下钻到 trace，发现某个 span 耗时异常，再跳转到该 span 对应时间点的日志，看到具体的错误堆栈或慢查询语句，最终定位根因。

以 Elastic 平台为例，一个典型的排查闭环如下。假设告警显示订单服务 P99 延迟从 200ms 升至 1.2s。第一步，在 Metrics 中确认延迟上升的时间窗口与影响范围；第二步，在 APM 的 Traces 中按 service.name: order-service 和该时间窗口筛选，按延迟排序，找到最慢的 trace；第三步，展开该 trace 的瀑布图，发现 payment-service 的 POST /charge span 占了 900ms；第四步，点击该 span 的“查看日志”，平台自动带入 trace_id 与时间范围，日志中显示数据库连接池等待超时；第五步，回到 Metrics 查看该数据库连接数指标，确认连接池耗尽。整个过程不需要预先为“连接池耗尽”配置任何监控项。

落地时的关键判断

在 Elastic 数据平台中建设可观测性，需要先明确几个工程判断。第一，数据模型先行：所有日志、指标、追踪都应遵循 ECS，至少保证 @timestamp、service.name、host.name、trace.id、span.id 等字段一致，否则关联无从谈起。第二，采样策略要分层：追踪数据量最大，通常采用头部采样或尾部采样，但错误请求与慢请求应尽量保留；日志可对 DEBUG 级别降采样，ERROR 级别全量保留。第三，保留周期要区分：指标可长期保留用于趋势分析，原始日志保留 7～30 天，追踪保留 3～7 天，通过 ILM（索引生命周期管理）自动滚动与删除，控制存储成本。