This is a cleanup of concurrency and error handling in the aws-s3 input that could cause several known bugs:

• Memory leaks (1, 2). This issue was caused because the input could run several scans of its s3 bucket simultaneously, which led to the cleanup routine s3Poller.Purge being called many times concurrently. Inefficiencies in this function caused it to accumulate over time, creating many copies of the state data which could overload process memory. Fixed by:
  • Changing the s3Poller run loop to only run one scan at a time, and wait for it to complete before starting the next one.
  • Having each object persist its own state after completing, instead of waiting until the end of a scan and writing an entire bucket worth of metadata at once.
    • This also allowed the removal of other metadata: there is no longer any reason to track the detailed acknowledgment state of each "listing" (page of ~1K events during bucket enumeration), so the states helper object is now much simpler.
• Skipped data due to buggy last-modified calculations (3). The most recent scanned timestamp was calculated incorrectly, causing the input to skip a growing number of events as ingestion progressed.
  • Fixed by removing the bucket-wide last modified check entirely. This feature was already risky, since objects with earlier creation timestamps can appear after ones with later timestamps, so there is always the possibility to miss objects. Since the value was calculated incorrectly and was discarded between runs, we can remove it without breaking compatibility and reimplement it more safely in the future if needed.
• Skipped data because rate limiting is treated as permanent failure (4). The input treats all error types the same, which causes many objects to be skipped for ephemeral errors.
  • Fixed by creating an error, errS3DownloadFailure, that is returned when processing failure is caused by a download error. In this case, the S3 workers will not persist the failure to the states table, so the object will be retried on the next bucket scan. When this happens the worker also sleeps (using an exponential backoff) before trying the next object.
  • Exponential backoff was also added to the bucket scanning loop for page listing errors, so the bucket scan is not restarted needlessly.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Results

Comparison when ingesting a bucket of 1.9 million objects using the configuration (bucket/auth data redacted):

filebeat.inputs:
- type: aws-s3
  number_of_workers: 200

output.elasticsearch:
  allow_older_versions: true
  worker: 10

queue.mem.flush.timeout: 0

Without this PR

After ingesting 218K events in 1:15, ingestion stopped permanently.

With this PR

1.9 million events ingested in 3 hours. Ingestion then continues at a much lower rate as the input begins the next bucket scan, picking up new entries and retrying failures from the last pass.

This ingestion is now output-limited -- the slowdown visible around 11:30 was caused by Elasticsearch-side throttling producing 429 Too Many Requests responses, not by any issue with the input.

Related issues

• Fixes [AWS] S3 input consumes significant amount of memory integrations#9463
• Fixes aws-s3 input writes to Filebeat registry without proper synchronization #39052
• Fixes aws-s3 input skips events and slows ingestion based on object creation timestamp #39065
• Fixes aws-s3 input treats client rate limiting as permanent failure #39114