核心要点
- 多云可观测性统一的四个硬骨头：数据口径、链路采样、告警路由、成本归集。
- 口径收敛以 OpenTelemetry 语义为目标，映射层是一次性投资、长期收益。
- 链路缝合最大的坑是采样策略不一致，全局头部采样是解。
- 成本数据纳入监控体系，让可观测性从成本中心变成省钱工具。
难点一：数据口径
各云的指标命名、粒度、聚合方式互不兼容，是多云统一的第一道坎。解法是建立映射层：定义内部统一语义，各云原始指标先归一化再入库。设计映射时直接以 OpenTelemetry 的语义约定为目标口径——它是行业收敛中的标准，把映射建立在开放标准上而不是自造方言，未来接入新云的成本会持续下降。工程细节上，粒度归一化要先行（统一到分钟级），聚合方式随后（统一为平均），顺序反了历史数据要重灌。
难点二：链路采样
调用链跨云缝合，最隐蔽的坑是采样策略不一致：A 云全采样、B 云按比例采样，部分请求的链路在 B 云根本没有记录，缝合出来依然是断的，而且这种断是随机的、难排查的。解法是全局统一的头部采样：入口服务决定是否采样，采样决策随上下文全链路传播（W3C Trace Context 的标志位就是干这个的），全链路要么都采要么都不采。另外两类容易被遗漏的传播场景：MQ 异步消息的属性传递、定时任务发起的调用——它们不在请求主路径上，但故障排查时一样需要链路。
难点三：告警路由
告警汇聚技术上简单（webhook 指向统一入口），规则归一才是硬骨头：三套静默规则、三套升级策略、三套值班分组，归一过程是治理谈判。推荐三段式：先物理汇聚透传不动规则，跑两周攒数据；再合并静默规则、按业务影响重排升级策略；最后做跨云关联收敛。这个顺序把技术问题和治理问题分开解决，避免一开始就陷入"谁的规则算数"的扯皮。
难点四：成本归集
多云的成本数据最散：账单格式不同、计费粒度不同、资源类型对不齐。但恰恰是成本数据，最能让管理层看到可观测性统一的价值。把三个云的实例利用率、闲置资源、账单趋势汇到同一张表，浪费会自己浮出来——临时实例忘了关、过配规格常年低载、僵尸磁盘散落各云。实践中很多团队第一个季度清理闲置资源的收益，就超过了监控体系本身的年费：可观测性不只是成本中心，它可以自己赚钱。
FAQ
各云的托管监控服务（如云监控、CloudWatch）要替换掉吗？
不用。它们在单云内部的深度（细粒度指标、云产品集成）是统一平台短期做不到的。分工是原厂管深度、统一层管决策，两边数据打通即可。
OTel 的接入对存量服务改动大吗？
取决于语言与框架。主流语言都有自动探针方案（agent 挂载即可），改造成本集中在少数需要自定义埋点的场景。建议按调用链路从入口向内分批灰度。
多云数据汇到一处，安全与合规怎么考虑？
三个层面：传输加密与最小权限的采集凭证、日志类数据汇聚前的脱敏（参照 OWASP 日志规范）、部署形态按合规要求选（有数据出境约束的选本地部署形态的统一平台）。
统一之后，跨云告警的关联怎么做的？
两层：时间窗加拓扑关联（同一时间窗内、依赖路径上相邻的告警合并为一个事件），以及基于历史模式的学习（重复出现的告警组合自动分组）。先做好第一层，第二层是锦上添花。
这个工程值得自研吗？
看团队定位。如果可观测性本身是你们的核心能力（平台工程团队），自研映射层与统一管道是合理资产；如果只是业务运维团队，采购一体化平台（如 Applications Manager 这类把多云、APM、成本做成一体的产品）把工程量外包出去更划算。
四个难点有没有推荐的攻坚顺序？
口径先行，成本殿后。先把指标映射层立起来（它是其他一切分析的地基），再做链路采样统一（需要服务改造，提前排期），然后告警路由归一（治理谈判为主），最后成本归集（纯接入工作，但它的报表产出最适合向上汇报立项成果）。整个工程按周迭代推进，三个月内可见全貌。
监控统一之后，容量规划能跟着受益吗？
能，而且是常被忽略的收益。三朵云的利用率数据同表对比后，扩容决策第一次有了跨云参照系：同样的负载下哪朵云的水位更高、规格怎么选更划算，一目了然。可观测性统一的终点不是大屏，是决策质量的提升。
