出海企业多云可观测性架构实战：Prometheus+Grafana 统一监控与告警治理（2026最新版）

Meta Description: 出海企业阿里云+AWS+腾讯云监控割裂、告警轰炸怎么办？本文给出 Prometheus+Grafana+Thanos 统一可观测性架构，覆盖指标采集、日志聚合、链路追踪与 Alertmanager 告警治理，附完整命令与 Terraform 配置。

关键词： 多云可观测性、Prometheus监控、告警治理、CloudWatch、SLS日志服务、Grafana、OpenTelemetry

前言：先给结论

出海企业做多云可观测性，最务实的路径是：指标层用 Prometheus 生态统一（Grafana 展示、Thanos 长期存储），日志层在各云内就近采集、按需中心化汇聚，链路层用 OpenTelemetry 一次埋点、三朵云通吃，告警层用 Alertmanager 统一路由与值班轮换。不要在每朵云里各建一套大而全的监控台——那只会换来三倍的费用、三套告警和三倍的运维负担。本文以阿里云+AWS+腾讯云三朵云为例，从架构设计到落地命令逐步拆解。

一、出海企业为什么需要统一可观测性

先看三个真实场景：

场景 1：双活业务，故障定位靠猜。 业务同时在阿里云（新加坡）和 AWS（新加坡）运行，负载均衡在两边各半。某天订单量下跌 30%，运维团队打开阿里云云监控——指标正常；打开 AWS CloudWatch——也正常。折腾两小时后才发现是跨境专线抖动，而两边监控面板各看各的，谁都没把网络链路纳入视野。没有统一视图，MTTR 平均比单云环境高出 40% 以上。

场景 2：告警轰炸，真故障被淹没。 三朵云各自配置了告警：CloudWatch 阈值告警 5 条、阿里云云监控 8 条、腾讯云云监控 3 条，凌晨 2 点可能同时收到十几条通知。监控界有个著名统计：当告警每天超过 20 条时，工程师对告警的响应率会急剧下降，真正的 P1 故障反而被当成"狼来了"。告警疲劳不是管理问题，是架构问题。

场景 3：日志割裂，排查要跨系统。 一条订单从用户请求到支付回调，前半段日志在 AWS CloudWatch Logs，后半段在阿里云 SLS。排查问题时要在两个控制台之间反复切换，用 trace ID 关联日志基本靠手工。

统一可观测性的本质，是把三朵云的数据平面拉平：指标、日志、链路三类数据各有一个统一的汇聚与查询入口，告警只有一个出口。下面按可观测性三支柱逐一展开。

二、可观测性三支柱与工具选型

可观测性（Observability）由三个支柱构成：指标（Metrics）、日志（Logs）、链路（Traces）。三朵云的产品映射如下：

选型三条原则：

1. 指标用开源统一，避免厂商锁定。 Prometheus 是事实标准，三朵云都提供兼容 Prometheus 的托管方案（阿里云 ARMS Prometheus、AWS AMP、腾讯云 TPM），即使自建也毫无障碍。指标是监控的"骨架"，必须握在自己手里。
2. 日志按地域就近采集、按需汇聚。 日志是数据量最大的支柱，跨地域/跨云全量传输成本极高。正确做法是每个云内用 Fluent Bit 就近写入本云日志服务，只把需要跨云检索的关键业务日志汇聚到一处（对象存储 + 统一检索）。
3. 链路用 OpenTelemetry 标准。 OTel 是 CNCF 的事实标准，SDK 一次埋点，通过 Collector 可同时导出到 X-Ray、ARMS、自建 Jaeger 等多个后端，彻底解决"换云就要换埋点"的噩梦。

三、总体架构：两图看懂

先看全景 mermaid 图：

graph TD
    subgraph 阿里云[阿里云 新加坡]
        A1[ACK 集群] --> A2[Prometheus]
        A3[SLS 日志服务] --> A4[Fluent Bit]
        A2 --> A5[Thanos Sidecar]
        A5 --> A6[(OSS 对象存储)]
    end
    subgraph AWS[AWS 新加坡]
        W1[EKS 集群] --> W2[Prometheus]
        W3[CloudWatch Logs] --> W4[Fluent Bit]
        W2 --> W5[Thanos Sidecar]
        W5 --> W6[(S3 对象存储)]
    end
    subgraph 腾讯云[腾讯云 新加坡]
        T1[TKE 集群] --> T2[Prometheus]
        T3[CLS 日志服务] --> T4[Fluent Bit]
        T2 --> T5[Thanos Sidecar]
        T5 --> T6[(COS 对象存储)]
    end
    A2 --> G1[Thanos Querier]
    W2 --> G1
    T2 --> G1
    G1 --> G2[Grafana 统一大盘]
    A3 --> L1[中心日志检索]
    W3 --> L1
    T3 --> L1
    A1 --> O1[OTel Collector]
    W1 --> O1
    O1 --> O2[统一链路后端]
    G2 --> AM[Alertmanager]
    AM --> O3[值班通知]

