本文定位：可观测性平台建设面向正在建设统一观测能力的平台团队、SRE 和研发负责人，重点讨论指标、日志、链路三类信号如何分层，不展开单个后端工具的安装教程。
可观测性平台不是把 Prometheus、日志系统和 Trace 后端放到一个菜单里。真正可用的平台，需要回答三个问题：哪些信号进入平台、在哪里治理这些信号、故障发生时能不能从告警一路追到上下文。
OpenTelemetry 将 traces、metrics 和 logs 作为遥测数据的核心信号，并提供统一采集与导出模型[1]。因此，平台建设的第一步不是选工具，而是给三类信号明确职责边界。
如果团队还在规划 Collector 管道，可以结合站内 OpenTelemetry Collector管道部署-采样路由与故障降级 阅读，先把数据入口和处理策略想清楚。
先把三类信号放到不同层级
三类信号的使用方式不同，不能只按“采集到同一个后端”来设计。
| 信号 | 主要回答的问题 | 平台治理重点 |
|---|---|---|
| 指标 Metrics | 系统是否异常，异常是否持续 | 指标命名、基数控制、告警窗口、SLO 关联 |
| 日志 Logs | 发生了什么，异常上下文是什么 | 字段结构化、脱敏、保留周期、检索成本 |
| 链路 Traces | 请求经过哪里，慢在哪一段 | 采样策略、关键路径保留、Trace 与告警关联 |
图1：可观测性平台通过指标、日志和链路三类信号分层，形成症状映
核心判断是：指标负责发现，日志负责解释，链路负责定位路径。把三类信号混在一起使用，容易让告警靠日志检索支撑、让 Trace 承担报表职责，最终造成成本和排障体验同时失控。
指标层优先服务告警和趋势
指标层最重要的是稳定、低延迟和口径一致。Prometheus 官方文档强调指标由 metric name 与 labels 组成，labels 会决定时间序列维度[2]。这意味着高基数标签会直接放大存储和查询压力。
指标层建设建议先收敛：
- 命名规范：业务、平台、基础设施指标分组管理。
- 标签边界：避免把用户 ID、请求 ID、动态路径放进指标标签。
- 告警窗口：区分瞬时抖动、持续异常和容量趋势。
- 服务目标：把核心 SLI 与 SLO 绑定，减少无行动价值告警。
指标层不适合承载完整事件上下文。遇到需要解释原因的问题，应通过告警标签跳转到日志或链路，而不是把所有上下文字段都塞进指标。
日志层要先治理结构和保留周期
日志的价值在于上下文，但它也是最容易膨胀的信号。平台层需要统一字段规范、敏感信息处理和保留策略，否则日志后端会变成“什么都能查，但谁也查不快”的系统。
日志进入平台前至少检查：
- 业务日志是否结构化，例如 JSON 或固定字段。
- 是否包含 Token、手机号、Cookie、身份证号等敏感信息。
- 是否能按应用、命名空间、环境、Trace ID 关联查询。
- debug、info、warn、error 是否有不同保留周期。
- 审计日志是否与普通应用日志分开管理。
日志不要替代事件与审计
很多团队会把 Kubernetes 事件、应用日志、审计日志混在一个索引里。短期看检索方便，长期看会带来权限和成本问题。审计类日志往往涉及合规和追责，应独立设置保留周期、访问权限和导出策略。
链路层重点是采样和关联
链路追踪最适合回答“请求在哪一段变慢或失败”。但 Trace 数据量通常随请求量增长，平台层必须设置采样、保留和关联规则。OpenTelemetry Collector 支持 tail sampling processor，用于在看到完整 trace 后再做保留决策[3]。
链路层优先保留：
- 错误请求、异常状态码和超时请求。
- 核心业务路径，例如登录、支付、任务提交。
- 发布变更、灰度流量和故障窗口内请求。
- 与重要告警同时间段、同服务、同租户相关的 Trace。
采样策略不应写成固定比例答案。不同系统的请求量、错误率、存储预算和排障需求差异很大，更稳妥的做法是先定义保留优先级，再用数据量反推采样策略。
平台层能力要围绕信号生命周期建设
可观测性平台应覆盖从采集到消费的完整链路，而不是只提供几个查询入口。
| 生命周期 | 平台要做的事 | 常见风险 |
|---|---|---|
| 采集 | SDK、Agent、Collector、Exporter 标准化 | 入口太多，字段不一致 |
| 处理 | 过滤、脱敏、采样、批处理、路由 | 策略散落在应用侧 |
| 存储 | 指标、日志、Trace 分开定级 | 所有数据同等保留 |
| 查询 | 告警跳转、跨信号关联、租户隔离 | 只能单系统检索 |
| 运营 | 容量、成本、SLO、规则审计 | 告警和成本无人负责 |
告警闭环决定平台是否真的可用
观测数据如果不能驱动行动，就只是数据湖。平台建设要把告警规则、负责人、升级路径和复盘证据放进闭环。
一条可执行告警至少包含：
- 告警表达式和触发窗口。
- 受影响服务、环境、租户或集群。
- 推荐查看的日志查询条件或 Trace 入口。
- 初步 Runbook 或处理建议。
- 告警关闭后的复盘记录入口。
这也是可观测性平台和单点监控工具的差别：平台不仅收数据，还要让数据进入稳定性治理流程。
图2：可观测性平台按采集、处理、存储、查询和运营组织信号生命周
成本边界从第一天就要定义
可观测性成本通常不是某个工具突然变贵，而是数据生命周期缺少规则。高基数指标、全量 debug 日志、无限保留 Trace、无边界的多租户查询，都会让平台逐步失控。
成本治理可以从四个问题开始：
- 哪些数据必须实时查询，哪些只需要归档？
- 哪些服务需要完整 Trace，哪些服务只保留错误 Trace？
- 哪些日志字段可以采集，哪些字段必须脱敏或丢弃？
- 哪些团队、环境、租户需要独立预算和用量视图？
可观测性平台越早建立这些边界，后期越容易扩展。否则等到数据规模变大后再治理，往往需要同时改 SDK、采集管道、后端索引和团队习惯。
图3：可观测性平台成本边界检查清单，从实时查询、Trace 保
小结
可观测性平台建设的关键，不是把三类工具部署齐，而是把指标、日志、链路追踪放到合适层级：指标用于发现异常，日志用于解释上下文，链路用于定位请求路径。平台层再统一采集、处理、存储、查询、告警和成本治理，才能让观测数据真正服务排障和稳定性改进。
如果只能先做一件事，建议从信号分层和告警闭环开始，而不是直接扩大采集范围。
原创声明：本文为 CNBPA 云原生社区原创技术内容，非商业转载须注明出处：https://www.cloudnative-tech.com/p/9354/。文中原创图示、架构图和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
参考资料
- [1] OpenTelemetry Observability Primer
- [2] Prometheus Data Model
- [3] OpenTelemetry Collector tail sampling processor
常见问题
1. 可观测性平台必须同时建设指标、日志和链路吗？
不一定。多数团队可以先从指标和告警做稳定性基线，再补日志结构化和链路追踪。关键是提前定义三类信号的职责，避免后续每个团队用不同方式接入。
2. 可观测性平台和监控平台有什么区别？
监控平台更强调指标采集和告警；可观测性平台还要覆盖日志、链路追踪、跨信号关联、采样、脱敏、成本和复盘闭环。它更关注“如何解释系统行为”，而不是只判断系统是否异常。
3. 三类信号都进入同一个后端是否更简单？
小规模场景可以降低接入成本，但规模扩大后要看后端是否能分别处理指标、日志和 Trace 的存储模型、查询模型和保留策略。若缺少分层治理，统一后端也可能变成统一瓶颈。
4. 可观测性平台建设最容易忽略什么？
最容易忽略的是成本边界和责任边界。没有采样、保留周期、字段脱敏和告警负责人，平台很快会出现数据很多、查询很慢、告警很多但没人处理的问题。
