With elastic/beats#40699 the max_number_of_messages setting is now ignored for SQS inputs as of 8.15. It is still exposed in integration settings. It is still relevant for <8.15.
The new setting is number_of_workers, which the SQS-based input shares with the S3 bucket polling input in integration settings.
Unfortunately, the default value for number_of_workers is just 1. Users using an SQS-based S3 input upgrading to 8.15 agents will find that they've gone from having five workers (or whatever number they had customized it to) for processing objects to just a single worker processing objects.
We should consider one or more of the following:
- Using the
max_number_of_messages setting for the number_of_workers value if queue_url is present to maintain backwards compatibility while indicating that the setting will be removed in a future version.
- Indicating that
max_number_of_messages is no longer applicable for 8.15 and to use number_of_workers when using an SQS queue
- Bumping the
number_of_workers default value to 5
With elastic/beats#40699 the max_number_of_messages setting is now ignored for SQS inputs as of 8.15. It is still exposed in integration settings. It is still relevant for <8.15.
The new setting is number_of_workers, which the SQS-based input shares with the S3 bucket polling input in integration settings.
Unfortunately, the default value for number_of_workers is just
1. Users using an SQS-based S3 input upgrading to 8.15 agents will find that they've gone from having five workers (or whatever number they had customized it to) for processing objects to just a single worker processing objects.We should consider one or more of the following:
max_number_of_messagessetting for thenumber_of_workersvalue ifqueue_urlis present to maintain backwards compatibility while indicating that the setting will be removed in a future version.max_number_of_messagesis no longer applicable for 8.15 and to usenumber_of_workerswhen using an SQS queuenumber_of_workersdefault value to 5