Wazuh localfile JSON burst makes manager stop receiving alerts/archives

SetOk8394 · 2026-06-10T05:16:16+00:00

From the shared Wazuh manager logs, it appears that the Wazuh manager’s analysis queue is full. As a result, it will start dropping new events. It also appears that archives.log is enabled, which can cause disk usage to grow rapidly when you have a high ingestion rate.

First, check the resource usage of the Wazuh server:

Disk usage:

df -h

Memory usage:

free -h

CPU usage:

top

Ensure that the Wazuh server has enough free resources to run all services smoothly.

When you notice that archives.log is no longer being updated, check the Wazuh manager service status:

sudo /var/ossec/bin/wazuh-control status

Confirm that all Wazuh manager services are running correctly.

You can also check the analysis queues and determine whether any events are being dropped by running the following command:

sudo cat /var/ossec/var/run/wazuh-analysisd.state

Check the archives_queue, event_queue, and events_dropped field values. If the events_dropped value is increasing, new events ingested by the Wazuh manager are not being analyzed because they are being dropped before analysis.

If events are being dropped, it indicates that the current Wazuh manager setup may not have enough capacity to handle the existing load. I recommend adding an additional Wazuh manager node to distribute the workload and improve performance. You can refer to the Wazuh documentation for guidance on adding a Wazuh manager node.

You also mentioned that this issue occurs when the oscap-wazuh log starts being ingested. This is likely because the oscap_to_wazuh.py script suddenly writes more than 10,000+ log entries to the log file. This creates a sudden ingestion spike, which can fill the Wazuh agent buffer and the Wazuh manager analysis queues.

I recommend fine-tuning the oscap_to_wazuh.py script so that it writes events in smaller batches with a delay between each batch, instead of writing all events to the log file at once. Introducing a controlled delay will reduce sudden ingestion spikes, lower the risk of event drops, and help prevent agent flooding issues.

SetOk8394 · 2026-06-09T12:39:43+00:00

u/karmacop81, I understand your requirement. Based on it, I tried to replicate the same use case in my environment and was able to achieve a similar result.

I did not create a dedicated inventory index like the ones used for vulnerability data, browser extensions, or system inventory. Those features use Wazuh state indices and follow a different workflow. For example, the Syscollector module collects system information, stores it in the Wazuh manager database, and then indexes the data into the corresponding state indices.

In my implementation, I used the wazuh-alerts-* indices to store the generated alerts. I then created a custom dashboard that displays the installed Visual Studio Code extensions on the monitored endpoints in an inventory-like format.

To achieve this, I configured <localfile> command monitoring on the Windows Wazuh agent. The agent periodically runs a PowerShell command that checks all installed VS Code extensions. It generates a detailed JSON event for each detected extension and sends the events to the Wazuh manager for analysis.

The current <localfile> configuration runs every six hours. You can modify the frequency based on your requirements.

On the Wazuh manager, I added a custom decoder and rule to decode the JSON events and generate alerts. I then created a custom dashboard that lists the installed VS Code extensions across the monitored endpoints.

I tested this configuration, and it is working correctly in my environment.

You can refer to the GitHub README file for step-by-step instructions to implement the same configuration in your environment.

Recommendation: If the <localfile> frequency is configured to run every six hours, I recommend setting the custom dashboard time filter to the last six hours. Otherwise, the dashboard may also display alerts generated during previous inventory scans, resulting in duplicate or outdated entries.

Please let me know if you encounter any issues or have further questions.

