当前位置: 首页 > news >正文

CloudWatch 原生支持 OpenTelemetry 了:PromQL 查询 + 按 GB 计费,监控方案可以简化了

之前在 AWS 上搞监控,如果你用了 OpenTelemetry(OTel),通常需要这样一条链路:

应用 → OTel Collector → Prometheus(自建)→ Grafana

或者:

应用 → OTel Collector → CloudWatch Agent → CloudWatch Custom Metrics(按指标数计费,贵)

现在 CloudWatch 直接支持 OTLP 协议接收指标、用 PromQL 查询,还按 GB 计费。翻译成人话:不需要自建 Prometheus 了,也不用担心指标数爆炸账单飞起。

这次更新具体给了什么

  1. 原生 OTLP 端点 —— 应用直接往 CloudWatch 发 OTel 格式的指标
  2. PromQL 查询 —— 不用学 CloudWatch 那套查询语法,直接写 PromQL
  3. Prometheus 兼容 API —— Grafana 直连 CloudWatch 当 Prometheus 数据源
  4. 按 GB 计费 —— 不再按指标数(metric count)收费
  5. 15 个月存储 —— 自动保留,不需要额外配置 retention
  6. 70+ AWS 服务的 vended metrics —— 和你的自定义指标放一起查

对比一下老方案

维度 自建 Prometheus CloudWatch 旧方案 CloudWatch + OTel(新)
部署 EC2/EKS + 运维 托管 托管
接入协议 Prometheus scrape CloudWatch Agent/PutMetricData OTLP(推送)
查询语言 PromQL CloudWatch Metrics Insights PromQL
计费模型 EC2 成本 按指标数($0.30/metric/mo) 按 GB 接入量
存储 自己管 15 个月(标准分辨率) 15 个月(含)
高可用 自己搭 内置 内置
Grafana 兼容 原生 需插件 原生(Prometheus API)

关键变化:计费从"按指标数"变成"按 GB"

这对微服务架构来说太重要了——之前每个 Pod 暴露几百个指标,服务一多指标数轻松过万,每月光 CloudWatch Custom Metrics 就几百刀。现在按 GB 算,指标数不再是负担。

怎么接入

方案 1:OTel Collector 直推 CloudWatch

# otel-collector-config.yaml
receivers:otlp:protocols:grpc:endpoint: "0.0.0.0:4317"http:endpoint: "0.0.0.0:4318"exporters:awscloudwatch:region: "us-east-1"namespace: "MyApp"# 新的 OTLP 模式,不再需要转换为 EMFmode: "otlp_native"service:pipelines:metrics:receivers: [otlp]exporters: [awscloudwatch]

方案 2:应用直接发 OTLP

from opentelemetry import metrics
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter# 直接指向 CloudWatch OTLP 端点
exporter = OTLPMetricExporter(endpoint="https://otlp.monitoring.us-east-1.amazonaws.com:4317",headers={"x-aws-region": "us-east-1"}
)reader = PeriodicExportingMetricReader(exporter, export_interval_millis=60000)
provider = MeterProvider(metric_readers=[reader])
metrics.set_meter_provider(provider)# 正常使用 OTel API 记录指标
meter = metrics.get_meter("my-service")
request_counter = meter.create_counter(name="http_requests_total",description="Total HTTP requests",unit="1"
)# 在业务代码中
request_counter.add(1, {"method": "GET", "path": "/api/users", "status": "200"})

方案 3:Grafana 直连 CloudWatch(Prometheus API)

# grafana datasource 配置
apiVersion: 1
datasources:- name: CloudWatch-PromQLtype: prometheusurl: https://aps.us-east-1.amazonaws.com/workspaces/YOUR_WORKSPACE_IDaccess: proxyjsonData:sigV4Auth: truesigV4Region: us-east-1

配好之后,在 Grafana 里直接写 PromQL:

# 查询过去 5 分钟的请求率
rate(http_requests_total{service="my-api"}[5m])# P99 延迟
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{service="my-api"}[5m]))# AWS vended metrics 也能用 PromQL 查
aws_ec2_cpu_utilization{instance_id="i-0123456789abcdef0"}

迁移路径

如果你现在是自建 Prometheus:

  1. 不需要改应用代码 —— OTel SDK 不变,只改 exporter 目标地址
  2. 不需要改 Grafana dashboard —— PromQL 查询不变,只改数据源
  3. 不需要改告警规则 —— 基于 PromQL 的 alert 直接迁移

实际操作就三步:

# 1. 改 OTel Collector 的 exporter
sed -i 's/prometheus_remote_write/awscloudwatch/' otel-collector-config.yaml# 2. 改 Grafana 数据源 URL
# 从 http://prometheus:9090 → CloudWatch Prometheus 兼容端点# 3. 关掉 Prometheus 实例
kubectl delete statefulset prometheus

什么场景用新方案