再看分层 ASCII 图：

┌─────────────────────────────────────────────────────────────┐
│                      展示层                                  │
│   Grafana 统一大盘（三朵云指标同屏）  +  统一日志检索          │
├─────────────────────────────────────────────────────────────┤
│                      告警层                                  │
│   Alertmanager：路由 / 分组 / 静默 / 抑制 / 值班轮换          │
│   （企业微信 / 钉钉 / Slack / PagerDuty 单出口）              │
├─────────────────────────────────────────────────────────────┤
│                      汇聚层                                  │
│   Thanos Querier（跨云全局查询）  +  OTel Collector（链路）   │
├─────────────────────────────────────────────────────────────┤
│                      采集层（云内就近）                       │
│  阿里云: Prometheus+SLS │ AWS: Prometheus+CloudWatch Logs    │
│  腾讯云: Prometheus+CLS │ 每朵云 Fluent Bit + 云监控 Exporter │
├─────────────────────────────────────────────────────────────┤
│                      存储层                                  │
│  指标: OSS / S3 / COS 对象存储（Thanos 长期归档，成本极低）   │
│  日志: SLS / CloudWatch Logs / CLS（按留存策略各自保留）      │
└─────────────────────────────────────────────────────────────┘

架构要点：采集层每朵云内自包含（避免跨云公网流量费），指标通过 Thanos 汇聚为单一查询入口，告警统一由 Alertmanager 出口，日志只做关键业务汇聚。

四、指标层落地：Prometheus 统一采集三朵云

4.1 云监控指标接入 Prometheus

三朵云的托管指标（EC2 CPU、ECS CPU、CVM 指标等）无法被 Prometheus 直接抓取，需要各自的 Exporter 拉取后转为 Prometheus 格式：

以 AWS cloudwatch-exporter 为例，采集 EC2 CPU 与 RDS 连接数：

region: ap-southeast-1
metrics:
  - aws_namespace: AWS/EC2
    aws_metric_name: CPUUtilization
    aws_dimensions: [InstanceId]
    aws_statistics: [Average]
    period_seconds: 300
  - aws_namespace: AWS/RDS
    aws_metric_name: DatabaseConnections
    aws_dimensions: [DBInstanceIdentifier]
    aws_statistics: [Average]
    period_seconds: 300

启动命令：

// 下载并启动（以 v0.15.0 为例）
curl -LO https://github.com/prometheus-community/cloudwatch-exporter/releases/download/v0.15.0/cloudwatch_exporter-0.15.0.jar
java -jar cloudwatch_exporter-0.15.0.jar --config.file=cloudwatch.yml

// 验证指标
curl -s localhost:9106/metrics | grep aws_ec2_cpuutilization_average | head -3

费用提醒：CloudWatch GetMetricData 按请求计费（每 1000 个 API 请求约 $0.01），采集间隔从 60 秒放宽到 300 秒，每月成本可下降 80%；同时用维度白名单只采集真正需要的资源，避免"全量拉取"式烧钱。阿里云与腾讯云 exporter 同理，务必用只读子账号 AK/SK，权限只给上表中的最小 API。

4.2 Prometheus 本体：云内部署 + remote write

每个云内跑一套 Prometheus（可用 kube-prometheus-stack 一键部署），负责本云指标采集与短周期告警；长期数据通过 Thanos Sidecar 上传对象存储。跨云全局查询走 Thanos Querier，规则如下：

// prometheus.yaml 关键段：remote write 到 Thanos Receiver
remote_write:
  - url: https://thanos-receiver.internal:19291/api/v1/receive
    queue_config:
      max_samples_per_send: 5000
      capacity: 100000

对象存储按云就近：阿里云用 OSS、AWS 用 S3、腾讯云用 COS，Thanos 只需在 Querier 侧配置 StoreAPI 网关即可跨云查询，Grafana 数据源直接指向 Thanos Querier，一张大盘看三朵云。

