如何在AWS上实现容器JVM监控及单容器资源使用率告警

是否需要切换到Prometheus/Grafana方案 #

可根据团队运维成本偏好选择，不需要硬切：

• 若团队愿意投入少量资源维护开源监控栈，Prometheus+Grafana是最优选择，刚好匹配当前痛点：Grafana原生支持模板变量，可直接拉取指标中的任务ID维度作为下拉筛选框，弹性扩缩容新产生的任务ID会自动同步到选项中，无需提前配置；同时有大量开箱即用的JVM、Spring Boot、Tomcat、数据源监控面板，可节省大盘搭建成本。
• 若不想完全替换现有链路，也可以保留现有采集到CloudWatch的逻辑，直接用Grafana对接CloudWatch作为数据源，即可实现任务ID筛选能力，改造成本极低。
• 若不想额外维护开源组件，也无需切换：2023年之后CloudWatch控制面板已经上线维度值动态筛选功能，可将任务ID配置为控制面板参数，选项会自动拉取当前时间段内存在的所有任务ID，不需要提前录入，仅交互灵活度略低于Grafana。

容器化Java应用的监控行业通用方案 #

目前行业内主流分为两类方案，按需选择即可：

云原生开源栈 #

适合有一定运维能力、需要高灵活度的团队：

• 采集层：优先用OpenTelemetry Java Agent自动埋点，无需修改业务代码即可覆盖JVM、框架、中间件的全量指标、链路、日志，比Micrometer手动埋点的覆盖度更高
• 存储层：用Prometheus（或云厂商托管版Prometheus，如AWS Managed Service for Prometheus）做指标存储，指标基数大的场景下成本远低于CloudWatch
• 可视化层：用Grafana做统一大盘，支持多数据源聚合，可将应用、ECS集群、负载均衡、数据库等指标整合到同一面板
• 告警层：用Prometheus Alertmanager或Grafana Alerting配置告警，规则灵活度远高于云厂商原生告警

云厂商托管栈 #

适合小团队、不想投入精力维护监控组件的场景：
直接使用云厂商提供的可观测服务，如AWS CloudWatch + X-Ray，优势是免运维，劣势是灵活度低、高基数指标场景下成本偏高。
两类方案都建议保留集群名、服务名、任务/容器ID、可用区作为核心维度，方便问题下钻排查。

ECS容器级别告警支持说明 #

AWS完全支持容器级别的告警，无需局限在服务级别：

• 可直接基于带任务ID维度的指标配置告警规则，你需要的两个触发条件可通过两条规则实现：
  • 按服务名维度聚合，CPU使用率平均值>=60%触发告警
  • 按服务名+任务ID维度聚合，使用MAX()聚合函数，只要任意一个任务的CPU使用率>=80%即触发告警
• 若使用AWS托管Prometheus，还可以通过PromQL配置更复杂的告警规则，比如统计服务下CPU使用率超过80%的容器占比超过20%时触发告警，更适配负载不均衡的场景
• 额外可搭配CloudWatch Contributor Insights规则，实时统计Top N高负载容器，提升负载不均问题的排查效率。

内容的提问来源于stack exchange，提问作者Juan Vega