一台服务器上的监控很简单：CPU、内存、磁盘、网络，几条命令，几张图。当一个搜索请求扇出到上千台机器、经过几十个服务时，任何一个环节的延迟抖动都可能导致用户觉得慢，却没有一个工程师能单独指出问题出在哪里。

可观测性回答的就是这个问题。它不预设"可能出什么错"，而是保证你能在出错之后、从系统自身输出的数据中找到根因。这不是一套工具，是一种系统能力。

一、可观测性是什么

可观测性（observability）这个词来自控制论。1960 年，Rudolf E. Kálmán 在数学上定义了它：一个系统的可观测性，是指从它的外部输出推断其内部状态的能力。在控制论中，这是一个数学属性——一个系统要么具备可观测性，要么不具备，与你装了多少传感器无关。

软件工程借用这个词时，含义发生了一些偏移。大约从 2016 年开始，Honeycomb 的 Charity Majors 和 Christine Yen 推动这个词进入行业视野。他们的逻辑是：分布式系统的故障模式无法穷举，传统的监控——预先定义"什么算异常"然后盯着仪表盘——失效了。你需要的不只是已知指标的仪表盘，而是一种能在问题出现后、通过任意维度切分数据来找到根因的能力。

于是，"监控"和"可观测性"的区别可以这样界定：

  • 监控处理的是已知的未知（known unknowns）：你已经知道 CPU 过高、错误率飙升、响应时间变长这三件事需要关注，你预设了阈值和告警规则，系统帮你盯着。
  • 可观测性处理的是未知的未知（unknown unknowns）：系统出了一个问题，但这个问题不是你预先定义过的。你需要从高基数（high-cardinality）、高维度的遥测数据中临时组合查询，找到根因。这个"根因"在问题发生之前你根本不知道会长什么样。

两者需要的数据类型和存储模型完全不同。监控数据是低基数的时间序列（CPU、内存、QPS），可以被高效聚合和压缩。可观测性数据是高基数的（用户 ID、请求 ID、trace ID、pod name、build version），任意维度交叉查询时，传统的聚合存储就不够用了。

2024 年 8 月，Charity Majors 在一篇文章中提出"Observability 2.0"的概念来区分这两种形态：

  • Observability 1.0：三支柱模型。Metrics、logs、traces 各存各的，各查各的。工程师在三个工具之间手动拼接线索。
  • Observability 2.0：单一数据源——任意宽度的结构化日志事件（wide structured log events），metrics 和 traces 是从中派生出来的视图，不是独立存储的数据类型。

不管是叫 1.0 还是 2.0，核心问题始终是一个：当系统出了你不知道会出的问题，你需要多快、多自由地探索数据来找到答案。

二、一个简短的技术史

1990s：手工运维。 SNMP（Simple Network Management Protocol）是网络设备监控的标准协议，通过轮询获取 CPU、内存、接口流量。Nagios 在 1999 年发布，引入了阈值告警——某个指标过线就触发通知。日志是服务器上的本地文件，用 grep 和 tail -f 查看，没有中心化存储，跨机器关联靠人工。

2003-2005：SRE、日志平台和 APM。 2003 年，Splunk 成立，第一次把机器生成的日志数据集中到可搜索的平台里。同一年，Google 内部的 Production Team 在 Ben Treynor Sloss 的带领下开始实践 Site Reliability Engineering——用软件工程的方法做运维，包括定义 SLO（Service Level Objective）、error budget、blameless postmortem。SRE 不是可观测性技术本身，但它定义了"为什么要观测"和"观测到什么程度算够"的实践框架。2016 年 Google 出版了《Site Reliability Engineering》一书，这套方法论开始扩散到全行业。

同期的另一个进展是 APM（Application Performance Monitoring）。New Relic（2008）、AppDynamics（2008）、Dynatrace（2005）先后成立，它们提供了代码级别的实时性能监控，但主要针对单体或三层架构应用——结构固定，故障模式可预测。

