-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration tests: Add new eps limit configuration #2947
Comments
Update 2022/08/02To test the EPS limits deployment, it has been used the EPS enable testThis test checks that the following configuration works:
To do this, it checks the message EPS disable testThis test checks that if it is sent EPS invalid value testThis test checks:
|
Update 2022/08/17I order to send message to the manager, it has upgrade the tool Message formatThe format of the message send it to the manager is the following:
This message is formated to have a size of 1Kb. And generate an alert as follow:
|
Description
In order to validate the changes of the branch https:/wazuh/wazuh/tree/dev-cloud-limits, some tests are required.
As part of wazuh/wazuh#12512, a new mechanism has been created to limit the amount of EPS than a manager can process.
This mechanism is implemented within the
wazuh-analysisd
daemon and works by using a circular buffer that tracks the total number of events over a defined period of time.Whenever the circular buffer fills up, the events are held within the related queues until some space is freed. This works like a moving average, this is to support event spikes.
In this first iteration, main configuration will be located in global section from
ossec.conf file
. Link to documentation.Configuration
ossec.conf
Events per second (EPS) limitation is disabled by default.
Logs
EPS functionality disabled:
EPS functionality enabled:
Feature validation
State files could be useful to check if EPS limits are working properly.
Test cases
For the following tests, always use the same type of events (for example,
dbsync
) so that they are directed to the same queue. Also, keep in mind that this mechanism works like a moving average (freeing up some space every second), so the results may not always be exactly the same because they depend on the second the events reach the manager, so it should be better to compare between ranges of expected values instead of exact values.Check that
wazuh-analysisd
stops processing events when the limit is reached. For example, if the eps is 50 and the timeframe is 30, it should stop processing events when reaching 1500 in the last 30 seconds (timeframe) until the moving average frees up some space.Check that
wazuh-analysisd
starts queuing events when the limit is reached and the corresponding queue is not full. For example, if the eps is 50 and the timeframe is 30, it should start queuing events after reaching 1500 in the last 30 seconds (timeframe) and the corresponding queue is not full until the moving average frees up some space.Check that
wazuh-analysisd
starts dropping events when the limit is reached and the corresponding queue is full. For example, if the eps is 50 and the time frame is 30, it should start discarding events when reaching 1500 in the last 30 seconds (timeframe) and the corresponding queue is full until the moving average frees up some space.Check that
wazuh-analysisd
processes queued events first instead of new events when the moving average frees up some space. For example, if the eps is 50 and the time frame is 30, it should start processing queued events after freeing up a slot of the 1500 events from the last 30 seconds (timeframe) instead of new events (which are sent to the end of the queue).Test the new configuration block.
The text was updated successfully, but these errors were encountered: