EventBridge触发SQS推送事件丢失问题的排查与解决咨询

1. 验证EventBridge规则的事件匹配与生成 #

• 先确认事件源是否实际生成了目标事件：比如如果是DynamoDB等服务的事件，直接查看对应服务的事件流/日志，确认插入/更新操作确实产生了事件；如果是自定义事件，检查发送方是否正确将事件推送到EventBridge总线。
• 检查规则的匹配模式是否准确：核对detail-type、source以及detail字段的JSON路径是否正确（比如要写$.detail.type而非detail.type），有没有语法错误。可以用EventBridge的测试事件功能，构造模拟插入/更新事件，验证规则是否能正确匹配触发。
• 查看EventBridge的CloudWatch指标：重点看MatchedEvents（匹配到的事件数）、Invocations（尝试投递的次数）、FailedInvocations（投递失败次数），判断是事件根本没匹配上，还是匹配后投递失败。

2. 检查EventBridge到SQS的交付链路 #

• 确认SQS队列的权限配置：确保队列的访问策略允许EventBridge服务主体（events.amazonaws.com）执行sqs:SendMessage操作，且资源ARN指向当前队列。
• 排查SQS队列的容量与限制：查看CloudWatch的ApproximateNumberOfMessages指标，确认队列是否达到最大消息数限制（默认120000），或者是否有消息积压导致无法接收新事件。
• 检查EventBridge的重试与死信配置：如果配置了死信队列（DLQ），直接查看DLQ中的消息，排查投递失败的具体原因（比如权限不足、队列不存在、消息大小超限等）；未配置DLQ的话，EventBridge会默认重试24小时，可在CloudWatch的FailedInvocations指标中定位失败时段。

3. 排查SQS到Lambda的触发环节 #

• 验证Lambda的触发器配置：确认SQS触发器处于启用状态，批量大小设置合理，且没有添加错误的过滤规则（避免合法事件被过滤）。
• 查看Lambda执行日志：在CloudWatch Logs中检查Lambda的运行日志，确认是否存在收到消息但执行失败的情况，或者是否因为并发限制、超时导致消息未被正确处理。
• 核对SQS的可见性超时：如果Lambda处理消息的时间超过了SQS的可见性超时，消息会重新回到队列，但如果是丢失问题，要排查是否存在Lambda提前调用DeleteMessage但未完成处理的情况。

4. 其他潜在问题排查 #

• 事件大小超限：EventBridge和SQS的单条消息最大限制均为256KB，若插入/更新事件的 payload 超过该大小，会被直接丢弃，需检查事件内容大小。
• 跨账户/跨区域配置问题：确认EventBridge规则、SQS队列、Lambda函数处于同一AWS账户和区域，跨资源配置需要额外的权限和信任关系。
• 时间条件匹配错误：如果规则中使用了时间相关的过滤条件，确认时区设置正确，避免因时间匹配逻辑错误导致事件被过滤。

内容的提问来源于stack exchange，提问作者Sparsh Rawat