2010：Dapper 论文。 2010 年 4 月，Google 发表了"Dapper, a Large-Scale Distributed Systems Tracing Infrastructure"。这篇论文描述了一个覆盖 Google 几乎所有线上服务的分布式追踪系统，已经在生产环境运行了两年多。Dapper 的核心模型——用 trace_id 串联一个请求经过的所有服务，每个服务上的操作为一个 span，span 之间有父子关系形成树结构——成为之后所有分布式追踪系统的原型。

Dapper 的几个设计决策影响了整个方向：通过自适应采样（高吞吐服务采样率低至 1/1024）把 overhead 控制在可忽略的水平；把 instrumentation 限制在通用库中，让应用开发者基本不需要感知追踪系统的存在；在 span 上附加 key-value 注解供应用自定义。

2012-2015：开源爆发。 Dapper 论文发表后，开源社区开始实现类似系统。Twitter 在 2012 年发布了 Zipkin——第一个开源的 Dapper 风格追踪系统。Uber 在 2015 年发布了 Jaeger（后来捐给 CNCF，2019 年毕业）。Apache SkyWalking 在 2015 年由吴晟开源，2017 年进入 Apache 孵化器。

2012 年还有一个独立事件：SoundCloud 的工程师发布了 Prometheus。Prometheus 的设计源自 Google 内部的 Borgmon 监控系统，关键特性是多维度的数据模型（key-value labels）、PromQL 查询语言、以及 pull-based 采集模式。Prometheus 后来成为 Kubernetes 生态的事实监控标准。

日志侧，Elasticsearch（2010）+ Logstash + Kibana 组成了 ELK Stack，成为中心化日志管理的主流开源方案。Grafana 从 2014 年开始成为跨数据源的可视化标准——它不存数据，但能从 Prometheus、Elasticsearch、InfluxDB 等几十种数据源拉数据画图。

2017：三支柱概念提出。 2017 年，Peter Bourgon 发表了"Metrics, Tracing, and Logging"一文，Cindy Sridharan 随后在《Distributed Systems Observability》中进一步阐释，将 metrics、logs、traces 并称为可观测性的三大支柱。这个概念影响深远——它给行业提供了一套共享词汇，但也暗示三者是独立的、平行的，在客观上助长了数据孤岛。

2019-2023：OpenTelemetry 统一标准。 2010s 后期，分布式追踪领域有两个互相竞争的开放标准：CNCF 的 OpenTracing（2015）和 Google/Microsoft 联合推出的 OpenCensus（2017）。两者互不兼容。

2019 年，OpenTracing 和 OpenCensus 宣布合并为 OpenTelemetry（OTel），作为 CNCF 的沙箱项目。OTel 的目标是成为 traces、metrics、logs 的统一采集标准——一套 API、一套 SDK、一个 Collector，数据输出到任意后端。

OTel 的关键里程碑可以粗略看成几步：

  • 2021 年：Tracing 相关 API/SDK 进入稳定阶段
  • 2022 年：OpenTracing 归档退役，OpenTelemetry 开始成为迁移方向
  • 2023 年：Metrics 在多个语言生态进入稳定阶段，Logs 数据模型和采集链路逐步稳定，OpenCensus 归档退役

从 Dapper 论文发表算起 13 年后，分布式追踪从一家公司的内部实验变成了全行业的开放标准。

2024-2025：eBPF 和持续 profiling。 传统方式需要应用引入 SDK 或在集群中部署 agent 来采集遥测数据。eBPF（extended Berkeley Packet Filter）改变了这一范式：它允许在内核中安全地运行沙箱程序，在系统调用层、网络层、调度层直接捕获数据，不需要修改应用代码，overhead 通常在 1% 以下。

