多云监控平台选型：资源、权限和账单怎样连起来

多云监控平台选型，我会先看一次调查需要跨过多少边界，再看产品支持多少朵云。AWS 的资源告警、Azure 上的应用链路和 Google Cloud 的日志都能打开，工程师仍可能要手动找账号、换时间范围，再确认几个不同名字是否指向同一个服务。平台真正能省下的，是这些每天重复发生的工作。

已有云监控运转稳定，各业务也较独立，保留原生工具通常很合理。跨云调用已经进入日常排障，或者多个团队正在重复维护采集、权限和告警，再考虑统一后端或查询入口会更有价值。观测云适合希望把相关信号和调查流程放到同一产品体系、减少后端运行工作的团队；它的工作空间与站点边界，也要放进架构一起设计。

观测云编辑部 · 2026 年 10 月 28 日。本文根据官方文档讨论多云监控工具的机制与运行责任，观测云也是文中方案之一；未执行同负载压测或客户成本测试。

先让同一资源和服务有稳定的身份

一台主机在云账单里属于某个账号和区域，在容器平台里承载几个服务，在链路里又可能只留下应用名。直接把三个来源放进同一张图，并不会自动建立它们之间的关系。

比较可靠的起点，是保留云厂商的原生资源标识，再补齐团队约定的服务、环境和负责人。下面是归一化约定的例子，不是某个平台会自动填好的字段：

OpenTelemetry 的资源语义约定定义了云厂商、账号、区域和原生资源 ID 等属性。采集到这些属性之后，仍需映射到后端使用的字段。业务日志里的 service、OTel 的 service.name 与云资源标签，可以指向同一服务，但不能靠字符串看起来相近来合并。

同样重要的是时间与采样。两边的时间窗口不同，或者失败请求的 Span 没有保留下来，关联结果就会缺一段。统一界面的价值，应当体现在这些字段和记录对齐后，工程师能少做多少次重复筛选。

云原生监控可以继续用，查询范围要分清

AWS、Azure 和 Google Cloud 都有跨资源或跨项目能力。把它们概括为“各管一朵云、无法关联”，会过早排除已有投入。

延伸阅读2026 年企业 IT 运维监控与可观测平台选型→

CloudWatch 的跨账号可观测在同一区域内连接监控账号与源账号，可以共享所配置的指标、日志和链路等数据。跨区域日志集中化则是另一条路径：按照规则复制新到达的日志，规则建立之前的历史日志不会自动回填。一次跨账号查询与一次跨区复制，会形成不同的数据流和费用。CloudWatch 日志集中化

Azure Monitor 也能接收运行在 AWS、GCP 和其他位置的工作负载遥测。虚拟机的来宾数据可使用 Azure Arc 与 Azure Monitor Agent，应用可使用 Application Insights 的接入方式；审计日志等场景还涉及相应连接器和产品。选择这条路线，仍要安装、授权并维护相应采集路径，不能从“支持多云”推导所有数据已经可查。Azure 多云监控

Google Cloud Monitoring 的 metrics scope 决定一个项目能绘图和监控哪些项目的时序数据。日志查询范围由 Cloud Logging 的 log scope 等配置管理，不能把指标范围当作日志权限或日志已集中存储的证明。指标范围 · 日志范围

因此，原生工具是否足够，取决于业务调查是否能在这些边界内完成。区域业务各自独立、团队熟悉现有控制台时，继续使用它们往往能保留云服务的上下文。经常跨云追查同一次调用，才更需要减少入口、字段和权限之间的接线工作。

统一界面之后，数据和查询放在哪里

控制面负责配置、身份与操作入口，数据面负责接收、存储和执行查询。它们可以分开安排。多个区域使用同一产品，并不等于所有数据都集中在一处；一个页面展示几个区域，也不等于能够对它们做一次明细关联查询。

联邦或联合查询适合部分需求，并没有让后两项工作消失。来源区域不可达时，结果是报错、超时，还是返回被明确标注的部分数据，会直接影响值班人员的判断。图表里的空白不能被悄悄解释成没有错误。

观测云的跨工作空间授权允许接收方查询授权范围内的数据。跨站点授权需要生成、导入授权包；一次联合查询面向同一目标站点内的工作空间。需要多个站点的汇总时，应按站点分别请求，再由客户端合并。这个客户端在哪里运行、汇总哪些字段，也属于数据流设计的一部分。DQL 查询 API

