S3通知偶发失效问题的调试方法咨询

1. 启用CloudTrail数据事件排查操作触发情况 #

CloudTrail*支持记录s3:ObjectCreated:这类对象级操作，只是默认仅开启管理事件，需要手动配置数据事件：

• 针对目标存储桶开启s3:ObjectCreated:*数据事件记录，指定日志存储到另一个S3桶。
• 对比成功触发通知和未触发的操作日志，重点看：
  • 对象键是否严格匹配前缀DP/event-triggering-export-data-test/和后缀.json.gpg（S3前缀后缀区分大小写，且为精确字符串匹配）；
  • 操作类型是否属于s3:ObjectCreated范畴（比如PutObject、CopyObject、MultipartUploadComplete等，s3:ObjectCreated:*会覆盖所有子事件）；
  • 是否存在对象覆盖场景（覆盖已有对象也应触发通知，可通过日志中的overwrite字段确认）。

2. 验证S3通知规则的匹配逻辑 #

• 确认上传的对象键完全符合规则：比如必须是DP/event-triggering-export-data-test/[文件名].json.gpg，不能多/少字符（比如DP/event-triggering-export-data-test/sub/xxx.json.gpg是匹配前缀的，但如果前缀没加末尾斜杠则可能不匹配）；
• 后缀匹配要求对象键严格以.json.gpg结尾，如果上传的是.json.gpg.tmp这类临时文件，不会触发通知。

3. 排查SQS端接收问题 #

• 检查SQS权限策略：确保S3有权限向该队列发送消息，策略示例如下：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "s3.amazonaws.com"
        },
        "Action": "sqs:SendMessage",
        "Resource": "arn:aws:sqs:[区域]:[账号ID]:[队列名称]",
        "Condition": {
          "ArnLike": {
            "aws:SourceArn": "arn:aws:s3:::[你的存储桶名称]"
          }
        }
      }
    ]
  }
  

• 查看SQS死信队列：如果消息发送失败被转入死信队列，可从中获取失败原因（比如权限不足、队列容量超限）；
• 确认SQS的可见性超时和消息保留期：避免消息被其他消费者提前获取或过期未被查看。

4. 查看S3通知交付状态 #

在S3控制台的存储桶「事件通知」页面，找到对应的规则，查看交付状态（Delivery Status）：

• 这里会展示最近的交付成功/失败记录，以及具体错误码（如AccessDenied、QueueDoesNotExist），偶发失败的情况通常能在这里找到线索。

5. 测试特殊场景 #

• 测试不同上传方式：分别用单文件PutObject和分片上传（MultipartUpload），看是否存在某类操作无法触发通知；
• 检查对象键的特殊字符：如果键包含空格、非ASCII字符，确认通知规则的前缀后缀配置是否正确（无需转义，直接匹配原字符即可）。

6. 排查AWS服务端异常 #

• 查看AWS服务健康仪表板，确认问题发生时段S3和SQS所在区域是否有服务中断或性能波动；
• 重复执行相同上传操作，验证是否为临时网络延迟或服务抖动导致的偶发失效。

内容的提问来源于stack exchange，提问作者Lesha Pipiev