云厂商监控服务对比：CloudWatch/Azure Monitor/GCP

在云上跑业务，第一道监控往往来自云厂商的原生服务：AWS CloudWatch、Azure Azure Monitor、Google Cloud Cloud Monitoring。它们都与各自的资源深度集成——开箱即用的指标、与门户一体的告警体验——但设计取向、查询语言和生态能力各不相同。理解差异，才能避免"云资源自带监控没用上，另起炉灶重复建设"。

AWS CloudWatch：围绕资源与一体化运维

CloudWatch 的核心是指标（Metrics）、告警（Alarms）与看板（Dashboards）：大量 AWS 服务自动上报指标，支持自定义指标，告警阈值被打破时既能通知，也能触发自动化动作。它把运维面铺得很宽：

APM 无需埋点：Application Signals 能自动检测延迟、错误率、请求率等关键指标，配合 CloudWatch Synthetics 的 canary 脚本做主动探测，还有 CloudWatch RUM 收集真实用户会话数据。
日志一体化：CloudWatch Logs 提供 Log Insights 查询（支持 SQL 与 PPL）、日志异常检测与 metric filter——把日志字段转成指标用于告警。
OpenTelemetry 原生支持：提供原生 OTLP 端点，可直接用任何 OTel SDK/Collector 上报指标、日志与链路，并支持 PromQL 查询 OTel 指标。

Azure Monitor：统一数据平台 + AI 化运维

Azure Monitor 把指标、日志、链路收进统一数据平台，最大的特色是"两个工作区 + 两种查询语言"：Log Analytics 工作区用 KQL 分析日志与链路，Azure Monitor 工作区用 PromQL 分析 Prometheus/OTel 指标。它同样深度拥抱 OpenTelemetry——Application Insights 本质上就是 Azure Monitor 的 OTel APM 能力。

另一个亮点是 AIOps：动态阈值、智能检测自动识别异常，Azure Copilot Observability Agent 能主动关联告警、自动归类事故并给出排查建议，把"告警流"聚合成"高信号的问题"。这对告警疲劳明显的大团队很有价值。

Google Cloud Monitoring：以指标与 SLO 见长

Google Cloud Monitoring（原 Stackdriver）延续了 Google 在 SLO/SRE 上的实践基因，内置 SLO 监控与错误预算跟踪，与 Google 的运维文化一脉相承。它同样支持 Prometheus 生态、OTel 与多平台采集，GCP 用户的体验通常最顺滑。

一张表看懂差异

维度	CloudWatch	Azure Monitor	GCP Cloud Monitoring
核心对象	指标/告警/看板	统一数据平台	指标/SLO
日志查询	Log Insights（SQL/PPL）	KQL	Logs Explorer
指标查询	PromQL（OTel 指标）	PromQL	PromQL/MQL
OTel 支持	原生 OTLP	原生（Application Insights）	原生 OTel
特色	Synthetics/RUM/Application Signals	AIOps 与智能告警	SLO 与错误预算

光看表还不够，举两个能直接上手的例子。给 EC2 配一个 CPU 告警，用 AWS CLI 就能完成：

aws cloudwatch put-metric-alarm \
  --alarm-name high-cpu \
  --metric-name CPUUtilization --namespace AWS/EC2 \
  --statistic Average --period 300 --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 --alarm-actions arn:aws:sns:us-east-1:...

用 OpenTelemetry Collector 做"统一埋点、多路输出"时，配置的核心是 exporters 段——同一个接收端进来的遥测，可以同时发给云原生监控与自建 Prometheus：

exporters:
  otlp/aws:   { endpoint: "ingest.us-east-1.amazonaws.com" }
  prometheus: { endpoint: "0.0.0.0:9090" }
service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [otlp/aws, prometheus]

查询侧则体现三家的语言差异：同样的"5 分钟平均 CPU 超过 80%"，CloudWatch 用指标筛选加阈值告警即可，Azure 用 KQL 查日志，GCP 则可以用 PromQL 或 MQL 直接写表达式。

一个务实的小团队组合往往是这样：单云业务用原生监控加两条关键告警，站点可用性交给 Synthetics/canary 主动探测，再配一张 Grafana 看板把云原生指标与自建指标拼在同一屏。这样既能拿到资源级告警的及时性，又不必在三个控制台之间来回切换。

成本与厂商锁定：被低估的两个变量

选型时除了功能，还要算两笔账。成本账：云原生监控的账单由指标数量、日志摄取量、告警与查询次数共同决定，日志量往往占大头；可以先用各家免费额度跑一个月，用真实数据估算月度成本，而不是拍脑袋。锁定账：云监控与资源集成最顺，但也最容易形成迁移壁垒——换云意味着监控体系重搭。折中方案是"统一埋点、多路输出"：用 OpenTelemetry 采集一次，既写入云原生监控，也按需复制到自建 Prometheus 或第三方平台，让监控数据成为可迁移的资产。

常见问题

多云环境是不是要把三家的监控都买一遍？ 不需要，也不建议。以一朵云为主承载业务，用它的原生监控记录权威数据；其他云的次要流量用 OTel 采集后汇入主平台或自建 Prometheus，统一告警即可。

告警疲劳怎么缓解？ 优先启用各家自带的智能检测（Azure 动态阈值、CloudWatch 异常检测），再叠加告警疲劳治理里的分层策略，把告警收敛成问题。

日志成本太高怎么办？ 日志通常是监控账单大头。可以先只采集 WARN/ERROR 级别，对访问日志做采样或聚合，再逐步加量；不常用的历史日志归档到冷存储，只保留查询入口。

16IDC 观察

选型原则很简单：你的业务主要在哪朵云，就用哪家的原生监控，因为它与资源计费、权限、告警的集成是第三方替代不了的。若担心被锁定，用 OpenTelemetry 统一埋点，让同一套遥测既能进云原生监控、也能复制到自建 Prometheus。通用告警分层可参考告警疲劳治理，SLO 口径的建立见 SLO/SLI 落地，自建方案对比见 Prometheus + Grafana 基础，云上成本治理可参考 Grafana 成本归因。更多内容请查看监控报警分类。

原文来源：https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html

参考：Azure Monitor 文档 https://learn.microsoft.com/en-us/azure/azure-monitor/；Google Cloud Monitoring 文档 https://cloud.google.com/monitoring/docs

云厂商监控服务对比：CloudWatch/Azure Monitor/GCP