使用 Amazon Managed Service for Prometheus 进行容器监控 - EKS 指标的收集与分析
以兼容 Prometheus 的方式收集 EKS/ECS 的指标，并使用 PromQL 进行查询。本文介绍通过与 Managed Grafana 集成构建容器监控平台的方法。
Managed Prometheus 概述
Managed Service for Prometheus 是兼容 Prometheus 的托管监控服务。Prometheus 服务器的预置、扩展、存储管理和高可用性配置均已自动化，因此可以专注于指标的收集和查询。通过 Prometheus 的远程写入（remote write）API 发送指标，并使用 PromQL 执行查询。可以将现有的 Prometheus 导出器、Grafana 仪表板和告警规则直接迁移过来。
与 EKS 的集成
从 EKS 集群收集指标时，将 ADOT（AWS Distro for OpenTelemetry）收集器部署为 DaemonSet 是标准的模式。ADOT 收集器从各节点的 kubelet、cAdvisor 和 kube-state-metrics 抓取指标。随后将这些指标发送到 Managed Prometheus 的远程写入端点。通过 IRSA（IAM Roles for Service Accounts）为 ADOT 收集器授予写入 Managed Prometheus 的权限。使用 Prometheus Operator 时，保持 ServiceMonitor 与 PodMonitor 的设置不变。只需将远程写入目标改为 Managed Prometheus，即可完成迁移。在 ADOT 收集器与 Managed Prometheus 的配置之外，Datadog 已经与 Kubernetes 和 AWS 两者完成集成，因此可以直接监控 EKS。截至 2026 年 10 月，在集群中安装 Datadog Agent 推荐使用 Datadog Operator，也可以通过 Helm chart 安装。Pod 和 Deployment 等 Kubernetes 资源的状态可以在 Kubernetes Explorer 中查看。此外，Datadog 关于在 Kubernetes 上安装的官方文档中建议使 Cluster Agent 与 Agent 的版本保持一致。
PromQL 与告警
使用 PromQL 查询收集到的指标，并使用 Managed Grafana 构建仪表板。除了 CPU 使用率、内存使用率、Pod 重启次数、请求延迟等标准的 Kubernetes 指标外，还可以收集 / 可视化应用程序特有的自定义指标。可以在告警管理器中定义基于 PromQL 的告警规则，并将通知发送到 SNS 主题。由于指标会保留 150 天，因此也可以将其用于长期的容量规划和趋势分析。
Managed Prometheus 的费用
Managed Prometheus 的费用由指标的摄取量、存储和查询构成。摄取方面，每月最初的 20 亿个样本按每 1,000 万个样本约 0.90 美元计费（截至 2026 年 8 月）。存储为每 GB 每月约 0.03 美元，保留 150 天。查询根据处理的样本数计费，每 1,000 万个样本约 0.10 美元。与自托管的 Prometheus 服务器相比，由于不再需要 EC2 实例的运维成本和存储管理的工作，在中等规模及以上的环境中，托管服务的总成本呈现更低的趋势。
从 ECS 和自管理集群收集
指标的发送来源并不限于 EKS。在 ECS 中，将 ADOT 收集器作为边车容器加入任务，抓取并发送应用程序公开的 Prometheus 格式的指标。对于在 EC2 上自行管理的 Prometheus，也仅需将远程写入的目标指向 Managed Prometheus 的端点，就可以迁移。即使是在本地或其他环境中运行的工作负载，如果支持远程写入，也可以将 Managed Prometheus 用作汇集目标。这样可以将分散在多个环境中的指标整合到一处进行跨环境监控。
与 Managed Grafana 的联动
在可视化方面，与 Managed Grafana 组合使用是常见的做法。创建 Managed Grafana 的工作区并将 Managed Prometheus 注册为数据源后，可以直接显示用 PromQL 编写的面板。认证与 IAM Identity Center 或 SAML 联动，通过组织的单点登录来控制访问。现有的 Grafana 仪表板仅需导入 JSON 定义就可以迁移，可以降低工具的学习成本。让 Grafana 端的告警与 Prometheus 端的告警规则分担职责，并加以整理以免通知重复，运维就会趋于稳定。
告警与记录规则的设计
告警在 Managed Prometheus 内置的告警管理器中定义。通过 PromQL 的条件表达式设置阈值，并经由 SNS 通知已触发的告警。对于频繁评估的重型查询，事先通过记录规则将聚合结果保存为单独的指标，仪表板和告警的评估速度就会提高。告警以基于症状进行设计为基本原则。与 CPU 使用率本身相比，将延迟恶化、错误率上升等与用户影响直接相关的指标作为监控目标，会得到噪声少的实用通知。
多账户与成本优化
在大规模环境中，按环境或团队划分工作区，会使权限和成本的边界变得清晰。在跨账户汇集指标时，让发送端代入 IAM 角色，并写入中央工作区。由于摄取量按样本数成比例计费，不发送不需要的指标，以及在设计上避免标签的基数（值的组合数）膨胀，是成本管理的最大要点。高基数的标签会使摄取量急剧增加，因此将收集范围缩小到必要的部分。
总结
Managed Prometheus 是兼容 Prometheus 的托管监控服务，最适合收集容器工作负载的指标。通过 ADOT 收集器从 EKS 自动收集指标，使用 PromQL 查询，并使用 Managed Grafana 可视化，这是标准的集成模式。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。