五、日志层落地：就近采集 + 中心汇聚

5.1 三朵云日志服务对比

5.2 推荐模式：双活对等 + 关键日志汇聚

双活架构下不建议把全部日志跨云传输（成本高、延迟高、还涉及数据出境合规）。推荐"本地全量 + 关键汇聚"：

1. 本地全量：每朵云内 Fluent Bit DaemonSet 采集全部业务日志，写入本云日志服务，保留 30 天热数据；
2. 关键汇聚：订单、支付、风控等核心日志，通过跨云订阅/投递到统一对象存储（OSS 或 S3），由中心日志平台检索，长期保留 180 天用于审计。

Fluent Bit 配置（K8s 内采集并输出到本云日志服务）：

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
data:
  output.conf: |
    [OUTPUT]
        Name            cloudwatch_logs
        Match           *
        region          ap-southeast-1
        log_group_name  app-logs
        log_stream_prefix from-fluent-bit-
        auto_create_group true

AWS 侧把核心日志订阅到 S3 的命令：

// 创建订阅过滤器，把 app-logs 投递到 S3 归档桶
aws logs put-subscription-filter \
  --log-group-name app-logs \
  --filter-name to-s3-archive \
  --filter-pattern "" \
  --destination-arn arn:aws:logs:ap-southeast-1:123456789012:destination:s3-archive

合规提醒：日志留存要符合 GDPR 数据最小化原则——个人数据默认 30 天，审计类日志 180 天以上；跨云传输个人数据需确认数据出境机制（SCC 或充分性认定），相关内容可参考本站 GDPR 数据跨境传输系列文章。

六、链路层：OpenTelemetry 统一埋点

链路追踪是定位"跨云调用慢在哪"的关键。用 OTel 的好处：埋点与后端解耦——SDK 只负责生成 trace，导出到哪个后端由 Collector 配置决定。

// otel-collector-config.yaml：一份配置，三后端通吃
receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  awsxray:
    region: ap-southeast-1
  alibabacloud:
    endpoint: http://arms-ap-southeast-1.aliyuncs.com
  jaeger:
    endpoint: jaeger-collector:14250
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [awsxray, alibabacloud, jaeger]

部署 OTel Collector 作为三朵云 K8s 集群内的 DaemonSet，应用只需把 OTLP 端点指向本集群 Collector；未来若调整后端（比如统一迁到自建 Jaeger），只改 Collector 配置，应用零改动。跨云调用链拼接建议统一 trace ID 注入 HTTP Header（traceparent），并在日志中打印 trace ID，故障时一条命令就能把三朵云的日志串起来。

七、告警治理：从告警轰炸到 SLO 驱动

7.1 Alertmanager 统一出口

三朵云的原始告警（CloudWatch Alarm、云监控报警、腾讯云策略告警）全部通过 Webhook 汇入 Alertmanager，由它统一做分组、抑制、静默、路由：

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: ['severity=critical']
      receiver: oncall-p1
      continue: false
    - matchers: ['severity=warning']
      receiver: oncall-p2
    - matchers: ['job=~"cron.*"']
      receiver: batch-jobs
      continue: true
receivers:
  - name: oncall-p1
    webhook_configs:
      - url: https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=XXXX
  - name: oncall-p2
    webhook_configs:
      - url: https://oapi.dingtalk.com/robot/send?access_token=XXXX

关键参数解释：group_wait: 30s 把 30 秒内到达的同类告警合并为一条；repeat_interval: 4h 防止同一告警每 5 分钟刷屏；P1 走企业微信高优群，P2 走钉钉普通群，批量任务告警单独一路。

7.2 SLO 驱动的 burn rate 告警

传统阈值告警（CPU>80% 就报警）是告警轰炸的源头。SLO 告警的思路是：只有"烧 SLO 预算的速度过快"才告警。以 99.9% 可用性、30 天窗口为例：

// 5 分钟窗口 error budget 消耗率 > 14.4（即 30 分钟内烧掉 30 天预算的 2%）
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[5m]))
  /
  sum(rate(http_requests_total{job="api"}[5m]))
)
> (1 - 0.999) * 14.4

这条规则的含义：只有当错误率持续高到"按此速度 2 小时就会烧完本月预算"时才触发 P1。低峰期的偶发抖动不会打扰你，真实故障不会漏报——这是治理告警疲劳最有效的一招。

7.3 告警治理十条军规

