Wazuh Manager Not Receiving eve.json Events from Agent
Kuna
Hello everyone,
I’m new to Wazuh and need help understanding a behavior I can't resolve. I have a Wazuh agent where a local eve.json file is being generated. My goal is to have this file analyzed by the Wazuh server (manager). However, the server doesn't seem to receive or process anything from it.
Here’s what I’ve done so far:
-
The <localfile> entry with <log_format>json</log_format> is correctly configured in ossec.conf and points to the correct file path on the agent
-
The agent appears as active and connected
-
The agent's ossec.log confirms that the file is being analyzed
-
Debug mode is enabled on the agent, but I still see no logs indicating that any events are being sent to the manager
-
wazuh-logtest successfully decodes manually injected log lines (from eve.json)
From the manager side, I don’t see anything related to this file in the logs, and no alerts or archived events are generated.
Has anyone experienced a case where a monitored JSON file on the agent is being read, but nothing reaches the manager for processing?
Any help or suggestions would be greatly appreciated, thank you!
Md. Nazmur Sakib
Hi Kuna,
It seems to me you are working with Suricata and talking about Suricata eve,json log. I believe you have seen a log like this in the ossec.log of the agent, which indicates the log file is being monitored by the agent and the agent is forwarding logs from this log file.
2025/11/11 05:16:33 wazuh-logcollector: INFO: (1950): Analyzing file: '/var/log/suricata/eve.json'.
On the agent endpoint, can you check if you have alerts in the eve.json file?
tail /var/log/suricata/eve.json
I suspect the JSON logs are not triggering alerts because they are not matching any rules.
Very often, we see that due to misconfiguration in Suricata, it does not generate the expected logs, and as a result, it doesn't generate alerts, as there are mostly information-level logs.
Can you test some log from the eve.json file, which you are expecting to have alerts for?
For this, from the UI, go to
>Server management
>Ruleset Test
And test the logs.
Check if it triggers any alerts with rule level 3 or above.
Ex:
**Phase 3: Completed filtering (rules).
id: '86601'
level: '3'
description: 'Suricata: Alert - GPL ICMP_INFO PING *NIX'
groups: '["ids","suricata"]'
firedtimes: '1'
mail: 'true'
**Alert to be generated.
By default, Wazuh only shows alerts in the Dashboard that have a rule level 3 or above.
If your logs are triggering alerts with level 3 and above in the test and they are not in the dashboard, the issue can be connected with the agent or filebeat / manager for some reason dropping those alerts.
If the logs are not triggering level 3 alerts for you, but you believe your logs should trigger an alert, you need to write custom rules. For this, you can follow these documents
Rules
Rules Syntax
If you are not getting the desired logs in the eve.json file, you should review the Suricata configuration.
You can follow this document to check a use case on Suricata
Network IDS integration
Also, if you are following any specific document to implement your use case, share it with me, and it will be helpful for troubleshooting.
Looking forward to your response on this.
Kuna
Hi again, and thank you for the previous suggestions.
You're right! It seems that all logs in eve.json are below level 3.
However, my concern is not only about alerts. The main issue is that I don’t see any indication in archives.json that Wazuh has processed the file at all, even though decoded messages should appear there regardless of alert level.
To clarify my setup:
I’m analyzing a dataset from CIC-IDS2017, which I converted from PCAP to JSON using the Suricata format.
The resulting eve.json is well-structured and passes validation in the Wazuh Ruleset Test — Wazuh is able to decode these logs.
I’ve also injected test JSON entries manually, for example with "event_type":"dns".
To ensure these logs would generate alerts, I’ve added a custom rule in local_rules.xml (please see the image)
File ownership and permissions are correct (suricata:wazuh, chmod 640), and Wazuh has access.
However, despite all that, nothing ever shows up in /var/ossec/logs/archives/archives.json, not even the test logs that should match this rule.
File ownership and permissions are correctly set to suricata:wazuh with chmod 640, and Wazuh has access to the file.
My understanding is that even if no alert is triggered, Wazuh should still store any properly parsed logs in archives.json.
But currently, it seems like the manager is not receiving or logging anything at all from the monitored file.
Could this be a logcollector issue or a communication problem between the agent and the manager?
Md. Nazmur Sakib
Just to confirm, I believe you have already configured the archive.json (that is disabled by default) by enabling <logall_json> and restarting the manager service.
<ossec_config>
<global>
—--------------
<logall_json>yes</logall_json>
—----------
Now, if you are still not seeing any logs in the archives.json file.
cat /var/ossec/logs/archives/archives.json | grep eve.json
Check if you can see any errors or warnings in the ossec.log
If you see an error like this:
2025/11/12 10:47:10 wazuh-analysisd: ERROR: Too many fields for JSON decoder.
It indicates the problem comes from the JSON log with too many fields.
To solve this, on your Wazuh manager in the internal_options file, you can modify the maximum number of fields in a decoder.
Edit the /var/ossec/etc/internal_options.conf file and modify this entry? ~30 line
# Maximum number of fields in a decoder (order tag) [32..1024]
analysisd.decoder_order_size=256
Change the value to 1024
Remember to restart the manager to apply this configuration.
systemctl restart wazuh-manager
If you want to see more information about this file, you can consult it here:
https://documentation.wazuh.com/current/user-manual/reference/internal-options.html
Let me know the update on the issue.