传统监控已死。不是在那种夸张的、会议上演讲式的”万物皆逝”的意义上，而是在实际意义上——过去十年为我们服务的工具和实践，已不再足以应对我们今天构建的系统。
分布式微服务、无服务器函数、边缘计算、多云部署和服务网格创造了”检查服务器是否在线”不再有意义的环境。现在的问题是：”为什么当我们的总体指标看起来正常时，特定用户在特定 API 端点上 experiencing 高延迟？”
回答这个问题需要可观测性——不是作为一个流行词，而是作为一种理解系统行为的根本不同方法。在 2026 年，两项技术已成为现代可观测性的支柱：OpenTelemetry 和 eBPF。
从监控到可观测性：究竟发生了什么变化
监控提出的是预设问题：CPU 是否超过 80%？错误率是否超过阈值？服务是否响应健康检查？您为您预期的情况配置仪表板和警报，并希望生产故障符合您计划的模式。
相比之下，可观测性是能够就系统行为提出任意问题，而无需部署新代码或配置。这是一种区别：一个显示平均响应时间的仪表板，与一个让您调查为什么来自特定地区、使用特定 API 版本、访问特定数据库分片的请求从凌晨 3:47 开始失败的系统。
这一转变的技术基础建立在三大支柱上：
- 追踪：跟踪跨服务边界的请求，在每个跳点捕获时间、依赖关系和上下文。
- 指标：提供随时间变化的系统行为聚合数值测量。
- 日志：捕获具有结构化上下文的离散事件。
突破不在于任何单一支柱。而在于关联——跨越所有三个方面，从异常指标跳转到促成该指标的追踪，再到这些追踪中的日志事件。
OpenTelemetry：胜出的标准
多年来，可观测性一直受到同样的 N 乘 M 问题的困扰，这个问题也困扰着 AI 工具集成。每个应用程序都需要为每个后端使用检测库：Datadog 库、Jaeger 库、Prometheus 库、特定于供应商的代理。切换可观测性供应商意味着重新检测整个技术栈。
OpenTelemetry (OTel) 通过提供单一、供应商无关的遥测标准解决了这一问题。它现在是云原生计算基金会 (Cloud Native Computing Foundation) 中活跃度第二高的项目（仅次于 Kubernetes)，并且已经成为遥测数据收集的行业标准。
OpenTelemetry 如何工作
OTel 提供三个层次：
API 和 SDK 用于对应用程序代码进行遥测。这些 API 和 SDK 支持所有主流语言，既提供自动遥测（针对常见框架和库），也提供用于自定义业务逻辑的手动遥测 API。
// Go 中的 OpenTelemetry 手动遥测
func handleRequest(w http.ResponseWriter, r *http.Request) {
ctx, span := tracer.Start(r.Context(), "handleRequest",
trace.WithAttributes(
attribute.String("user.id", getUserID(r)),
attribute.String("request.path", r.URL.Path),
),
)
defer span.End()
result, err := processOrder(ctx)
if err != nil {
span.RecordError(err)
span.SetStatus(codes.Error, err.Error())
http.Error(w, "Internal error", 500)
return
}
span.SetAttributes(attribute.String("order.id", result.ID))
json.NewEncoder(w).Encode(result)
}OpenTelemetry Collector 是一个供应商无关的代理，用于接收、处理和导出遥测数据。它可以作为 sidecar、守护进程或独立服务运行，并支持数十种输入和输出格式。Collector 将您的遥测与可观测性后端解耦。
# OpenTelemetry Collector 配置
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch:
timeout: 5s
send_batch_size: 1024
tail_sampling:
policies:
- name: errors
type: status_code
status_code: { status_codes: [ERROR] }
- name: slow-requests
type: latency
latency: { threshold_ms: 1000 }
exporters:
otlphttp:
endpoint: https://your-backend.example.com
prometheus:
endpoint: 0.0.0.0:8889
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tail_sampling]
exporters: [otlphttp]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [prometheus]OTLP 协议（OpenTelemetry Protocol）定义了遥测数据的传输格式。如今几乎每个现代可观测性后端都原生支持 OTLP，这意味着您只需更改 Collector 配置文件即可切换供应商，而无需修改应用程序代码。
自动遥测
OTel 最强大的功能之一是自动仪表化。对于具有运行时仪表化功能的语言（Java、Python、Node.js、.NET），OTel 代理可以在不进行任何代码更改的情况下，将追踪注入到通用框架和库中。例如，使用 Spring Boot 的 Java 应用程序只需在启动时附加 OTel Java 代理，即可在 HTTP 调用、数据库查询和消息队列操作中获得分布式追踪。
eBPF：无需仪表化的可观测性
OpenTelemetry 革新了应用程序级别的可观测性。eBPF（扩展伯克利数据包过滤器）正在为基础设施和内核级别的可观测性带来同样的变革。
eBPF 允许您在 Linux 内核中运行沙盒化程序，而无需修改内核源代码或加载内核模块。这些程序可以附加到几乎任何内核函数或事件上，并以接近零的开销收集数据。
为什么 eBPF 对可观测性很重要
传统的基础设施监控依赖于代理，这些代理轮询 /proc 文件系统、解析日志文件或从用户空间拦截系统调用。这些方法要么是粗粒度的（缺少重要细节），要么是高开销的（消耗大量 CPU 和内存）。
eBPF 程序在内核空间运行，使它们能够访问从用户空间完全不可见的细粒度数据：
- 网络可观测性：eBPF 可以在内核级别检查每个数据包、每个 TCP 连接、每个 DNS 查询，而无需修改任何应用程序。像 Cilium 这样的工具使用 eBPF 在 Kubernetes 集群中执行网络策略和提供可观测性。
- 系统调用追踪：eBPF 可以追踪任何进程发出的每个系统调用，从而能够对 I/O 模式、文件访问和进程间通信进行详细分析。
- 安全监控：eBPF 程序可以实时检测可疑活动（意外的网络连接、权限提升尝试、文件完整性更改），且对性能影响最小。
- 应用程序分析：像 Parca 和 Pyroscope 这样的工具使用 eBPF 进行持续分析，捕获 CPU 和内存分配分析结果，而无需任何应用程序仪表化。
基于 eBPF 的可观测性工具
eBPF 可观测性生态系统已迅速成熟：
- Cilium 和 Hubble 提供 Kubernetes 原生网络和可观测性，使用 eBPF 捕获服务间通信模式，无需 sidecar。
- Pixie（现为 CNCF 的一部分）使用 eBPF 提供即时 Kubernetes 可观测性，无需任何检测工具—它可以直接从内核级网络事件中捕获 HTTP、gRPC、MySQL、PostgreSQL 和其他协议的完整请求/响应数据。
- Grafana Beyla 使用 eBPF 进行内核级自动检测，生成兼容 OpenTelemetry 的追踪和指标，无需接触应用程序代码甚至附加特定语言的代理。
- Tetragon 提供 eBPF 基础的安全可观测性，跟踪进程执行、文件访问和网络活动，用于安全事件检测。
关联：魔法发生之处
单个信号—追踪、指标、日志、配置文件—在孤立状态下是有用的。当它们相互关联时，才会产生变革性影响。现代可观测性平台擅长实现这些连接：
- 错误率指标触发警报。您点击查看导致错误率升高的示例追踪。
- 在追踪中，您识别出一个缓慢的数据库调用。您跳转到该服务在该时间窗口内的连续配置文件，查看 CPU 时间的使用情况。
- 配置文件显示特定锁上的争用。您检查与该追踪关联的结构化日志，查看触发争用的具体查询和参数。
这种调查工作流程—从症状出发，通过关联信号深入到根本原因—正是可观测性所能实现而传统监控无法提供的。
供应商格局
可观测性市场已围绕几家主要参与者整合，各具独特优势：
Datadog
Datadog 仍然是商业可观测性市场的领导者，提供统一平台，涵盖指标、追踪、日志、性能分析、安全等。其优势在于广度：如果您希望从单一供应商处获取所有服务，Datadog 能够满足。代价是成本—大规模使用时，Datadog 的账单可能成为重要支出项，其定价模式（每主机、每 GB 摄入量、每百万跨度）需要仔细管理。
Grafana Labs
Grafana Labs 构建了引人注目的开源优先可观测性堆栈：Grafana 用于可视化，Loki 用于日志，Tempo 用于追踪，Mimir 用于指标，Pyroscope 用于性能分析，Beyla 用于基于 eBPF 的自动检测。每个组件都可以独立部署，并使用成本效益高的对象存储后端。Grafana Cloud 为不想自行运行基础设施的团队提供托管版本。
Honeycomb
Honeycomb 开创了”可观测性作为一门学科”的运动，并仍然是高基数查询性能的黄金标准。如果您的主要需求是通过跨高维数据的临时查询来调查生产问题，Honeycomb 的查询引擎无与伦比。其 BubbleUp 功能能自动识别与异常行为相关的属性，对于根本原因分析非常有用。
成本优化：房间里的大象
可观测性数据量的增长速度超过了大多数团队的预期。一个中等规模的微服务架构每天可以轻松生成太字节的跟踪和日志数据，而摄取、存储和查询这些数据的成本是相当可观的。
实用的成本优化策略包括：
- 基于尾部采样： 不要在跟踪开始时随机采样（可能会丢失潜在的重要数据），而是在跟踪完成后在尾部进行采样。保留所有包含错误或高延迟的跟踪，并对成功且快速的跟踪按一定比例采样。OTel Collector 原生支持此功能。
- 日志过滤和转换： 在 Collector 管道中处理日志，以删除冗长的调试日志，提取结构化字段，并在将数据发送到后端之前降低基数。
- 分层存储： 对近期数据（小时到天）使用热存储，对历史数据（周到月）使用冷存储。许多后端支持自动分层到对象存储。
- 指标聚合： 在收集时预先聚合高基数指标。如果您不需要每个请求的指标，可以聚合到每分钟或每五分钟的窗口。
- 数据所有权： OpenTelemetry Collector 是您的数据控制平面。通过将所有遥测数据路由通过它，您保持独立于后端供应商过滤、转换、采样和路由数据的能力。
实用实施指南
对于刚开始其可观测性之旅或从传统监控迁移的团队，这里有一个务实的顺序：
第一阶段：使用 OpenTelemetry 进行检测
为您的主要语言部署自动检测。启用跨服务边界的跟踪上下文传播。仅此一项就能让您以最少的努力获得分布式跟踪。
第二阶段：部署 OTel Collector
将所有遥测数据路由通过 Collector。配置基本处理（批处理、属性丰富）。导出到您选择的后端。这建立了其他一切所依赖的数据管道。
第三阶段：添加自定义检测
使用自定义 span 和属性对业务关键路径进行检测。添加关键业务指标的指标（订单量、支付成功率、用户参与度）。带有跟踪关联 ID 的结构化日志。
第四阶段：使用 eBPF 实现基础设施可见性
部署基于 eBPF 的工具以实现网络可观测性和持续性能分析。这填补了应用级跟踪和基础设施级行为之间的空白。
第5阶段：关联与告警
构建跟踪、指标、日志和性能分析之间的关联。用异常检测和基于 SLO 的告警替代基于阈值的告警。启用基于样本的调查工作流程。
结论
2026 年的可观测性格局与五年前的监控世界已截然不同。OpenTelemetry 解决了工具碎片化问题。eBPF 在无需工具化的情况下解锁了内核级可见性。工具生态系统已经足够成熟，团队可以在没有巨额预算的情况下构建复杂的可观测性管道。
但技术本身是不够的。可观测性是一种实践，而非产品。它要求团队从被动告警转向主动调查，从看仪表板转向假设驱动的调试，从”什么坏了？”转向”为什么这个特定事物的行为与预期不同？”
工具已经就绪。标准已经成熟。剩下的挑战是组织层面的：建立有效使用可观测性数据的文化和技能。从 OpenTelemetry 开始，在合适的地方添加 eBPF，投资于关联功能，并将您的遥测管道视为关键基础设施。您的值班工程师会感谢您的。