排查ECS容器日志发送至SQS队列后无法接收消息问题

报错原文：2021-10-06T22:16:30.330Z ERROR [input.s3] s3/collector.go:137 handleSQSMessage failed: json unmarshal sqs message body failed at offset 1 with syntax error: invalid character 'T' looking for beginning of value {"queue_url": "https://sqs.us-east-1.amazonaws.com/721086286010/filebeat-cloudtrail-sqs", "region": "us-east-1"}

该报错核心是Filebeat的S3输入组件尝试将SQS消息体按JSON解析失败，消息体第一个有效字符为'T'，不符合JSON首字符必须为{/[的语法要求，按以下步骤定位：

• 先拉取SQS队列的原始消息验证格式，执行命令：
  aws sqs receive-message --queue-url https://sqs.us-east-1.amazonaws.com/721086286010/filebeat-cloudtrail-sqs --max-number-of-messages 1
  查看返回结果里的Body字段，确认是否为合法JSON结构，是否直接写入了开头带时间标识的纯文本日志。
• 核查ECS侧的日志发送逻辑：如果你的链路是ECS直接发日志到SQS，确认发送端有没有把日志内容封装为JSON结构；如果是ECS日志先写S3、再通过S3事件通知推送到SQS，确认S3事件通知的配置没有自定义修改消息体格式。
• 排查IAM权限与SQS策略：确认ECS实例关联的IAM角色有sqs:SendMessage权限，SQS队列的访问策略允许对应角色写入，排除消息未实际写入队列、报错来自队列中残留的无效测试消息的情况。

• 若为S3事件通知链路：恢复S3事件通知的默认消息格式，Filebeat的S3输入采用默认配置即可，不要额外添加强制JSON解析的参数。
• 若为ECS直写SQS链路：修改ECS侧的发送逻辑，把原始日志封装为合法JSON结构，示例结构如下：
  {"log_content": "原始日志内容", "timestamp": "2021-10-06T22:16:30.330Z", "ecs_instance_id": "实例标识"}
  确保整个消息体为标准JSON格式，首字符为{。
• 快速验证可手动推送一条合法JSON消息到SQS队列，执行命令：
  aws sqs send-message --queue-url https://sqs.us-east-1.amazonaws.com/721086286010/filebeat-cloudtrail-sqs --message-body '{"test_key": "test_value"}'
  如果Filebeat能正常消费该消息，即可确认根因是上游发送的消息格式不符合要求。
• 排查阶段可开启Filebeat的debug日志，启动时添加-d "input.s3"参数，会打印完整的SQS消息体内容，可直接查看错误格式的原始消息。

内容的提问来源于stack exchange，提问作者Evan Gertis