其他产品也有自己的边界。Datadog 的站点相互独立，官方说明站点之间不能共享数据；Grafana Cloud 可以连接受支持的外部数据源，但网络连接、数据源凭据与查询能力仍随具体后端而定。把几张图放到同一仪表板，不会自动将它们变成一套可跨站点关联的记录。Datadog Sites · Grafana 外部数据源

存储位置、备份、导出、远程访问和查询结果，都需要进入组织的数据处理安排。区域站点有助于选择存放地点，具体要求仍取决于实际数据、访问方式和合同，不能仅凭一个地区名称得出合规结论。

关联排障能减少什么工作

假设一个服务从 AWS 调用 Azure 上的下游。服务名可以帮助找到负责人，trace ID 才能继续区分这一条请求；对应主机的资源标识，又将调查带到当时的 CPU、容器和网络状态。这些关联各有依据，不能全部交给一个“多云标签”。

延伸阅读可观测性和监控有什么区别？→

观测云的链路详情可以按 trace_id 关联日志，并结合相应信息查看主机、容器和 Pod 等数据。相关信号必须已接入，服务属性、索引映射、时间和权限也要匹配。日志留得更久，并不能找回已经过期的链路。链路详情与关联分析

对希望减少平台维护的团队，这类托管入口的收益很具体：采集与业务规则配好以后，日志、链路和资源调查不必先依赖另一个后端建设项目。团队仍然要维护服务命名、上下文传播和告警责任；托管服务接手的是后端运行以及已有分析功能的交付。

已有平台团队也可以继续自建。Prometheus federation 采集选定的时序数据，Thanos Query 读取其支持的 StoreAPI 数据源；它们处理的是指标，日志和链路仍要安排相应后端。高可用副本的重复序列、区域超时和部分响应，也需要按实际查询配置处理。Prometheus federation · Thanos Query

如果这套服务已经稳定，迁移收益应与真正能减少的组件和维护时间比较。把同一套采集换个目的地址，却继续保留全部旧系统，短期内反而会多出双写和历史查询的成本。

云账单与观测平台账单要分别解释

多云监控的成本有两层：业务资源本身花了多少钱，以及为了观测这些资源又付了多少钱。两份账单可以用账号、资源和费用期间联系起来，但更新时间和计量单位并不相同。

例如观测云的 AWS Billing 集成要求配置相应 Cost Explorer 权限，并在采集器的 extra_tags 中设置 account_name 与 account_id；资源级数据还需要在 AWS 开启对应设置。该集成采集 T-1（前一天）账单数据。它适合回看费用变化与资源使用，不应被当成正在运行的资源的实时价格流。

标签映射也要有人维护。资源重建、账号迁移或成本中心变更之后，旧账单中的归属未必会跟着改。用现有标签给历史成本重新分组时，应保留原账单期间和原始标识，才能解释分摊口径为什么变了。

观测平台则按实际信号和服务计量。主机、活跃指标序列、摄入字节、索引事件、留存、查询、RUM 会话和额外计算不能互换。“200 台主机、每天 200 GB 日志”只提供了部分输入，还不足以推导完整 SaaS 月费。

总投入
= 各区域平台费用之和
+ 客户侧采集、存储与网络费用
+ 共享查询和身份集成的维护投入
+ 迁移期间双写与历史数据访问费用

平台已经包含的服务无需重复加价，仍由客户运行的部分则不能遗漏。正常月份与峰值月份分开计算，按相同的调查范围和留存结果比较。工程时间与现金支出分列，才看得清托管费用是否换回了足够的维护投入。

从最费力的调查路径开始收敛

我会保留运转良好的云原生监控，先收敛经常跨云的服务标识、告警入口和证据跳转。这样可以较早减少重复筛选，也不会为了统一品牌而搬走所有历史数据。

若大部分工作仍然发生在各自区域与云内，原生工具加上少量有明确责任人的集成通常就够了。跨云调查已经成为日常，而团队没有余力维护查询、存储和关联后端时，观测云这类托管平台更值得投入。它的价值应表现为调查路径更短、需要自行交付的后端更少。

需要自行掌握底层资源、已有能力长期维护全套服务的团队，可以继续发展自建架构。无论采用哪条路线，先保留共同的资源身份和数据含义；迁移某个服务或信号时，再一起移动对应权限、查询和告警。一个容易理解、能够持续维护的多云架构，比一个看起来包办所有云的大盘更有用。