这使得几个方向成为可能：

  • 零代码分布式追踪：DeepFlow、Pixie（CNCF）等项目通过 eBPF 自动捕获服务间的调用关系，不需要应用层埋点
  • 持续 profiling：Grafana Pyroscope 和 Parca 利用 eBPF 实现 CPU、内存、I/O 的持续性能分析，overhead 足够低以至于可以在生产环境一直开着
  • 内核级容器可见性：Netflix 使用 eBPF 监控调度器延迟来检测"noisy neighbor"问题，Cilium/Tetragon 则利用 eBPF 做网络和安全可观测性

2025 年，Coralogix 发布了基于 eBPF + OpenTelemetry 标准的持续 profiling 产品。eBPF 与 OTel 的融合方向是：eBPF 负责零代码采集，OTel Collector 负责处理、转换和导出。

三、三类核心数据

Observability 2.0 的 wide events 模型在理论上更统一——用一套高基数结构化日志支撑所有查询模式。但在当前的工程实践中，业界仍然广泛按 metrics / logs / traces 三类来组织和理解遥测数据，每种类型有各自的存储引擎、查询模式和适用场景。从使用者的视角看，这三类的区分仍然有用。

Metrics（指标） 是数值型时间序列。CPU 使用率、请求数、错误数、延迟分位数——这些是聚合后的数值，存储成本低，查询速度快，适合构建仪表盘和配置告警。Prometheus 是多维度指标模型的代表。指标的局限在于丢失了细节：你知道 p99 延迟高了，但不知道是哪个用户、哪个请求触发的。

Logs（日志） 是不可变的事件记录。一次请求进来、一个函数被调用、一个错误被抛出——都生成一行日志。日志的粒度最细，但存储和查询成本最高。结构化日志（JSON 格式、一致的字段名）是现代实践的基础要求——非结构化日志机器无法高效解析，可观测性无从谈起。

Traces（追踪） 是一次请求的完整路径。一个 trace 由多个 span 组成，每个 span 代表请求在某个服务上的处理片段。Span 之间的父子关系和兄弟关系描述了请求在分布式系统中的拓扑。Traces 对于定位性能瓶颈和理解服务依赖特别有价值——你会知道不是 B 服务慢了，是 B 服务调用的 C 服务的第 3 个数据库查询慢了。

三者的关联 是让数据从孤岛变成一张网的关键：

  • 在日志中注入 trace_id 和 span_id：从 trace 定位到某个慢 span，直接跳到对应日志看详情
  • 使用 exemplar：在 metrics 中关联到具体 trace，把聚合指标和具体请求打通
  • OpenTelemetry 的统一数据模型：metrics、logs、traces 共享同一套 resource 和 attribute 语义约定

关于日志有一个值得展开的方向：wide structured log events。这个思路是让应用输出任意宽度、高基数的结构化日志（user_id、request_id、feature_flag、build_version、region 等都打进去），然后将这些日志同时用于生成 metrics（按某字段聚合）和 traces（按 request_id 串联）。本质上用一套数据支撑三种视图。Honeycomb 是这种模式的早期倡导者，OpenTelemetry 的 Logs 数据模型也支持这种用法。

四、数据是怎么采集的：从 SDK 到 eBPF

采集层的演进是可观测性技术栈中最关键的基础设施变化。

第一阶段：SDK + Agent。 应用通过 OpenTelemetry SDK（或各语言的 Prometheus client、日志库）产生 telemetry 数据，发送到本地 agent 或直接发送到 Collector。SDK 的优点是精度高——你在代码里知道变量的确切含义和业务语义——代价是需要在代码中手动埋点。

第二阶段：OpenTelemetry Collector。 OTel Collector 是 telemetry 的统一网关。它接收 OTLP 协议数据，经过处理管道（过滤、脱敏、批处理、采样、属性编辑），导出到不同后端——可以把 traces 发到 Jaeger，metrics 发到 Prometheus，logs 发到 Loki，三路数据走同一个 Collector。Collector 可以部署为 sidecar、daemonset 或独立集群，取决于流量规模。

