Ecs健康监控

技能简介

该技能用于监控AWS ECS生产环境的运行状态，结合CloudWatch日志进行深度分析。

业务背景

运维团队需要实时掌握AWS ECS生产环境的健康状态。该技能整合HTTP探测、服务实例比对、ALB目标组检查及SSL证书监控，自动拉取CloudWatch日志并智能归类错误，过滤健康检查噪音，帮助快速定位容器异常和重启事件，降低故障排查时间。

落地案例：某电商平台使用本技能监控其核心交易服务。配置后，系统自动对支付网关域名执行HTTP探测，对比订单服务的期望与实际运行实例数，检查ALB目标组健康状态，同时监控API网关SSL证书有效期。当检测到容器频繁重启时，自动触发日志诊断，从CloudWatch拉取相关日志并按错误类型分类，运维人员可直接查看结构化报告定位根因。

能做什么

• 对指定域名执行HTTP健康探测
• 对比ECS服务的期望实例数与实际运行实例数
• 检查ALB目标组的健康状态
• 监控SSL证书剩余有效期
• 拉取CloudWatch日志并按类型归类错误
• 检测容器重启事件
• 自动过滤健康检查产生的噪音日志
• 根据健康状态自动触发日志诊断

使用说明

安装要求

需预先安装以下工具：

• aws CLI（配置好IAM权限）
• curl
• python3
• openssl（可选，用于SSL检查）

IAM权限需包含：ecs:ListServices、ecs:DescribeServices、elasticloadbalancing:DescribeTargetGroups、elasticloadbalancing:DescribeTargetHealth、logs:FilterLogEvents、logs:DescribeLogGroups。

配置方式

通过环境变量完成配置：

• ECS_CLUSTER（必填）：集群名称
• ECS_REGION：区域，默认us-east-1
• ECS_DOMAIN：待检查的域名，未设置则跳过HTTP/SSL检查
• ECS_SERVICES：逗号分隔的服务名，未设置则自动发现
• ECS_HEALTH_STATE：健康状态JSON文件路径，默认./data/ecs-health.json
• ECS_HEALTH_OUTDIR：输出目录，默认./data/
• ECS_LOG_PATTERN：日志组匹配模式，默认/ecs/{service}
• ECS_HTTP_ENDPOINTS：逗号分隔的name=url格式HTTP探测端点

运行脚本

健康监控脚本：

ECS_CLUSTER=my-cluster ECS_DOMAIN=example.com ./scripts/ecs-health.sh

日志分析脚本：

# 拉取指定服务日志
ECS_CLUSTER=my-cluster ./scripts/cloudwatch-logs.sh pull my-api --minutes 30

# 查看所有服务错误
ECS_CLUSTER=my-cluster ./scripts/cloudwatch-logs.sh errors all --minutes 120

# 深度诊断
ECS_CLUSTER=my-cluster ./scripts/cloudwatch-logs.sh diagnose --minutes 60

# 检测容器重启
ECS_CLUSTER=my-cluster ./scripts/cloudwatch-logs.sh restarts my-api

# 根据健康状态自动诊断
ECS_CLUSTER=my-cluster ./scripts/cloudwatch-logs.sh auto-diagnose

输入与输出

见下方输入与输出表格。

风险提示

• 需要有效的AWS凭证和相应IAM权限，权限不足会导致监控失败
• 频繁调用CloudWatch API可能产生额外费用
• 日志分析依赖正确的日志组命名模式，配置错误将无法获取日志
• 自动诊断功能需要共享目录支持，目录权限不当可能导致状态文件读写失败
• SSL证书检查依赖openssl，未安装时该功能不可用

来源信息

原始链接：https://github.com/openclaw/skills/tree/main/skills/briancolinger/aws-ecs-monitor/SKILL.md
来源类型：GitHub仓库

常见问题

Q1：ECS健康监控 适合哪些场景？
A：适合需要「该技能用于监控AWS ECS生产环境的运行状态，结合CloudWatch」的场景，尤其是希望快速验证并落地的团队与个人。

Q2：第一次使用应该先做什么？
A：先明确目标任务，再按照页面中的“能做什么”和“使用说明”完成最小可行流程。

Q3：如何判断是否值得长期使用？
A：建议连续使用 1-2 周，对比效率、稳定性和协作成本，再决定是否纳入长期工具栈。

替代方案

• 版本发布管理
• 智能自动更新器
• Pulse应用生成

相关推荐

• Perry隔离工作区
• Docker基础
• Bot状态API服务
• 机器人状态API