可观测性 2026 实战：Logs / Metrics / Traces 三剑客
在云原生与分布式时代，"看得见"比"跑得快"更难。一个跨多区域、多服务、多语言的系统每天产生 TB 级日志、亿级指标点、千万级请求链路。可观测性（Observability）就是把这些海量信号变成工程师能理解、能定位故障的体系。它通常被拆成三个基本支柱：日志（Logs）、指标（Metrics）、链路追踪（Traces）——业内俗称"三剑客"。Prometheus、Grafana、Jaeger、Loki、Tempo、ELK 是开源世界的代表组合；OpenTelemetry 在 2024 年迎来 Logs GA，已成为多厂商互通的事实标准；阿里云 SLS、ARMS 与腾讯云 CLS、APM 则是国内的生产级 SaaS。本文从信号模型、采集、存储、查询、告警、成本控制、中国云替代与实战部署八个维度系统拆解 2026 年的可观测性栈，帮助团队从"凑合用"走向"可量化运营"。
三大信号：Logs、Metrics、Traces 的本质差异
Logs 是离散的事件记录，包含时间戳、级别、消息与上下文。它的优势是细节最丰富——错误堆栈、请求体、外部调用响应都能完整保留；劣势是体积大、查询慢、聚合成本高。结构化日志（JSON 而非纯文本）是基础工程素养，方便机器检索与提取字段。日志的典型保留期是 7 到 30 天，重要审计日志可达数年。
Metrics 是带标签的时间序列数值。它的优势是密度极高、查询极快——百万指标点可在毫秒内聚合；劣势是只能反映"有多少"，无法反映"为什么"。Prometheus 的 PromQL 是当下最受欢迎的查询语言，支持 rate、sum、histogram_quantile 等聚合。指标用于看板、SLO、告警、容量规划，是观测的"骨架"。
Traces 描述一次请求在分布式系统中的传播路径。每次跨服务调用产生一个 Span，多个 Span 通过 Trace ID 串成一棵树，能直接看到 P99 延迟来自哪个下游、哪段 SQL 慢、哪次外部 API 卡住。Traces 是故障定位的"显微镜"。OpenTelemetry 把这三类信号统一在一个 SDK 与协议（OTLP）下，让采集与传输不再各自为战。
OpenTelemetry：行业统一的采集层
OpenTelemetry（OTel）是 CNCF 第二大活跃项目（仅次于 Kubernetes），由 OpenTracing 与 OpenCensus 合并而来，目标是为可观测性信号制定厂商中立的标准。截至 2026 年初，Metrics、Traces 早已 GA，Logs 信号也在 2024 年宣布稳定，至此三大支柱齐全。
OTel SDK 已覆盖 Java、Go、Python、Node.js、.NET、Rust、PHP、Ruby、Swift、JavaScript 等几乎所有主流语言。代码侧通过 Span、Counter、Histogram、Logger 等 API 生成信号；底层走 OTLP（gRPC 或 HTTP）协议送到 Collector。OTel Collector 是事实标准的边车与网关，支持几十种 Receiver 与 Exporter，能把同一份数据同时送到多个后端。
采纳 OTel 的最大价值是避免厂商 SDK 锁定。今天接 Datadog、明天换 New Relic、再后天接阿里云 ARMS，应用代码无需改动，只改 Collector 配置即可。Jaeger、Tempo、Loki、Prometheus 都已支持 OTLP，国内的阿里云 SLS、ARMS、腾讯云 APM 也已原生兼容。新项目几乎没有理由不用 OTel。
Metrics 栈：Prometheus 与水平扩展方案
Prometheus 是云原生 Metrics 的事实标准。它采用 Pull 模型，定期从目标 endpoint 抓取暴露的 /metrics，TSDB 存储 + PromQL 查询。社区生态丰富：node_exporter、cAdvisor、blackbox_exporter、redis_exporter 等覆盖几乎所有常见组件。Service Discovery 与 Kubernetes 紧密集成。
单机 Prometheus 适合中小规模——百万级活跃序列下查询毫秒级响应。规模上去后，水平扩展方案接力：Thanos 通过 Sidecar + Object Storage 做长期存储与全局查询；Cortex 与 Grafana Mimir 基于无状态查询节点 + 对象存储后端，已被许多大型团队采用；VictoriaMetrics 是国产替代之一，单机性能强、集群版本简洁；GreptimeDB 是新兴时序数据库，2025 年快速崛起。
Grafana 是 Metrics 可视化的事实标准。它能同时连 Prometheus、Loki、Tempo、CloudWatch、阿里云 SLS、腾讯云 CLS 等数据源，做统一看板。Grafana Cloud 提供托管版本，省去自建运维。生产环境建议把 Grafana 与 Prometheus 解耦部署，分别独立伸缩。
Logs 栈：从 ELK 到 Loki
日志栈历史最久。ELK（Elasticsearch + Logstash + Kibana）是十多年的经典组合，功能完整但运维门槛高、成本贵。OpenSearch 是 AWS 在 ES 切到 SSPL 后的开源分叉，已成为云上替代。
Loki 是 Grafana 团队推出的"轻量日志"，理念是"只索引标签、不索引日志正文"，存储成本只有 ES 的 1/10。Loki 与 Grafana 深度整合，配合 Promtail 或 OTel Collector 采集，是 Kubernetes 环境的常见选择。LogQL 与 PromQL 风格类似，学习成本低。
Vector 与 Fluent Bit 是当下最主流的日志采集器，比 Logstash/Fluentd 更轻量，资源占用极低。它们支持 OTLP、Kafka、Loki、ES、SLS、CLS 等几乎所有后端。日志的最大成本不是采集而是存储与索引，因此结构化、采样、分级、冷热分层是必须的工程素养。
Traces 栈：Jaeger 与 Tempo
Jaeger 是 Uber 开源的分布式追踪系统，已成 CNCF 毕业项目。它的存储后端可选 Cassandra、Elasticsearch、Kafka，UI 简洁。Jaeger 在 2024 年发布 v2，全面拥抱 OTel：Jaeger Collector 直接走 OTLP，数据模型对齐 OTel Trace。
Grafana Tempo 是另一个流行选项，理念与 Loki 一致："只用 Trace ID 索引、其他丢对象存储"，把 Tracing 成本压到极低。Tempo 的查询是基于 Trace ID 直接拉取，不支持复杂搜索；要做"找慢请求"等查询需要先用 Metrics（Span Metrics）筛出 Trace ID 再调 Tempo。
实战中两者各有取舍：Jaeger 自带搜索 UI，Tempo 成本更低但依赖 Grafana 生态。许多团队用 Tempo 做长期低成本存储，对热数据继续保留 Jaeger UI。OpenTelemetry Collector 可以同时把 Trace 数据 export 到两边。中国云上阿里云 ARMS、腾讯云 APM 都是托管 Trace 的成熟方案。
中国云替代：SLS、ARMS、CLS、APM
阿里云日志服务（SLS）是国内最强大的日志平台之一，按 GB 写入与索引计费，支持 SQL 查询、机器学习异常检测、可视化看板、告警。SLS 的 Logtail 与 OTel Collector 都能采集，并支持冷热分层（热数据存 SSD、冷数据放 OSS），整体成本可降 50% 以上。
阿里云应用实时监控服务（ARMS）覆盖 APM、Prometheus、链路追踪、用户体验监控（前端）、容器监控、告警等，是一体化方案。Managed Service for Prometheus 与 Managed Service for Grafana 让团队不用自建。腾讯云对应产品是 CLS（日志）、APM（应用监控）、TPMP（Prometheus 托管），与微信生态、CDN、COS 整合好。
华为云有 LTS（日志）与 APM；火山引擎也已上线类似产品。国产可观测性产品近两年快速追赶，对国内业务尤其在合规、网络延迟、中文支持、按量计费上有显著优势。出海团队倾向自建 Prometheus + Loki + Tempo 或用 Datadog、New Relic；国内团队用阿里云 SLS + ARMS 或腾讯云 CLS + APM 是常见组合。
日志成本控制：可观测性的生死线
许多团队第一次用 SaaS 可观测性都会被账单吓一跳。日志按 GB 计费，一个中等规模微服务集群每天产生 200GB 到 1TB 日志，半年就能花几十万。控制策略有四个层面。
第一是分级。DEBUG 仅本地或预发使用，生产关闭；INFO 默认保留 7 天；WARN/ERROR 保留 30 到 90 天；审计与合规日志按法规保留 1 到 3 年。第二是采样。访问日志按 1% 到 10% 概率抽样，错误请求 100% 全量；OTel Collector 提供 tail-based sampling，能在追踪结束后根据是否有 Error 决定是否保留。第三是结构化与字段裁剪。JSON 比纯文本压缩率高一倍，去除多余字段（无关 header、过长 body）能砍 30% 体积。第四是冷热分层。热数据放快查存储（SSD/ES）保留几天，冷数据归档到对象存储（S3、OSS、COS），按需用 Athena/Hologres 查询。
实施这四项后，团队整体日志成本通常能砍掉 50% 到 80%。同样适用于 Trace（用 head-based 与 tail-based 采样）与 Metrics（合理设置 cardinality 上限）。可观测性是工程问题也是经济问题。
告警疲劳治理与 SLO 驱动
告警疲劳是大型 SRE 团队的隐形杀手。当一个工程师每天收到几十条告警、其中 90% 不需要处理，他会本能地无视所有告警，包括真正关键的那条。治理告警疲劳的方法是结构化的工程实践。
分级是基础。P1 立即电话叫醒值班；P2 即时 Slack/钉钉/企业微信通知；P3 工作时间汇总邮件；P4 仅记录到看板。聚合避免重复——同一根因的多条告警合并为一条。抑制让依赖告警不重复触发：当数据库挂掉时，所有依赖它的服务告警都被抑制。Alertmanager、PagerDuty、阿里云 ARMS 告警平台、Splunk OnCall 都支持这些能力。
更高阶是 SLO 驱动。Google SRE 提出的 Error Budget 概念让告警从"指标超阈值"升级到"错误预算燃烧太快"。比如 SLO 是 99.9% 可用，月预算是 43 分钟错误；按当前燃烧速率 6 小时会烧完，就触发 P1。这种基于业务影响而非技术阈值的告警大幅减少误报。每个告警都必须配 runbook，写清"当此告警触发时第一步做什么"，新人到岗也能快速响应。健康团队每周告警总量应是个位数，每条都值得人工处理。
2026 实战部署模式与建议
组合一：开源自建。OTel Collector 边车 + Prometheus + Loki + Tempo + Grafana。适合有专门 SRE 团队、希望最大灵活性、对成本敏感的中大型公司。运维成本不低，但长期看比 SaaS 便宜很多。规模化时 Prometheus 升级到 Mimir，Loki 与 Tempo 配 S3 做长期存储。
组合二：云厂商一体化。国内用阿里云 SLS + ARMS 或腾讯云 CLS + APM；海外用 AWS CloudWatch + X-Ray、Azure Monitor、GCP Cloud Operations。优点是开箱即用、按量付费、与云厂商其他服务深度整合；缺点是绑定深、长期成本高。适合中小团队与初创公司。
组合三：商业 SaaS。Datadog、New Relic、Splunk、Dynatrace 是面向欧美市场的成熟选项，开发体验好、AI 异常检测强；价格不便宜（百万 USD 级是常态）。建议头部互联网企业核心业务采用。无论选哪种组合，都要做好两件事：一是用 OpenTelemetry 统一采集层，避免锁定；二是建立 SLO 与 Error Budget 文化，让可观测性服务于业务质量，而不是仅技术展示。最后提醒：可观测性是基础工程，从第一天就要做对，否则故障定位时间会以小时计。
常见问题
OpenTelemetry 已经成熟到能上生产了吗？
完全可以。OTel 在 2024 年宣布 Logs 信号 GA，至此 Metrics、Traces、Logs 三大信号全部稳定。各主流语言 SDK（Java、Go、Python、Node.js、.NET、Rust）都已正式版，OTel Collector 是事实标准的边车收集器。Jaeger、Tempo、Loki、Prometheus、Datadog、New Relic、阿里云 SLS、腾讯云 APM 均原生兼容 OTLP 协议。建议新项目直接采用 OTel，避免被单一厂商 SDK 锁定。
日志成本怎么控制才合理？
日志是可观测性最大的成本黑洞。控制策略有四：一是分级，DEBUG 不进生产，INFO 设保留 7 天，ERROR/审计设 30 到 90 天；二是采样，高频访问日志按 1% 到 10% 抽样，错误日志全量；三是结构化，用 JSON 而非纯文本，方便压缩与索引；四是冷热分层，热数据 7 天放快查存储，冷数据放对象存储归档。阿里云 SLS、腾讯云 CLS 均支持冷热分层，自建 Loki 配合 S3 也能实现，整体成本可降 50% 到 80%。
Prometheus 适合所有规模吗？
不适合超大规模。单机 Prometheus 在 100 万到 500 万活跃序列下表现良好，再上去内存与查询延迟都会爆炸。规模化方案有 Thanos（去重、长期存储、全局查询）、Cortex 与 Mimir（基于 Cassandra/对象存储的水平扩展）、VictoriaMetrics（高性能单机 + 集群版本）。GreptimeDB 是国产新秀，Grafana Mimir 在云原生 SaaS 上口碑很好。中小团队 Prometheus 单机 + 远端写入到对象存储足够，年容量超过千万指标时再迁移。
中国云厂商有哪些可观测性产品？
阿里云有 SLS（日志服务，最强大的国产日志平台之一）、ARMS（应用实时监控服务，APM + Prometheus + 链路追踪一体化）、Managed Service for Prometheus、Managed Service for Grafana。腾讯云有 CLS（日志服务）、APM、TPMP（Prometheus 托管）。华为云有 LTS 与 APM。火山引擎也已上线类似产品。这些托管服务比自建 Prometheus + Grafana 更便宜（按量付费）也更省运维，但代价是与厂商生态绑定。
怎么避免告警疲劳？
告警疲劳的根源是"什么都告警"导致工程师麻木。治理方法有：分级（P1 立即电话、P2 即时通知、P3 工作时间汇总）、聚合（同一根因合并为一条）、抑制（依赖告警不重复）、SLO 驱动（基于错误预算燃烧速率告警，而非单点指标）、轮值与值班手册（runbook）配套。把无效告警每周梳理一次，删除或调阈值。一个健康团队的告警量应该是每周个位数，每条都需要人工处理；如果一天几十条没人看，等于零告警。