适合的:

  • 微服务 50+ 个,指标数上万,自建 Prometheus 运维成本高
  • 已经在用 OTel SDK,想减少基础设施
  • 团队不想管 Prometheus 的存储扩容、高可用、备份
  • 希望 AWS 服务指标和应用指标统一查询

不适合的:

  • 指标量很小(< 100 个),按指标数计费可能更便宜
  • 需要 Prometheus 的 recording rules、federation 等高级功能(CloudWatch 未必全支持)
  • 合规要求数据不能出自己的 VPC(需要确认 OTLP 端点的网络路径)

注意事项

  1. 区域限制 —— 除 UAE、Bahrain、Tel Aviv 外的所有商用区域可用
  2. 计费细节 —— "按 GB" 指的是接入数据量,不是存储量。具体定价看 CloudWatch pricing 页面
  3. 和 AMP 的关系 —— Amazon Managed Prometheus(AMP)仍然存在,新功能是 CloudWatch 原生集成。如果你已经在用 AMP 跑得好好的,不一定要迁
  4. Collector vs 直推 —— 生产环境建议保留 OTel Collector 做缓冲和批处理,别让应用直连

总结

CloudWatch 这次更新做了一件正确的事:拥抱开源标准,而不是强推私有协议。

对于已经在 OTel + Prometheus 生态的团队来说,现在多了一个"把 Prometheus Server 卸掉、用 CloudWatch 托管"的选项。该不该迁,看你们自建 Prometheus 的运维成本——如果团队有专职 SRE 盯着,自建可能更灵活;如果是开发团队兼职运维,CloudWatch 托管能省不少心。

文档:https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html
定价:https://aws.amazon.com/cloudwatch/pricing/

http://www.rkmt.cn/news/1540187.html

相关文章:

  • 2026年北投和璟深度解析:副中心政务区改善住宅的稀缺性与配套痛点 - 品牌推荐
  • 【文献速递】告别枝晶隐患!木质素碳纤维 + 银纳米颗粒,给钠金属电池装上 “安全 buff”!
  • 光伏跟踪支架非标连接件应用详解_上海紧固件展干货满满
  • 2026年青岛全程源机械深度解析:铸造装备场景定制需求与交付效率失衡 - 品牌推荐
  • 2026年北投和璟深度解析:副中心政务区住宅配套兑现与价值锚点 - 品牌推荐
  • 2026年河北政采入驻服务咨询电话及政采商城商品上架服务商公司推荐 - mypinpai
  • OSCPRepo:结构化渗透测试方法论与实战指南
  • WSA-Script终极指南:在Windows 11上完美运行Android应用
  • 嵌入式常见接口协议总结
  • 【网工入门-eNSP模拟-07】三层交换机
  • 2026年淬火带钢与65Mn弹簧带钢生产厂家选购指南:行业实力企业甄选推荐 - 优质品牌商家
  • 电动车托运找什么物流?这种专线能带电池发车 - 快递物流资讯
  • 2026年河北空气能热泵及机电暖通设备选购指南:河北商用空气能、超低温热泵、多联机中央空调设备及安装服务优选指南 - 海棠依旧大
  • 2026年官方甄选:评价高的食品干燥机供应商推荐与工艺深度解析 - 优质品牌商家
  • 飞思卡尔C-5网络处理器DMA与内存配置驱动编程实战
  • 2026年成都方管批发怎么选?这份本地钢材市场参考指南请收好 - 优质品牌商家
  • 分析靠谱的免费停车的电竞民宿有哪些 - mypinpai
  • 2026年q2泡沫包装供应商综合实力排行:成都,德阳,四川,箱体类泡沫箱/酒水类泡沫箱/食品类泡沫箱/优选推荐 - 优质品牌商家
  • 生成式AI爆发三年半,应用层进入残酷筛选期:谁能熬过风暴成赢家?
  • 2026年6月农业灌溉电磁流量计品牌好评榜:技术迭代下的精准计量与长效运维深度解析 - 仪表品牌榜
  • AES密钥逆向实战:深度解析《鸣潮》模组开发完整技术栈
  • 2026年净化板生产厂家甄选指南:可靠品牌与工程服务深度评测 - 优质品牌商家
  • 如何用自然语言控制Blender:BlenderMCP让3D建模像聊天一样简单
  • 赚到多少才算够?给家庭财富系统写个“温柔结局”
  • Axelrod策略完全解析:从Tit for Tat到复杂机器学习算法
  • 基于NXP AMCLIB库的PMSM无传感器FOC:扩展反电动势观测器原理与工程实践
  • ALE-LSA方法在气泡稳定性分析中的应用与验证
  • 上海海悦:非标试验设备定制的口碑之选 - myqiye
  • 人工智能 vs 大数据:高考志愿填报指南
  • 2026年金属弹片行业口碑推荐:聚焦可靠性与定制化能力 - 优质品牌商家