第三阶段：eBPF。 eBPF 程序在内核中运行，hook 进系统调用、网络包、调度事件等内核路径，直接暴露系统和网络行为。对于以下场景，eBPF 提供了传统方式难以替代的价值：

  • 应用不能埋点的场景（第三方软件、遗留系统）
  • 需要内核级可见性的场景（容器间网络延迟、文件系统 I/O 热点、CPU 调度抖动）
  • 安全可观测性（检测异常 syscall、容器逃逸、反向 shell）
  • 服务网格和网络层面的自动拓扑发现

eBPF 的局限：它在内核层，看不到应用层的业务逻辑和变量。所以 eBPF 不会替代 SDK 埋点——两者是互补的。SDK 补充业务语义，eBPF 补充基础设施可见性。

持续 Profiling 是采集层的另一个重要方向。传统 profiling 在开发或 staging 环境用 pprof、JFR 等工具针对特定进程采样，有显著性能开销，不适合生产环境长期运行。基于 eBPF 的 profiling（Grafana Pyroscope、Parca、Coralogix）将 overhead 压低到 1% 以下，使得在生产环境中持续采集 CPU 火焰图、内存分配热点、I/O 等待分布成为可行。当凌晨三点告警把你叫醒，你可以直接看过去 24 小时的 CPU profile 判断什么函数在烧 CPU，而不是试图在本地复现。

五、谁在提供可观测性

可观测性是一个生态，不是一个产品。以下列出现有格局中的主要选择，目的不是推荐某个方案，而是给读者一张结构化的地图。

开源栈 的核心是 Prometheus + Grafana 组合：

  • Prometheus：指标采集和存储。Kubernetes 环境下的默认监控方案
  • Grafana：跨数据源可视化。同一份面板可以查询 Prometheus（指标）、Loki（日志）、Tempo（追踪）、Pyroscope（profile）——Grafana Labs 把这套开源栈称为 LGTM（Loki, Grafana, Tempo, Mimir）
  • Grafana Loki：受 Prometheus label 模型启发的日志聚合系统。不索引全文，按 label 索引元数据再对日志内容做流式搜索，存储成本低于 ELK
  • Grafana Tempo：专注于高基数 trace 的存储和搜索，不索引 span 级别属性
  • Grafana Pyroscope / Parca：持续 profiling
  • OpenTelemetry Collector：统一采集管道

这套开源栈适合对数据自主权有要求的团队。所有组件可以自建，代价是运维成本。

商业可观测性平台 提供托管和整合：

  • Datadog：500+ 集成，覆盖基础设施监控、APM、日志、RUM、安全监控。2024-2025 年在 AI 驱动的异常检测方面投入较大
  • Grafana Cloud：托管版 LGTM 栈，对已有 Prometheus 生态的团队接入成本较低
  • Honeycomb：强调高基数事件驱动的查询模型，面向开发者 debug 场景。在 ETR 2024 年调查中，75% 的受访者认可其在可观测性领域的技术创新
  • New Relic、Dynatrace、Splunk（Cisco）：各自有较强的 APM 和 AIOps 积累，在大型企业中占有稳定份额

云平台原生服务 对已在对应云上的业务接入成本最低：

Google Cloud Operations Suite（原 Stackdriver）提供：

  • Cloud Monitoring：指标仪表盘、告警、SLO 监控、多项目 workspace
  • Cloud Logging：集中化日志聚合，支持 SQL 风格查询（Log Analytics），可通过 Log Router 按类型路由到 BigQuery / Pub/Sub / Cloud Storage
  • Cloud Trace：分布式追踪，支持 OpenTelemetry 接入，通过 X-Cloud-Trace-Context header 传播 trace context
  • Cloud Profiler：持续 CPU 和内存 profiling
  • Error Reporting：自动聚合相似异常并分组通知
  • 通过 Ops Agent 跨 GCP + AWS + on-prem 统一接入