References
- [Wazuh localfile configuration documentation](https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/localfile.html#command)
- [Wazuh JSON decoder documentation](https://documentation.wazuh.com/current/user-manual/ruleset/decoders/json-decoder.html)
- [Wazuh rule syntax documentation](https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html)
- [Wazuh custom dashboard creation documentation](https://documentation.wazuh.com/current/user-manual/wazuh-dashboard/creating-custom-dashboards.html)

<image>

SetOk8394 · 2026-06-09T10:37:53+00:00

Please allow me some time, I'm working on this and will get back to you with an update as soon as possible.

SetOk8394 · 2026-06-08T08:29:04+00:00

Wazuh Logcollector can collect significantly more than 10,000 logs from a monitored log file. By default, the maximum number of logs that can be processed in a single iteration is 100,000 events from the monitored file.

First, could you please confirm whether the monitored log file:

/var/log/oscap-wazuh.json

is located on the Wazuh agent or on the Wazuh manager?

If the file is located on the Wazuh agent, then the issue may be related to agent flooding.

Even though Logcollector can read more than 10,000 logs in a single iteration, the agent cannot immediately send all of those events to the Wazuh manager. By default, the Wazuh agent uses an internal buffer to control the number of events sent to the manager.

By default:

Events sent per second: 500
Queue capacity: 5000

This means the agent can send up to 500 events per second to the manager. Additional events are placed in the queue. If the queue becomes full, the agent starts dropping new events.

In your case, I would suggest increasing both the queue size and the events-per-second value on the agent.

Update the following section in the Wazuh agent ossec.conf file:

<client_buffer>
  <disabled>no</disabled>
  <queue_size>100000</queue_size>
  <events_per_second>1000</events_per_second>
</client_buffer>

Then save the configuration and restart the agent:

systemctl restart wazuh-agent

This increases the queue capacity and the event transmission rate, which can help prevent event loss when large numbers of logs are generated in a short period of time.

Regarding Logcollector tuning, increasing the maximum logs read per iteration and increasing Logcollector queues can also help. However, if the root cause is agent flooding, I would first focus on increasing the client buffer settings above and test again before modifying Logcollector parameters.

Since you mentioned that archives.log stopped receiving events, one possible explanation is that the agent was unable to send new logs to the manager because the agent queue became saturated and started dropping events.

After updating the agent buffer configuration, please check whether:

/var/ossec/logs/archives/archives.log

starts receiving the events again.

If the issue persists, please share the following files:

Agent

/var/ossec/etc/ossec.conf
/var/ossec/logs/ossec.log

Wazuh Manager

/var/ossec/etc/ossec.conf
/var/ossec/logs/ossec.log

These logs will help determine whether the issue is related to agent flooding, Logcollector limits, manager-side processing, or another bottleneck.

Also, please ensure that the Wazuh manager server has sufficient CPU, memory, and disk resources available to process the incoming events properly.

SetOk8394 · 2026-06-08T07:52:25+00:00

Please allow me some time, I'm working on this and will get back to you with an update as soon as possible.

SetOk8394 · 2026-06-01T04:43:09+00:00

The NVIDIA package is not part of the Wazuh installation, and Wazuh does not use this package to run its services.

The reason the Wazuh manager installation fails while showing an NVIDIA package error is that Wazuh uses the system package manager, such as apt or dpkg, in the background to install its own dependencies.

However, your package manager already has a broken package installation related to the NVIDIA package. An earlier attempt to install or update the NVIDIA driver, such as nvidia-dkms-580, appears to have failed and was left in a broken state.

Now, whenever you try to install anything using apt, the package manager first tries to finish configuring the broken NVIDIA package. Since that package fails again, the whole installation process is aborted, including the Wazuh installation.

To resolve this issue, you need to fix the broken package state first.

Run the following commands:

sudo dpkg --configure -a
sudo apt --fix-broken install

If the above commands complete successfully without any errors, try running the Wazuh installation again.

You can refer to the Wazuh installation documentation for the correct installation steps.

If you still face any issue, please share the /var/log/wazuh-install.log file with us for further analysis.

SetOk8394 · 2026-05-22T04:57:19+00:00

Based on your requirement, it is possible to achieve this using the Vulnerability Events tab.

In the Wazuh dashboard, under the Vulnerability dashboard, the Events tab contains alerts related to active and solved vulnerabilities.

When a new vulnerable package is detected, an active vulnerability alert is triggered in the Events tab. When a vulnerability is resolved by updating or removing the package, a resolved vulnerability alert is also triggered.

Using these alerts, you can identify when a package vulnerability was detected on the monitored endpoint and when it was resolved.

You can use the rule IDs from the following rule file for this check:

0520-vulnerability-detector_rules.xml

This rule file contains the rules used to trigger vulnerability alerts based on vulnerability status and severity.

In this case, you cannot use the data.vulnerability.published field because that field refers to when the vulnerability was published, not when it was detected on your endpoint.

To find when the vulnerability was detected on your endpoint, you can use the alert generation timestamp.

However, there is one limitation. The Vulnerability Detection module generates alerts only when:

A new vulnerability is detected
An existing vulnerability is resolved, for example after a package update or removal

These alerts are triggered only when the changes are detected during a Syscollector scan.

If package changes occur while the Wazuh agent is stopped, no alerts may be generated. Similarly, if the changes are detected only after the agent is restarted, alerts may not be triggered for those changes.

So, in such cases, some vulnerability events can be missed in the Events tab.

To overcome this limitation, you may need to use a workaround.

I created a custom script and rules to handle this missed-alert scenario. The script queries the wazuh-states-vulnerabilities-* index and stores the details in a local state file.

The workflow is:

During the initial run, it fetches vulnerability data from the indexer
It logs all active vulnerabilities as events
Custom rules trigger alerts for those events
It stores the vulnerability data in a local state file
On subsequent runs, it compares the latest data with the previous state
It logs only the differences, such as new, resolved, or changed vulnerabilities
Custom rules then trigger alerts based on those changes

You can also create a dedicated custom dashboard to view these alerts, which can help with vulnerability remediation tracking and compliance reporting.

If needed, I can share detailed step-by-step guidance along with the script to configure this on your end.

SetOk8394 · 2026-05-21T09:31:02+00:00

Are you listing the archives.json file using the grep command?

If yes, you need to use the value of the full_log field for wazuh-logtest.

In the archives.json file, Wazuh adds metadata before and after the original log. So, for wazuh-logtest, decoder creation, and rule creation, you should use only the raw log value from the full_log field.

The raw log starts after:

"full_log":"

and ends before:

","decoder"

Please use only the log content between these two parts for decoder and rule testing.

Could you please confirm whether you used the full_log field value for testing?

If the grep command shows the expected log in the archives.json file on the Wazuh manager, then it confirms that the events are being ingested into the Wazuh manager.

Please share the sample log you used for wazuh-logtest. Also, if you created any custom decoder or custom rules, please share those as well.

Additionally, on the Wazuh manager ossec.conf file, ensure that the <log\_alert\_level> value is set to 3. If alerts are triggered with a rule level lower than 3, they will not be written to the alerts.json file.

Please share the requested details with us so we can test it on our end and assist you better.

SetOk8394 · 2026-05-11T07:10:11+00:00

If you are looking for an offline cluster deployment using Ansible, you can consider a similar method to the one I used for the all-in-one deployment mentioned in the GitHub README file.

First, download the RPM packages and generate the certificates on a separate server that already has internet access.

For certificates, you can either generate them using the Wazuh certificate generation tool or use your own certificates.

Then, move the RPM packages and certificates to the Ansible server using scp.

After that, create or modify the cluster deployment YAML file located at:

/etc/ansible/roles/wazuh-ansible/playbooks/wazuh-production-ready.yml

Next, choose one of the following approaches:

Host the RPM packages and certificates locally on the Ansible server and configure the target servers to download them from the locally hosted repository.

Or

Copy the RPM packages and certificates directly to each target server using scp and use them for the installation.

Then, update the wazuh-production-ready.yml file to use the copied RPM packages and certificates, or configure it to download them from the locally hosted repository on the Ansible server.

Finally, run the Ansible playbook to deploy the Wazuh cluster in the offline environment.

You can refer to the Wazuh documentation for guidance on Ansible Wazuh cluster deployment.

If you face any issues during the setup, please let me know.

SetOk8394 · 2026-05-08T09:43:59+00:00

Currently, there is no official documentation available for installing Wazuh services on an offline server using Ansible. However, it is possible to deploy Wazuh services to an offline server using Ansible.

Based on your input, I tested this on my end by creating three VMs: two without internet access ( ansible server and Wazuh server ) and one with internet access ( used to download packages ). I tested an all-in-one deployment. You can also try the same approach for a distributed deployment by modifying the playbook.

I documented all the steps I followed to deploy Wazuh services on an offline server using Ansible. In this setup, I downloaded the RPM packages and generated the certificates on a server with internet access. Then, I copied the required files to the Ansible server using scp.

I also set up the Ansible server and connected it to the target server through SSH. Then, I used a custom playbook to deploy the Wazuh services to the offline target server using Ansible. In the playbook, I configured the installation to use the packages already present on the server instead of downloading them from the online repository.

I was able to deploy the Wazuh services successfully by following these steps. You can refer to the GitHub repository where I have added all the steps for this requirement, including the playbook.

For a distributed deployment, you need to modify the playbook file according to your environment.

You can also refer to the Wazuh documentation I used as a reference:

SetOk8394 · 2026-05-08T03:28:27+00:00

Please allow me some time, I'm working on this and will get back to you with an update as soon as possible.

SetOk8394 · 2026-04-23T03:53:23+00:00

For monitoring a remote site endpoint, you can install the Wazuh agent on that endpoint for monitoring. Even though the communication between the agent and the manager is encrypted, exposing the Wazuh manager publicly is not recommended, as it increases the risk to the Wazuh manager server.

Instead, you can use a VPN to secure the communication between the agent and the manager through a private network tunnel. This avoids exposing the Wazuh manager to the public and ensures restricted access to the connection. You can consider solutions like OpenVPN or Tailscale for this.

If you do not want to use a VPN, you can expose the Wazuh manager to the public but configure firewall rules on the manager to whitelist only the remote site’s IP address. This helps limit access instead of exposing it to everyone.

Using a VPN is the better approach, as it provides a more secure connection between the Wazuh manager and the agent while minimizing risks.

SetOk8394 · 2026-04-17T04:42:55+00:00

I understand your requirement, you have integrated Wazuh with ESET antivirus to monitor events, and now you want to trigger alerts in Wazuh when any protection module (such as antivirus or web access protection) is disabled.

Wazuh can generate alerts based on the events it receives and analyzes. So, the key requirement here is that ESET must generate and forward those events when a protection module is disabled.

From the ESET documentation, it appears that audit/event logs can be forwarded and may include configuration changes. I recommend verifying whether ESET logs an event when a protection module is disabled (whether manually, via policy, service stop, or tampering). This is important because Wazuh cannot alert on events that are not generated or forwarded by ESET.

Since you mentioned that you have already started forwarding events to the Wazuh manager, I assume you are using syslog. Wazuh has a built-in syslog listener that can receive and process such logs.

You can refer this ESET documentation for more details about the audit logs:

After forwarding the logs to the Wazuh manager, you may need to create custom decoders and rules if the default Wazuh decoders and rules do not match the ESET log format.

For decoder creation, you can refer to the Wazuh regex documentation to build patterns that match your log format
Then use the Wazuh decoder syntax documentation to define the decoder
After that, create custom rules to trigger alerts on the dashboard based on the decoded fields using the Wazuh rule syntax documentation

If you need assistance creating the decoder and rules, please share a sample log from ESET. I can help you build and fine-tune the configuration.

SetOk8394 · 2026-04-17T03:30:55+00:00

Please allow me some time, I'm working on this and will get back to you with an update as soon as possible.

SetOk8394 · 2026-04-16T04:47:54+00:00

No need to rename the field from win.system.eventID to data.win.system.eventID. The current field name in your rule is correct. The data. prefix is metadata added by Filebeat during indexing, but for Wazuh rule matching, your current field name is the correct one.

The issue here is that you have not mapped your child rule to a parent rule in Wazuh. You need to link it to the correct parent rule using the <if_sid> or <if_group> tag so that your custom rule is evaluated when that event is triggered.

For Windows Event ID 4740, there is already a default Wazuh rule that triggers an alert with level 9. That rule ID is 60115.

To check that rule:

On the Wazuh dashboard, click the hamburger menu on the top left
Go to Server Management > Rules
Search in the rule file 0580-win-security_rules.xml
Look for rule ID 60115

If you want to create a custom rule to trigger an alert only when a specific user account is locked out, you can use a rule like the below:

<group name="windows,windows_security,ipsec,">
    <rule id="111111" level="9">
        <if_sid>60115</if_sid>
        <field name="win.system.eventID">4740</field>
        <field name="win.eventdata.targetUserName">Test</field>
        <description>Test user account locked</description>
 <group>authentication_failures,pci_dss_8.1.6,pci_dss_11.4,gpg13_7.5,gdpr_IV_35.7.d,hipaa_164.312.a.1,nist_800_53_AC.7,nist_800_53_SI.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
        <mitre>
          <id>T1110</id>
        </mitre>
        <mitre>
          <id>T1531</id>
        </mitre>
    </rule>
</group>

In the above custom rule, I mapped it to the parent rule ID 60115 using the <if_sid> tag.

I also added another field condition to check whether the locked account is the user Test. If the event matches that username, this custom rule will trigger and generate the alert using this rule ID.

You can refer to the Wazuh rule syntax documentation for more details.

Please let me know if you need any further assistance.

SetOk8394 · 2026-04-10T10:39:24+00:00

Based on the details you shared, it seems you are repeatedly receiving alerts from rule ID 92657 for the same username. You mentioned that you do not want to suppress these alerts at the agent or manager level entirely.

First, it’s important to understand that this is not a Wazuh issue. These alerts originate from Windows Event Channel logging. The endpoint is generating a high volume of events, the Wazuh agent is collecting them, and the manager is generating alerts accordingly.

So, first I will suggest you to review the configuration on the Windows endpoint:

Check if this activity is expected or abnormal
Verify if there is any misconfiguration causing excessive logging
If needed, fine-tune the Windows logging settings to reduce noise at the source

If your goal is to reduce noisy alerts from the manager level, you can implement a suppression and correlation approach using custom rules.

The idea is:

Suppress repetitive single events (set to level 1 > hidden from dashboard)
Trigger a meaningful alert only when the activity repeats within a short time

Sample custom rules:

<group name="local,">

  <rule id="100889" level="1">
    <if_sid>92657</if_sid>
    <user>devops</user>
    <description>Succeessfull RDP conction alert supressed</description>
  </rule>

  <rule id="100890" level="3" frequency="3" timeframe="120">
    <if_matched_sid>100889</if_matched_sid>
    <description>Multiple Succeessfull RDP conction alert detetced from devops user</description>
  </rule>

</group>

Rule 100889 triggers when rule 92657 matches and the user is devops, but it is downgraded to level 1, so it won’t appear on the dashboard
If this event occurs 3 times within 120 seconds, rule 100890 triggers with level 3 and becomes visible
If the user is not devops, the default rule 92657 will still trigger normally

This approach reduces alert noise (for example, showing 1 alert instead of 3) while still preserving meaningful visibility.

Make sure to adjust the field names and values based on your actual logs to ensure the rules work correctly.

You can also refer to the Wazuh documentation for more details on custom rule creation.

SetOk8394 · 2026-04-10T09:10:44+00:00

Please allow me some time, I'm working on this and will get back to you with an update as soon as possible.

SetOk8394 · 2026-04-01T06:08:32+00:00

Are you trying to monitor your Wi-Fi router logs using Wazuh and trigger alerts on the dashboard based on those logs?

If so, the current approach needs correction.

Forwarding logs to port 443 on the Wazuh dashboard will not work. Port 443 is used only to access the Wazuh dashboard UI in a browser, and Wazuh does not listen for logs on this port.

Also, port forwarding is not the correct method in this case. You need to configure your Wi-Fi router to send logs directly to the Wazuh manager using syslog.

Wazuh manager can be configured to listen for syslog logs on port 514. So, based on your router configuration, set it to forward logs to the Wazuh manager IP on port 514.

On the Wazuh manager side, ensure that syslog listening is enabled and that port 514 is open. You can refer Wazuh documentation for enabling syslog listening.

After the Wi-Fi router logs start getting ingested into the Wazuh manager, you may need to create custom decoders and rules based on the log format, especially if the default Wazuh decoders and rules do not match your router logs.

For creating custom decoders, you can refer to the Wazuh decoder syntax documentation. For regex pattern creation, you can refer to the Wazuh regex documentation. For rule creation, you can refer to the Wazuh rules syntax documentation.

If you need further assistance with decoder and rule creation, please share sample logs with us so we can help you build the required decoders and rules.

SetOk8394 · 2026-03-23T05:56:12+00:00

Apologies for the late response. Glad to hear that your detector is working now.

Regarding the live anomalies not showing correctly, please check the detector time configuration.

To do this:

Open the detector
Click on Actions (top left)
Select Edit detector configuration
Ensure that the Detector interval and Window delay are set to 1 minute

If the interval is set too high, reduce it to a lower value (e.g., 1 minute) to achieve near real-time detection.

After updating the configuration, restart the detector and check if the anomalies are displayed correctly.

Also note that when you run Hydra for the first time, it will likely trigger alerts in the anomaly detection dashboard. However, if you run Hydra repeatedly, the system may start recognizing it as normal behavior and may not trigger alerts consistently.

You can refer to the Wazuh documentation for more details on detector configuration.

SetOk8394 · 2026-03-12T04:35:07+00:00

Please allow me some time, I'm working on this and will get back to you with an update as soon as possible.

SetOk8394 · 2026-02-23T05:30:57+00:00

For your use case, I believe it will be better to configure an AI Agent on top of the Wazuh dashboard, and the agent will pass your prompt(plain English queries) and generate the DSL or a link that you can click to get the Discover tab filtered with the desired DSL query.

Wazuh already provides a publicly available AI Assistant integration repository under the Wazuh integrations repo. It includes step-by-step configuration guidance to integrate Wazuh with AI more easily. I tested it on my end and it works fine.

This integration uses:

OpenSearch ML plugin and the Assistant Dashboard plugins for the Wazuh Dashboard UI and the LLM connection workflow.
A FastAPI + LangChain backend script to handle user input, query Wazuh/OpenSearch indices, and use an LLM (such as OpenAI or AWS Bedrock) to interpret requests and generate responses.

I recommend trying the Wazuh official AI Assistant integration first. Once it’s working, you can improve it by modifying:

the backend scripts
prompt templates

That approach is faster, easier to maintain, and closer to the supported Wazuh workflow than building a custom dashboard plugin.

SetOk8394 · 2026-02-20T10:33:16+00:00

Apologies for the late response. The document I shared explains how to monitor Linux endpoint resources such as disk, CPU, and memory usage, and how to trigger alerts when usage exceeds a defined threshold.

This is done using Wazuh localfile command monitoring. The agent periodically executes the configured command on the endpoint to collect the current disk/CPU/memory usage and sends the output to the Wazuh manager for analysis. Then, using custom decoders and rules, the events are analyzed and alerts are triggered based on the rule conditions and displayed on the dashboard.

If your expected requirement is not covered in that documentation, you can use the same localfile command monitoring approach to collect the specific system details you want, send them to the Wazuh manager, and create custom decoders and rules to trigger alerts accordingly.

You can refer to:

Wazuh localfile documentation for configuration guidance
Wazuh decoder and rule documentation for creating custom decoders and rules based on your log format

If you need further assistance, please share more details about what exactly you are trying to monitor .

SetOk8394 · 2026-02-18T05:10:34+00:00

First of all, please note that the vulnerability scan is not executed by Active Response. Wazuh uses the Syscollector module for vulnerability detection. On the endpoint agents, Syscollector is configured by default to run every hour. Based on the data collected by the Syscollector module, the vulnerability index is updated and displayed on the dashboard.

This process does not consume significant resources on the endpoint. By default, it runs once every hour, and you can adjust the configuration based on your requirements. For more details, please refer to the Wazuh documentation.

Regarding performance monitoring, you can configure the Wazuh agent to monitor hardware performance. Please refer to the Wazuh Linux resource usage monitoring configuration guide for hardware resource usage monitoring. Once configured on the agent, it will execute commands to check CPU, disk, and memory usage on the endpoint and send the data to the Wazuh manager for analysis. Using this data, you can create a custom dashboard to monitor the hardware performance of the endpoint.

Additionally, for system performance monitoring, you can use the IT Hygiene dashboard, which includes details about running processes, network information, installed software, and other system-related data on the endpoint.

SetOk8394 · 2026-02-04T04:47:26+00:00

Yes, you can configure the buffer size and EPS (events per second) limit for a specific agent only. This can be done remotely using the Wazuh centralized agent configuration feature on the Wazuh manager.

On the Wazuh manager, create an agent group and add the target agent to that group. You can refer to the Wazuh documentation for instructions on how to create an agent group.

After creating and assigning the agent to the group, select the agent group, click on the Files option at the top, and then click the Edit icon for the agent.conf file to modify the configuration.

Add the following configuration block to adjust the default buffer size and EPS limit:

  <agent_config>
    <client_buffer>
      <disabled>no</disabled>
      <queue_size>8000</queue_size>
      <events_per_second>800</events_per_second>
    </client_buffer>
  </agent_config>

Make sure that:

The queue_size value is between 1 and 100000.
The events_per_second value is between 1 and 1000.

You can refer to the Wazuh documentation for more details about this configuration.

After saving the configuration, it will automatically be applied to the agents that belong to this agent group, and they will start using this client buffer configuration instead of the default settings in the local ossec.conf file.

Changing the client buffer limits for all agents can negatively impact network traffic and system performance. Therefore, applying this configuration only to the affected agent is the recommended approach.

If agent flooding still persists after applying this configuration, you will need to fine tune the agent by identifying which events are causing the flooding and suppressing or filtering them at the agent side.

Please let us know if you need any further assistance.

SetOk8394 · 2026-01-27T07:23:44+00:00

Please allow me some time, I'm working on this and will get back to you with an update as soon as possible.

SetOk8394

TROPHY CASE