1. 区分事件与告警：只有需要人在 15 分钟内响应的才叫告警，其余进事件流（如 Grafana 大盘标注）；
2. 分级 P1-P4：P1 系统不可用、P2 核心功能受损、P3 非核心异常、P4 信息类；
3. 先分组再发送：同类告警 30 秒窗口合并，一次故障一条通知；
4. 告警必须有 runbook：每条告警附处置文档链接，值班人员不用现场发明操作；
5. 自动恢复通知：告警恢复自动发送"已恢复"，否则值班员不敢睡；
6. 静默有期限：维护窗口用 Alertmanager Silence（限时静默），到期自动失效；
7. 每周复盘：统计告警数量 TOP10，根因处理后删除或降级规则；
8. SLO 优先：核心服务用 burn rate 告警，阈值告警只用于容量类指标；
9. 告警预算：每个团队每月告警预算 N 条，超预算的规则必须被评审；
10. 值班轮换：工作日/夜间/周末不同路由，值班表与排班工具（如 PagerDuty）联动。

八、三朵云可观测性能力对比

选型建议：追求"省心"选云托管（阿里云 SLS 与 ARMS 组合成熟度最高）；追求"可控"选开源自建（Prometheus+Thanos+Grafana，三朵云完全一致）；推荐混合——指标开源统一、日志云托管就近采集、链路 OTel 双轨并行。

九、成本参考：自建 vs 托管（新加坡区域，2026-08）

以上为 2026-08 参考价（约数），实际以各官网实时报价为准。

省钱要点：指标数量是最大变量——1 万指标托管 vs 自建，半年差价约 $200-300；日志先算留存再定方案，热数据 30 天 + 归档到对象存储（对象存储价格仅为日志服务存储的 1/10 左右）；CloudWatch 这类纯按量计费的，务必为每个指标/日志组设置预算告警，防止失控。

十、Terraform 一键部署监控栈

监控栈本身也要"基础设施即代码"。以 EKS 为例，用 Terraform 部署 kube-prometheus-stack + Thanos：

// main.tf：部署 Prometheus + Grafana + Alertmanager 全家桶
provider "helm" {
  kubernetes {
    host                   = data.aws_eks_cluster.cluster.endpoint
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
    token                  = data.aws_eks_cluster_auth.cluster.token
  }
}

resource "helm_release" "kube_prometheus_stack" {
  name       = "prometheus"
  repository = "https://prometheus-community.github.io/helm-charts"
  chart      = "kube-prometheus-stack"
  namespace  = "monitoring"

  set {
    name  = "prometheus.prometheusSpec.remoteWrite[0].url"
    value = "https://thanos-receiver.internal:19291/api/v1/receive"
  }
  set {
    name  = "grafana.adminPassword"
    value = var.grafana_admin_password
  }
}

三朵云用同一套 Terraform 模块、不同 provider 即可保持配置一致；监控账号的只读凭证建议用角色联邦（AWS IRSA / 阿里云 RAM Role / 腾讯云角色）下发，避免把 AK/SK 写死在配置里——最小权限 + 定期轮换是底线。

十一、四周边际落地路线图

落地顺序建议：先指标后日志，先大盘后告警，先 SLO 后阈值。告警治理放在第三周是有意的——没有统一大盘和可靠的指标，过早接告警只会把原有的告警轰炸搬到新平台。

总结

出海企业的多云可观测性，核心就一句话：数据平面各云就近采集，控制平面统一收敛。指标走 Prometheus + Thanos + Grafana，日志本地全量 + 关键汇聚，链路 OTel 一次埋点通吃三云，告警由 Alertmanager 单出口 + SLO 驱动。这样建出来的体系，故障定位时间缩短一半以上，告警量下降 70% 不是夸张——关键是别在三朵云里重复造三套轮子。

🚀 企业出海需要云架构咨询？通过 7.chengzicloud.cloud 联系我们，获取专属方案。多云可观测性体系搭建、告警治理、统一监控平台建设均在服务范围内。

相关阅读

• AWS CloudWatch 全方位监控与可观测性实践指南 — AWS 单云监控的深度玩法
• 企业 FinOps 预算与成本治理实战 — 监控成本的分账与预算闭环
• 多云 Landing Zone 账号治理实战 — 监控独立账号与日志集中投递的前提
• Terragrunt + Atlantis 企业级 IaC 管理平台 — 监控栈即代码的规模化实践

本文由 7.chengzicloud.cloud 提供，点击访问首页了解更多