Cloudflare Observability 构建在 CDN 和 Workers 平台上，关注的是流经 Cloudflare 网络的流量的可观测性：

  • Log Explorer（2025 年 6 月 GA）：原生日志存储和查询，覆盖 HTTP 事件、安全事件、Zero Trust 数据集（Access、Gateway DNS/HTTP/Network、CASB、Device Posture），30 天留存
  • Workers Observability（2025 年）：Workers 的日志、指标查询和控制台，包含支持聚合/过滤/分组的 Query Builder
  • Observatory（2025 年 Open Beta）：融合 RUM、后端遥测、错误率、缓存命中率、合成测试（浏览器+网络），并给出可操作建议
  • Workers Automatic Tracing（2025 年 11 月 Open Beta）：零代码导出 OpenTelemetry 兼容的 traces
  • Cloudflare Radar：互联网级别的可观测性——BGP 路由、AS 流量、证书透明度、AI crawler 活动
  • 据 Cloudflare 官方博客披露，2024 年 6 月其内部日志管道从 syslog-ng 迁移到 OpenTelemetry Collector，同年将收购的 Baselime 从 AWS 迁移至自有平台后成本降低 80% 以上

AWS CloudWatch 和 Azure Monitor 提供类似功能，差异主要体现在与各自云产品线的集成深度。

六、在实践中落地

数据的覆盖顺序。 不需要一次性覆盖所有。对于单体应用或小于五个服务的团队，先把结构化日志做好，加上延迟、错误率、流量等核心指标已经能覆盖大部分场景。对于微服务架构、服务数超过十个的团队，分布式追踪的优先级显著提高——没有 trace，很难把跨服务的延迟尖峰追溯到根因。

结构化日志是基础。 如果日志是非结构化的，或者虽然是 JSON 但字段名在不同服务之间不一致——同一个概念用了不同的 key——任何下游查询和分析都会很痛苦。花时间定义一套跨服务共用的日志字段约定，至少包括 timestamp、service_name、trace_id、span_id、level、message。

SLO 驱动告警。 告警不应该基于随意挑选的阈值（"CPU > 90%"），而应该从用户的视角出发：服务应该多快（latency SLO）、可用性应该多少（availability SLO）、成功率应该多少（success rate SLO）。基于 SLO 和 error budget 配置告警——当 error budget 消耗速度快于预期时触发，而不是每次指标抖动都触发——可以显著减少凌晨告警的噪音。

成本控制。 可观测性数据的体量增长通常快于业务增长。几个需要注意的点：

  • 日志输出不是越多越好。debug 级别通常只在开发环境有价值，生产环境按需保留
  • 指标的 label 基数——Prometheus 每个唯一的 label 组合产生一个新的时间序列，用 user_id 或 request_id 做 label 是常见错误
  • traces 的采样策略——100% 采样通常没必要。tail-based sampling（基于延迟、错误等属性在后端决定保留哪些完整 trace）比 head-based sampling（随机决定）更适合大多数场景
  • 冷热分层——不常访问的历史数据用冷存储，频繁查询的近期数据用热存储，按访问频率控制成本

统一数据模型的长期价值。 采用 OpenTelemetry 的语义约定——不管后端是 Prometheus、Datadog 还是云厂商的监控服务——http.method 在哪个后端都叫 http.method。这种标准化减少了跨团队的解释成本，也降低了后端切换的迁移成本。

结尾

可观测性最终解决的不是技术问题，而是认知问题。

软件系统越来越复杂这个趋势不可逆。从单体到 SOA 到微服务到 serverless，从单机房到多 region 到 edge computing——每一步都在增加系统的组合状态数，也在增加故障模式数。到某一点，没有人能提前列出所有"可能出什么错"的场景——不是因为不够勤奋，是因为组合空间太大了。

可观测性就是对这件事的回应。它把"预先定义故障"的思维转换成"预先采集数据，事后探索"的思维。它的概念来自 1960 年的控制论，它的技术被 2010 年的 Dapper 论文点燃，被开源社区实现和扩散，被 OpenTelemetry 标准化，被 eBPF 和持续 profiling 推进到内核层。但它的目的始终是一个：当系统出了你不知道会出的问题，你能多快找到答案。

参考资料