-
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
Add a software limit to limit the amount of EPS that a manager can process #2995
Comments
Some tasks remain pending for qa to carry out its tests:
Also, could you check our template for new Issue? In this template we define a list of items that are necessary and facilitate our work |
Note: This issue is blocked by wazuh/wazuh#13077 |
It is closed because it is being worked on #2947 |
Review data
Testing environment
Tested packages
Status
Conclusion 🟡It proposed two improvements:
It was discussed with the development team and we decided to improve these issues in another PR. |
Tests cases fresh installPrerequisites
Test the new configuration block 🟡EPS functionality disabled 🟢
EPS functionality enabled 🟢
Check without maximum field 🟡
Note: The value by default (0) is set correctly and the EPS limit is disabled. I suggest adding a Warning log to informing to users that EPS limit is disabled because is missing a maximum field. Check without timeframe field 🟢
Note: The value by default is set correctly Check without timeframe and maximum field 🟢
Check with and extra field 🟢
Note: The EPS limit was configured correctly but should we detect an extra field? Check exceeding the maximum limit of maximum 🟡
Note: I suggest modifying this behavior. I think that when we detect a maximum limit is exceeding we can add a Warning log to informing to users that the limit was exceeding and set up the field with the maximum value allowed (100000) Check exceeding the maximum limit of timeframe 🟡
Note: I suggest modifying this behavior. I think that when we detect a maximum limit is exceeding we can add a Warning log to informing to users that the limit was exceeding and set up the field with the maximum value allowed (3600) Check with value outside the lower limit 🟢
Check with invalid values 🟢
Note: The same test was executed for white spaces and negative numbers. For Maximum and timeframe field Check that wazuh-analysisd stops processing events when the limit is reached 🟢
Note: With the configuration set in step 3 the manager should stop processing events when reaching 1500. With the tool, we send 1000 events per second and we can see in Check that wazuh-analysisd starts queuing events when the limit is reached and the corresponding queue is not full 🟢
Note: With the configuration set in step 3 the manager should stop processing events when reaching 1500. With the tool, we send 1600 events and we can see in Check that wazuh-analysisd starts dropping events when the limit is reached and the corresponding queue is full 🟢
Note: With the configuration set in step 3 the manager should stop processing events when reaching 1500. With the tool, we send 1600 events. In the first capture of logs, we can see in Check that wazuh-analysisd processes queued events first instead of new events when the moving average frees up some space 🟢
Check that wazuh-analysisd works as olders versions if the eps is 0 🟢
|
Tests cases upgrade from 4.3.6 to 4.4.0Prerequisites
Test the new configuration block 🟡EPS functionality disabled 🟢
EPS functionality enabled 🟢
Check without maximum field 🟡
Note: The value by default (0) is set correctly and the EPS limit is disabled. I suggest adding a Warning log to informing to users that EPS limit is disabled because is missing a maximum field. Check without timeframe field 🟢
Note: The value by default is set correctly Check without timeframe and maximum field 🟢
Check with and extra field 🟢
Note: The EPS limit was configured correctly but should we detect an extra field? Check exceeding the maximum limit of maximum 🟡
Note: I suggest modifying this behavior. I think that when we detect a maximum limit is exceeding we can add a Warning log to informing to users that the limit was exceeding and set up the field with the maximum value allowed (100000) Check exceeding the maximum limit of timeframe 🟡
Note: I suggest modifying this behavior. I think that when we detect a maximum limit is exceeding we can add a Warning log to informing to users that the limit was exceeding and set up the field with the maximum value allowed (3600) Check with value outside the lower limit 🟢
Check with invalid values 🟢
Note: The same test was executed for white spaces and negative numbers. For Maximum and timeframe field Check that wazuh-analysisd stops processing events when the limit is reached 🟢
Note: With the configuration set in step 3 the manager should stop processing events when reaching 1500. With the tool, we send 1600 events and we can see in Check that wazuh-analysisd starts queuing events when the limit is reached and the corresponding queue is not full 🟢
Note: With the configuration set in step 3 the manager should stop processing events when reaching 1500. With the tool, we send 1600 events and we can see in Check that wazuh-analysisd starts dropping events when the limit is reached and the corresponding queue is full 🟢
Note: With the configuration set in step 3 the manager should stop processing events when reaching 1500. With the tool, we send 1600 events per second. In the first capture of logs, we can see in Check that wazuh-analysisd processes queued events first instead of new events when the moving average frees up some space 🟢
Check that wazuh-analysisd works as olders versions if the eps is 0 🟢
|
🟡 Everything seems to be working properly. Several suggestions have been proposed in wazuh/wazuh#14665 wazuh/wazuh#14666 and will be reviewed in future PRs. |
The issue is reopened because we still need to test the settings using the configuration uploaded through the API. |
Review data
Testing environment
Tested packages
Status
Conclusion 🟡Everything seems to work as expected. However, there are some suggestions:
|
Testing resultsDefault configuration - Configure maximum and timeframe 🟡
# Uploadable Wazuh configuration sections
# upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
# limits:
# eps:
# allow: yes
<global>
<limits>
<eps>
<maximum>100</maximum>
<timeframe>30</timeframe>
</eps>
</limits>
</global> The default configuration has two {
"data":{
"affected_items":[
],
"total_affected_items":0,
"total_failed_items":1,
"failed_items":[
{
"error":{
"code":1113,
"message":"XML syntax error: junk after document element: line 318, column 0",
"remediation":"Please, ensure file content has correct XML"
},
"id":[
"manager"
]
}
]
},
"message":"Could not update configuration",
"error":1
} So for the rest of the tests, this part has been commented out: <!--<ossec_config>
<localfile>
<log_format>audit</log_format>
<location>/var/log/audit/audit.log</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/ossec/logs/active-responses.log</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/messages</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/secure</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/maillog</location>
</localfile>
</ossec_config>-->
{
"data":{
"affected_items":[
"manager"
],
"total_affected_items":1,
"total_failed_items":0,
"failed_items":[
]
},
"message":"Configuration was successfully updated",
"error":0
}
<global>
<limits>
<eps>
<maximum>100</maximum>
<timeframe>30</timeframe>
</eps>
</limits>
</global> Default configuration - Configure maximum 🟢
# Uploadable Wazuh configuration sections
# upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
# limits:
# eps:
# allow: yes <global>
<limits>
<eps>
<maximum>100</maximum>
</eps>
</limits>
</global>
{
"data":{
"affected_items":[
"manager"
],
"total_affected_items":1,
"total_failed_items":0,
"failed_items":[
]
},
"message":"Configuration was successfully updated",
"error":0
}
<global>
<limits>
<eps>
<maximum>100</maximum>
</eps>
</limits>
</global> Default configuration - Configure timeframe 🟢
# Uploadable Wazuh configuration sections
# upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
# limits:
# eps:
# allow: yes <global>
<limits>
<eps>
<timeframe>30</timeframe>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [
"manager"
],
"total_affected_items": 1,
"total_failed_items": 0,
"failed_items": []
},
"message": "Configuration was successfully updated",
"error": 0
}
<global>
<limits>
<eps>
<timeframe>30</timeframe>
</eps>
</limits>
</global> Allow upload configuration (yes) - Configure maximum and timeframe 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: yes <global>
<limits>
<eps>
<maximum>100</maximum>
<timeframe>30</timeframe>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [
"manager"
],
"total_affected_items": 1,
"total_failed_items": 0,
"failed_items": []
},
"message": "Configuration was successfully updated",
"error": 0
}
<global>
<limits>
<eps>
<maximum>100</maximum>
<timeframe>30</timeframe>
</eps>
</limits>
</global> Allow upload configuration (yes) - Configure maximum 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: yes <global>
<limits>
<eps>
<maximum>100</maximum>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [
"manager"
],
"total_affected_items": 1,
"total_failed_items": 0,
"failed_items": []
},
"message": "Configuration was successfully updated",
"error": 0
}
<global>
<limits>
<eps>
<maximum>100</maximum>
</eps>
</limits>
</global> Allow upload configuration (yes) - Configure timeframe 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: yes <global>
<limits>
<eps>
<timeframe>30</timeframe>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [
"manager"
],
"total_affected_items": 1,
"total_failed_items": 0,
"failed_items": []
},
"message": "Configuration was successfully updated",
"error": 0
}
<global>
<limits>
<eps>
<timeframe>30</timeframe>
</eps>
</limits>
</global> Allow upload configuration (true) - Configure maximum and timeframe 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: true <global>
<limits>
<eps>
<maximum>100</maximum>
<timeframe>30</timeframe>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [
"manager"
],
"total_affected_items": 1,
"total_failed_items": 0,
"failed_items": []
},
"message": "Configuration was successfully updated",
"error": 0
}
<global>
<limits>
<eps>
<maximum>100</maximum>
<timeframe>30</timeframe>
</eps>
</limits>
</global> Allow upload configuration (true) - Configure maximum 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: true <global>
<limits>
<eps>
<maximum>100</maximum>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [
"manager"
],
"total_affected_items": 1,
"total_failed_items": 0,
"failed_items": []
},
"message": "Configuration was successfully updated",
"error": 0
}
<global>
<limits>
<eps>
<maximum>100</maximum>
</eps>
</limits>
</global> Allow upload configuration (true) - Configure timeframe 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: true <global>
<limits>
<eps>
<timeframe>30</timeframe>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [
"manager"
],
"total_affected_items": 1,
"total_failed_items": 0,
"failed_items": []
},
"message": "Configuration was successfully updated",
"error": 0
}
<global>
<limits>
<eps>
<timeframe>30</timeframe>
</eps>
</limits>
</global> Do not allow upload configuration (no) - Configure maximum and timeframe 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: no <global>
<limits>
<eps>
<maximum>100</maximum>
<timeframe>30</timeframe>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [],
"total_affected_items": 0,
"total_failed_items": 1,
"failed_items": [
{
"error": {
"code": 1127,
"message": "Forbidden section detected: global > limits > eps",
"remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html"
},
"id": [
"manager"
]
}
]
},
"message": "Could not update configuration",
"error": 1
}
Do not allow upload configuration (no) - Configure maximum 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: no <global>
<limits>
<eps>
<maximum>100</maximum>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [],
"total_affected_items": 0,
"total_failed_items": 1,
"failed_items": [
{
"error": {
"code": 1127,
"message": "Forbidden section detected: global > limits > eps",
"remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html"
},
"id": [
"manager"
]
}
]
},
"message": "Could not update configuration",
"error": 1
}
Do not allow upload configuration (no) - Configure timeframe 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: no <global>
<limits>
<eps>
<timeframe>30</timeframe>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [],
"total_affected_items": 0,
"total_failed_items": 1,
"failed_items": [
{
"error": {
"code": 1127,
"message": "Forbidden section detected: global > limits > eps",
"remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html"
},
"id": [
"manager"
]
}
]
},
"message": "Could not update configuration",
"error": 1
}
Do not allow upload configuration (false) - Configure maximum and timeframe 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: false <global>
<limits>
<eps>
<maximum>100</maximum>
<timeframe>30</timeframe>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [],
"total_affected_items": 0,
"total_failed_items": 1,
"failed_items": [
{
"error": {
"code": 1127,
"message": "Forbidden section detected: global > limits > eps",
"remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html"
},
"id": [
"manager"
]
}
]
},
"message": "Could not update configuration",
"error": 1
}
Do not allow upload configuration (false) - Configure maximum 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: false <global>
<limits>
<eps>
<maximum>100</maximum>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [],
"total_affected_items": 0,
"total_failed_items": 1,
"failed_items": [
{
"error": {
"code": 1127,
"message": "Forbidden section detected: global > limits > eps",
"remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html"
},
"id": [
"manager"
]
}
]
},
"message": "Could not update configuration",
"error": 1
}
Do not allow upload configuration (false) - Configure timeframe 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: false <global>
<limits>
<eps>
<timeframe>30</timeframe>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [],
"total_affected_items": 0,
"total_failed_items": 1,
"failed_items": [
{
"error": {
"code": 1127,
"message": "Forbidden section detected: global > limits > eps",
"remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html"
},
"id": [
"manager"
]
}
]
},
"message": "Could not update configuration",
"error": 1
}
Invalid allow value 🟡If the value is invalid, it will take the default configuration, but we will not receive any warning.
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: ffalse <global>
<limits>
<eps>
<timeframe>30</timeframe>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [
"manager"
],
"total_affected_items": 1,
"total_failed_items": 0,
"failed_items": []
},
"message": "Configuration was successfully updated",
"error": 0
}
<global>
<limits>
<eps>
<timeframe>30</timeframe>
</eps>
</limits>
</global> Repeated allow configuration 🟢If the configuration is repeated, it will take the last one.
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: yes
allow: no <global>
<limits>
<eps>
<timeframe>30</timeframe>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [],
"total_affected_items": 0,
"total_failed_items": 1,
"failed_items": [
{
"error": {
"code": 1127,
"message": "Forbidden section detected: global > limits > eps",
"remediation": "To solve this issue, please enable the section in the API settings: https://documentation.wazuh.com/4.4/user-manual/api/configuration.html"
},
"id": [
"manager"
]
}
]
},
"message": "Could not update configuration",
"error": 1
}
Invalid allow configuration 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
enabled: yes <global>
<limits>
<eps>
<timeframe>30</timeframe>
</eps>
</limits>
</global>
{
"data": {
"affected_items": [],
"total_affected_items": 0,
"total_failed_items": 1,
"failed_items": [
{
"error": {
"code": 1113,
"message": "XML syntax error: 'allow'",
"remediation": "Please, ensure file content has correct XML"
},
"id": [
"manager"
]
}
]
},
"message": "Could not update configuration",
"error": 1
}
|
QA review
This will be discussed with the development team. |
Requested improvements update
This is not related to this development, but it is something we must address. Thus, it should not block this development but a new issue should be opened to investigate it.
This was actually a bug introduced in this development. A fix has been added in wazuh/wazuh@2f789dc. |
Testing after requested changes
ResultsInvalid allow value 🟢
# Uploadable Wazuh configuration sections
upload_configuration:
# remote_commands:
# localfile:
# allow: yes
# exceptions: []
# wodle_command:
# allow: yes
# exceptions: []
limits:
eps:
allow: yyes
Conclusion 🟢Everything seems to work correctly after the added fix. |
QA review update
After discussions with the development team, the following has been decided: (1) If we try to update the configuration with the default This appears to have been introduced in previous developments within (2) No message is displayed when entering a wrong value in the API configuration, taking the default value 🟢 This has been fixed in this development itself. After this fix, it has been tested here and it is now working correctly (3) It is suggested to add a log message for when available credits are consumed. This would be quite useful to let users know that they have to upgrade to a higher plan (cc @TomasTurina @vikman90). ⚫ It has been discussed with the development team and it has been concluded that it can be confusing for the user and that it is not very useful, so it is accepted to discard this idea. (4) It is suggested to add a log message for when the The development team is in agreement with this idea, and will endeavor to implement it in this very development. (5) It is suggested to add WARNING logs when parameters are missing in the block. Reported in this issue (cc @TomasTurina @vikman90). 🟡 The development team is in agreement with this idea, and will endeavor to implement it in this very development. (6) Check if the normal behavior after exceeding the value of It has been discussed with the development team and it has been concluded that this is the designed and expected behavior. We accept the discarding of this idea. We look forward to the implementation of the changes suggested in (3) and (4). |
UpdateTo solve wazuh/wazuh#14665, this warning was added when the
To solve:
This warning was added when
Beside, when it stops dropping events, this information message was added:
These logs can flood the |
Testing after requested changes
Results(4) It is suggested to add a log message for when the wazuh-manager start dropping events because the queue is full. This is quite important to let the user know that they are losing event analysis 🟢This has been resolved by adding the following logs:
This has been tested and verified to work correctly, and the final behavior is as expected. For this, a limit setting of maximum 1000 and timeframe of 30s (30000 events in total every 30s) has been specified. Then, an event simulator has been used, sending a large amount to force queue filling and event dropping. The following video shows how the process was performed and the results obtained. test.mp4(5) It is suggested to add WARNING logs when parameters are missing in the block 🟡
Missing <maximum> 🟡 When starting the
Missing <timeframe> 🟢 In this case the module is started with the default value of
Missing <maximum> and <timeframe> 🟢 In this case, the
Conclusion 🟡When |
Closing conclusion 👍🏼
After talking with the development team, the testing has been approved taking into account the following considerations proposed in the QA review: (1) If we try to update the configuration with the default This appears to have been introduced in previous developments within (2) No message is displayed when entering a wrong value in the API configuration, taking the default value 🟢 This has been fixed in this development itself. After this fix, it has been tested here and it is now working correctly (3) It is suggested to add a log message for when available credits are consumed. This would be quite useful to let users know that they have to upgrade to a higher plan. ⚫ It has been discussed with the development team and it has been concluded that it can be confusing for the user and that it is not very useful, so it is accepted to discard this idea. (4) It is suggested to add a log message for when the Log messages are now displayed for the indicated cases. Added in wazuh/wazuh@87aaf72 (5) It is suggested to add WARNING logs when parameters are missing in the block. Reported in this issue. 🟢 and 🔵 Log messages are now displayed for the indicated cases. Added in wazuh/wazuh@87aaf72, although it has been reported that the log appears multiple times. After discussing this with the development team, it seems that this has been happening before. The following issue has been opened to report it wazuh#15188. (6) Check if the normal behavior after exceeding the value of It has been discussed with the development team and it has been concluded that this is the designed and expected behavior. We accept the discarding of this idea. In addition, all |
Description
In order to validate the changes of the branch https:/wazuh/wazuh/tree/dev-cloud-limits, some manual testing is 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.Tests cases fresh install
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).Check that
wazuh-analysisd
works as olders versions if the eps is 0.Test the new configuration block.
Tests cases upgrade from 4.3.6 to 4.4.0
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).Check that
wazuh-analysisd
works as olders versions if the eps is 0.Test the new configuration block.
Note: This issue is blocked by wazuh/wazuh#13077
The text was updated successfully, but these errors were encountered: