如何通过Elasticsearch集成监控AWS基础设施与工作负载

通用集成操作流程 #

• 创建并配置S3存储桶，用于中转存储待采集的日志数据
• 创建并配置SQS队列，用于接收S3事件通知，支撑日志拉取的触发逻辑
• 安装并配置Filebeat、Metricbeat组件，分别承担日志、指标数据的采集转发职责
• 配置采集规则，从S3存储桶拉取对应日志数据
• 配置采集规则，从Amazon CloudWatch拉取云资源运行监控指标

实操问题解决方案 #

包含Serverless组件的复杂架构下Filebeat、Metricbeat部署位置选择 #

• 禁止将Filebeat、Metricbeat部署在Lambda、临时Fargate任务等Serverless实例上：这类实例生命周期不可控、运行时环境裁剪多，既无法维持SQS消费的长连接状态，还容易因为实例频繁启停导致数据重复采集、断流，额外产生不必要的API调用费用。
• 统一部署在和AWS服务网络打通的常驻计算资源上即可，和架构内是否包含Serverless组件没有直接关联：
  • 小规模架构直接部署在同账号下的固定规格EC2实例上，优先给实例绑定具备对应采集权限的IAM角色，安全性高于直接硬编码AK/SK
  • 容器化架构（EKS/ECS）下，将两个组件部署为专属的常驻工作负载，做固定CPU、内存资源预留，避免和业务容器抢占资源；多实例部署时注意配置SQS消费组参数，避免重复消费数据
  • 混合云场景下也可以部署在和AWS通过专线/VPN打通的本地IDC服务器上，只要网络能稳定连通S3、SQS、CloudWatch的API端点即可
• 架构内的Serverless资源本身不需要部署采集探针：Lambda、Fargate Serverless等服务的日志直接配置规则投递到S3，走统一日志采集链路；资源运行指标直接通过CloudWatch拉取，不需要修改业务代码嵌入采集逻辑。

配置AWS Access Key/Secret Key后连接不生效、监控数据无法采集的排查步骤 #

1. 验证密钥本身可用性
   在部署Beat的节点上安装AWS CLI，通过待验证的AK/SK执行基础测试命令：aws s3 ls验证S3访问权限、aws cloudwatch list-metrics --namespace AWS/EC2验证CloudWatch访问权限，先排除密钥输错、密钥已禁用/过期、账号欠费导致的API调用失败问题。
2. 校验IAM权限匹配度
   确认AK/SK绑定的IAM身份（IAM用户/角色）已配置最小必要权限：S3存储桶的读、列表权限，SQS队列的收消息、删消息、改可见性超时权限，CloudWatch的指标读取、列表权限；同时确认对应资源的ARN配置正确，没有被组织级SCP策略、权限边界拦截。
3. 检查Beat配置位置正确性
   最常见的配置错误是把AWS服务的AK/SK错填到Elasticsearch输出端的认证配置段：AWS相关的认证信息必须填写在Filebeat的S3输入模块、Metricbeat的AWS模块配置段下；同时检查配置文件内的密钥前后是否存在多余空格、特殊字符未转义的问题，所有配置修改后必须重启Beat进程才会生效。
4. 排查网络连通性问题
   确认部署Beat的节点到AWS对应服务端点的443端口连通性正常，没有被安全组、网络ACL、本地防火墙、WAF拦截；如果使用中国区、AWS GovCloud等特殊区域，必须在Beat配置中手动指定对应区域的服务端点，不能使用默认的全球区通用端点，否则会出现签名不匹配、连接超时问题。
5. 开启调试日志定位根因
   如果以上步骤都没有发现问题，给Beat启动参数加上-e -d "*aws*"开启AWS模块的调试日志，直接查看运行时的具体报错信息：常见报错包括签名校验失败、SQS队列不存在、S3路径配置错误、CloudWatch命名空间填错，根据日志里的明确报错定向修复即可。

内容的提问来源于stack exchange，提问作者Nika Khliobas