Syscheck real time monitoring issue
Ali Melikov
Hi everyone,
I've noticed an issue with Syscheck real-time file monitoring on one of my Wazuh agents.
Normally, the endpoint detects newly created files in real time without any issues. However, at some point, the real-time monitoring suddenly stops working. When this happens, newly created files are not detected immediately. Instead, they are only reported during the next scheduled Syscheck scan.
For my use case, real-time detection is critical, so this behavior is a problem.
I first noticed this behavior after moving the agent from one Wazuh manager to another. The migration itself completed successfully, and I don't see this problem on any other endpoints. The issue only affects this specific host after it was moved to the new manager.
Has you experienced similar behavior? Is there anything that could cause Syscheck real-time monitoring to stop while scheduled scans continue to work normally?
Any suggestions would be appreciated.
Stuti Gupta
Hi Ali Melikov
Since the issue started after migrating the agent to a new manager, please verify that the monitored directories are still configured with realtime="yes" in the agent's ossec.conf.
Also, check the Wazuh agent logs for any Syscheck-related messages or errors associated with the monitored directories, and share the relevant log entries.
Could you also confirm whether the issue is limited to a specific directory, or does it affect all directories configured for real-time monitoring?
Please share your complete <syscheck> configuration as well.
Finally, please share the name and path of a file that should have generated a real-time alert but was only detected during the scheduled Syscheck scan.
These all are requied to know the cause of the issue you are facing.
Ali Melikov
От: Ali Melikov <alime...@gmail.com>
Дата: пятница, 24 июля 2026 г., 12:08:05 UTC+4
Тема: Syscheck real time monitoring issue
Кому: Wazuh | Mailing List <wa...@googlegroups.com>
Also i noticed this when agent does't move from one manager pr to another. I check files doesn't reach limit. when the endpoint turn off, next day syscheck ignore logging realtime activity.
Stuti Gupta
Was the agent migrated to another manager successfully?
The FIM doesn't reach the limit; that is the good news.
In case it was successfully migrated to a different manager and it is active and reporting the rest of the logs but not the real-time logs, then please share the information asked above.
- Please verify that the monitored directories are still configured with realtime="yes" in the agent's ossec.conf.
- Also, check the Wazuh agent logs for any Syscheck-related messages or errors associated with the monitored directories, and share the relevant log entries.
- Could you also confirm whether the issue is limited to a specific directory, or does it affect all directories configured for real-time monitoring?
- Please share your complete <syscheck> configuration as well.
- Finally, please share the name and path of a file that should have generated a real-time alert but was only detected during the scheduled Syscheck scan.
These all are requied to know the cause of the issue you are facing.
Ali Melikov
<!-- File integrity monitoring -->
<syscheck>
<disabled>no</disabled>
<!-- Frequency that syscheck is executed default every 12 hours -->
<frequency>43200</frequency>
<!-- Default files to be monitored. -->
<directories recursion_level="0" restrict="regedit.exe$|system.ini$|win.ini$">%WINDIR%</directories>
<directories recursion_level="0" restrict="at.exe$|attrib.exe$|cacls.exe$|cmd.exe$|eventcreate.exe$|ftp.exe$|lsass.exe$|net.exe$|net1.exe$|netsh.exe$|reg.exe$|regedt32.exe|regsvr32.exe|runas.exe|sc.exe|schtasks.exe|sethc.exe|subst.exe$">%WINDIR%\SysNative</directories>
<directories recursion_level="0">%WINDIR%\SysNative\drivers\etc</directories>
<directories recursion_level="0" restrict="WMIC.exe$">%WINDIR%\SysNative\wbem</directories>
<directories recursion_level="0" restrict="powershell.exe$">%WINDIR%\SysNative\WindowsPowerShell\v1.0</directories>
<directories recursion_level="0" restrict="winrm.vbs$">%WINDIR%\SysNative</directories>
<!-- 32-bit programs. -->
<directories recursion_level="0" restrict="at.exe$|attrib.exe$|cacls.exe$|cmd.exe$|eventcreate.exe$|ftp.exe$|lsass.exe$|net.exe$|net1.exe$|netsh.exe$|reg.exe$|regedit.exe$|regedt32.exe$|regsvr32.exe$|runas.exe$|sc.exe$|schtasks.exe$|sethc.exe$|subst.exe$">%WINDIR%\System32</directories>
<directories recursion_level="0">%WINDIR%\System32\drivers\etc</directories>
<directories recursion_level="0" restrict="WMIC.exe$">%WINDIR%\System32\wbem</directories>
<directories recursion_level="0" restrict="powershell.exe$">%WINDIR%\System32\WindowsPowerShell\v1.0</directories>
<directories recursion_level="0" restrict="winrm.vbs$">%WINDIR%\System32</directories>
<directories realtime="yes">%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup</directories>
<ignore>%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup\desktop.ini</ignore>
<ignore type="sregex">.log$|.htm$|.jpg$|.png$|.chm$|.pnf$|.evtx$</ignore>
<!-- Windows registry entries to monitor. -->
<windows_registry>HKEY_LOCAL_MACHINE\Software\Classes\batfile</windows_registry>
<windows_registry>HKEY_LOCAL_MACHINE\Software\Classes\cmdfile</windows_registry>
<windows_registry>HKEY_LOCAL_MACHINE\Software\Classes\comfile</windows_registry>
<windows_registry>HKEY_LOCAL_MACHINE\Software\Classes\exefile</windows_registry>
<windows_registry>HKEY_LOCAL_MACHINE\Software\Classes\piffile</windows_registry>
<windows_registry>HKEY_LOCAL_MACHINE\Software\Classes\AllFilesystemObjects</windows_registry>
<windows_registry>HKEY_LOCAL_MACHINE\Software\Classes\Directory</windows_registry>
<windows_registry>HKEY_LOCAL_MACHINE\Software\Classes\Folder</windows_registry>
<windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Classes\Protocols</windows_registry>
<windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Policies</windows_registry>
<windows_registry>HKEY_LOCAL_MACHINE\Security</windows_registry>
<windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer</windows_registry>
<windows_registry>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services</windows_registry>
<windows_registry>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs</windows_registry>
<windows_registry>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg</windows_registry>
<windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run</windows_registry>
<windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce</windows_registry>
<windows_registry>HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx</windows_registry>
<windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\URL</windows_registry>
<windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies</windows_registry>
<windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows</windows_registry>
<windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon</windows_registry>
<windows_registry arch="both">HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components</windows_registry>
<!-- Windows registry entries to ignore. -->
<registry_ignore>HKEY_LOCAL_MACHINE\Security\Policy\Secrets</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\Security\SAM\Domains\Account\Users</registry_ignore>
<registry_ignore type="sregex">\Enum$</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MpsSvc\Parameters\AppCs</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MpsSvc\Parameters\PortKeywords\DHCP</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MpsSvc\Parameters\PortKeywords\IPTLSIn</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MpsSvc\Parameters\PortKeywords\IPTLSOut</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MpsSvc\Parameters\PortKeywords\RPC-EPMap</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MpsSvc\Parameters\PortKeywords\Teredo</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\Parameters\Cache</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ADOVMPPackage\Final</registry_ignore>
<!-- Frequency for ACL checking (seconds) -->
<windows_audit_interval>60</windows_audit_interval>
<!-- Nice value for Syscheck module -->
<process_priority>10</process_priority>
<!-- Maximum output throughput -->
<max_eps>50</max_eps>
<!-- Database synchronization settings -->
<synchronization>
<enabled>yes</enabled>
<interval>5m</interval>
<max_eps>10</max_eps>
</synchronization>
</syscheck>
agent.conf:
<syscheck>
<disabled>no</disabled>
<frequency>43200</frequency>
<directories realtime="yes">D:\*\Desktop</directories>
<directories realtime="yes">D:\*\Documents</directories>
<directories realtime="yes">D:\*\Downloads</directories>
<directories realtime="yes">C:\Users\*\Downloads</directories>
<directories realtime="yes">C:\Windows\System32\drivers\etc\hosts</directories>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Classes\batfile</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Classes\cmdfile</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Classes\piffile</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Classes\AllFilesystemObjects</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Classes\Folder</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg</registry_ignore>
<synchronization>
<enabled>yes</enabled>
<interval>5m</interval>
<max_eps>10</max_eps>
</synchronization>
</syscheck>
Wazuh Notification.
2026 Jul 24 09:01:39
Received From: (Ali) any->syscheck
Rule: 100544 fired (level 16) -> "File added to the system."
Portion of the log(s):
File 'd:\ali\downloads\sample.pdf' added
Mode: scheduled
Attributes:
- Size: 123403
- Permissions: Administrators (allowed): DELETE|READ_CONTROL|WRITE_DAC|WRITE_OWNER|SYNCHRONIZE|READ_DATA|WRITE_DATA|APPEND_DATA|READ_EA|WRITE_EA|EXECUTE|READ_ATTRIBUTES|WRITE_ATTRIBUTES, SYSTEM (allowed): DELETE|READ_CONTROL|WRITE_DAC|WRITE_OWNER|SYNCHRONIZE|READ_DATA|WRITE_DATA|APPEND_DATA|READ_EA|WRITE_EA|EXECUTE|READ_ATTRIBUTES|WRITE_ATTRIBUTES, Authenticated Users (allowed): DELETE|READ_CONTROL|SYNCHRONIZE|READ_DATA|WRITE_DATA|APPEND_DATA|READ_EA|WRITE_EA|EXECUTE|READ_ATTRIBUTES|WRITE_ATTRIBUTES, Users (allowed): READ_CONTROL|SYNCHRONIZE|READ_DATA|READ_EA|EXECUTE|READ_ATTRIBUTES
- Date: Thu Jul 23 16:57:59 2026
- Inode: 0
- User: Ali (S-1-5-21-3624353486-308272220-2052912969-17789)
- MD5: 7b9e0b0e02c5e3b2735c243304a78dbe
- SHA1: 7ea817db30fd67e8a9a24d3ae0fb5932f1d75abf
- SHA256: ae81814295cbf2aa4717fc86b6bc1c39647b51aad1c529d625f2210a6d897d95
- File attributes: ARCHIVE
That log i doesn't receive in real-time. Next day i show this
90% of endpoints works well, but some endpoints doesn't show real-time syscheck logs at current time. For example, last day it logs, but today doesn't have any scheduled and real-time, in fact that wazuh agents are active .
Ali Melikov
It affect all directories configured for real-time monitoring.
NOTE: My other endpoints logs all real-time activities in path which i monitor. I apply ossec and agent.conf to all endpoints
agent.conf:
<!-- File integrity monitoring -->
<syscheck>
<disabled>no</disabled>
<directories realtime="yes">D:\*\Desktop</directories>
<directories realtime="yes">D:\*\Documents</directories>
<directories realtime="yes">D:\*\Downloads</directories>
<directories realtime="yes">C:\Users\*\Downloads</directories>
<directories realtime="yes">C:\Windows\System32\drivers\etc\hosts</directories>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Classes\batfile</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Classes\cmdfile</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Classes\piffile</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Classes\AllFilesystemObjects</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Classes\Folder</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs</registry_ignore>
<registry_ignore>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg</registry_ignore>
<synchronization>
<enabled>yes</enabled>
<interval>5m</interval>
<max_eps>10</max_eps>
</synchronization>
</syscheck>
Stuti Gupta
Create a testfile on " D:\*\Desktop".
Then wait for about 30 seconds and see if rule 100544 fired in "Threat Hunting".
If it does in "Threat Hunting" but not in "FIM," that means the custom rule that you have created, 100544, has a rule group issue, and share that rule with me.
In case the rule doesn't trigger in any of the modules, then please share the logs from the affected agents without restarting the agent. Located at:
C:\Program Files (x86)\ossec-agent\logs\2026\Jul
Also share the version of the manager and agent for testing purposes (if required).
Additionally, check if the configuration that you have in agent.conf is reflected in the "C:\Program Files (x86)\ossec-agent\shared\merged.mg" file on the affected agent.
Ali Melikov
Wazuh manager version agent version is 4.14.3 , manager version is 4.14.3
Some days real-time monitoring works normally.
Other days it completely stops, and only scheduled scans detect file changes.
Here is ossec.log. And ossec-27.log located in C:\Program Files (x86)\ossec-agent\logs\2026\Jul
ossec.log
2026/07/28 08:52:00 wazuh-agent: INFO: Starting new log after rotation.
2026/07/28 08:52:04 wazuh-agent: INFO: Trying to connect to server ([wazuh_receiver.local]:1514/tcp).
2026/07/28 08:52:04 wazuh-agent: INFO: (4102): Connected to the server ([wazuh_receiver.local]:1514/tcp).
2026/07/28 08:52:04 wazuh-agent: INFO: Server responded. Releasing lock.
2026/07/28 08:52:06 wazuh-agent: INFO: Agent is now online. Process unlocked, continuing...
2026/07/28 08:52:06 rootcheck: INFO: Ending rootcheck scan.
2026/07/28 08:52:07 wazuh-agent: INFO: Agent is now online. Process unlocked, continuing...
2026/07/28 08:52:07 wazuh-agent: INFO: Agent is now online. Process unlocked, continuing...
2026/07/28 08:52:43 sca: INFO: Evaluation finished for policy 'C:\Program Files (x86)\ossec-agent\ruleset\sca\cis_win11_enterprise.yml'
2026/07/28 08:52:43 sca: INFO: Security Configuration Assessment scan finished. Duration: 53 seconds.
2026/07/28 08:57:45 wazuh-agent: INFO: (6009): File integrity monitoring scan ended.
2026/07/28 08:58:42 wazuh-modulesd:syscollector: INFO: Starting evaluation.
2026/07/28 08:59:43 wazuh-modulesd:syscollector: INFO: Evaluation finished.
2026/07/28 09:59:45 wazuh-modulesd:syscollector: INFO: Starting evaluation.
2026/07/28 10:00:33 wazuh-modulesd:syscollector: INFO: Evaluation finished.
ossec-27.log
...
2026/07/27 17:08:17 wazuh-modulesd:syscollector: INFO: Module started.
2026/07/27 17:08:17 wazuh-modulesd:syscollector: INFO: Starting evaluation.
2026/07/27 17:08:17 wazuh-agent: INFO: (6000): Starting daemon...
2026/07/27 17:08:17 wazuh-agent: INFO: (6010): File integrity monitoring scan frequency: 43200 seconds
2026/07/27 17:08:17 wazuh-agent: INFO: (6008): File integrity monitoring scan started.
2026/07/27 17:08:17 wazuh-agent: INFO: Trying to connect to server ([wazuh_receiver.local]:1514/tcp).
2026/07/27 17:08:17 wazuh-agent: INFO: Started (pid: 33888).
2026/07/27 17:08:17 wazuh-agent: INFO: (4102): Connected to the server ([wazuh_receiver.local]:1514/local).
2026/07/27 17:08:21 wazuh-modulesd:syscollector: INFO: Evaluation finished.
2026/07/27 17:08:22 wazuh-agent: INFO: Agent is now online. Process unlocked, continuing...
2026/07/27 17:08:22 wazuh-agent: INFO: Agent is now online. Process unlocked, continuing...
2026/07/27 17:08:22 rootcheck: INFO: Starting rootcheck scan.
2026/07/27 17:08:27 rootcheck: INFO: Ending rootcheck scan.
2026/07/27 17:12:51 wazuh-agent: INFO: (6009): File integrity monitoring scan ended.
2026/07/27 17:12:51 wazuh-agent: INFO: FIM sync module started.
2026/07/27 17:12:52 wazuh-agent: INFO: (6012): Real-time file integrity monitoring started.
Above logs are the normal logs, when my real-time activity works
Below logs is problematic logs
2026/07/28 08:51:49 sca: INFO: Starting Security Configuration Assessment scan.
2026/07/28 08:51:49 wazuh-agent: INFO: (6008): File integrity monitoring scan started.
2026/07/28 08:51:50 wazuh-agent: WARNING: Server unavailable. Setting lock.
2026/07/28 08:51:50 rootcheck: INFO: Starting rootcheck scan.
2026/07/28 08:51:50 wazuh-agent: INFO: Closing connection to server ([wazuh_receiver.local]:1514/tcp).
2026/07/28 08:51:51 sca: INFO: Starting evaluation of policy: 'C:\Program Files (x86)\ossec-agent\ruleset\sca\cis_win11_enterprise.yml'
2026/07/28 08:51:51 wazuh-agent: WARNING: Process locked due to agent is offline. Waiting for connection...
2026/07/28 08:51:51 wazuh-agent: WARNING: Process locked due to agent is offline. Waiting for connection...
2026/07/28 08:51:54 wazuh-agent: INFO: Could not resolve hostname 'wazuh_receiver.local'
2026/07/28 08:51:56 wazuh-agent: WARNING: Process locked due to agent is offline. Waiting for connection...
2026/07/28 08:52:00 wazuh-agent: INFO: Running daily rotation of log files.
I want to mention that i get all logs from agent, but syscheck doesn't
Stuti Gupta
Hi
Ali
Please share all the logs in a single text file once you have finished your testing. This will help us determine exactly what error is occurring and when. Please include only the logs from the day when the issue occurred, especially the agent logs.
Based on the logs you've shared so far, the agent may be intermittently losing its connection to the manager, which could explain why FIM alerts are not always generated in real time.
I also noticed the following message:
wazuh-agent: INFO: Could not resolve hostname 'wazuh_receiver.local'
Could you please make sure that the Wazuh agent's hostname is unique and does not match an already enrolled agent? Also, verify that wazuh_receiver.local resolves correctly from the affected endpoint.
Stuti Gupta
So the real-time issue you are seeing is a side effect of this connection instability, not a syscheck configuration problem.
Now we need to find out why the manager is repeatedly disconnecting from this one agent. Can you confirm if this same disconnect pattern is happening on any other agents, or is it limited to just this one endpoint?
This will clarify if this is agent-specific or a broader manager-side issue.
For now, please share the manager-side logs :
cat /var/ossec/logs/ossec.log | grep <agent_name or agent_id>
along with checking the agent connectivity, using https://documentation.wazuh.com/current/user-manual/agent/agent-management/agent-connection.html
Let me know if there is any error or issue. If nothing shows up there, we may need to escalate this for further investigation.
Additionally, please try to share every detail here in the Google Group discussion so it will be easier to track.
Ali Melikov
This behavior is not limited to a single agent. For your information, I have hundreds of agents, and only 8-9 of them encounter this issue, which affects only Syscheck. Event logs are not lost on these agents; only Syscheck real-time monitoring stops working correctly.
Most endpoints remain in sleep mode during non-working hours. This disconnect/reconnect pattern occurs on almost all agents, and when they reconnect, both real-time monitoring and scheduled activities normally resume.
90% of the endpoints are running agent version 4.14.2, while the manager is running 4.14.3.
I noticed that when I restart an agent experiencing this issue, the previously missed files immediately appear in the FIM Monitoring tab, with the correct Last Analysis (when the file appears in the tab) and Last Modified (when the file was actually created in the monitored directory) timestamps.
After the restart, some affected endpoints begin generating real-time Syscheck events again, while others do not. On some endpoints, even the scheduled Syscheck scan appears to stop working. The behavior is inconsistent across the affected agents.
Could this be a known bug or a compatibility issue between agent version 4.14.2 and manager version 4.14.3?
Stuti Gupta
I'm not aware of any known issue that matches this behavior. Also, the combination of Wazuh agent 4.14.2 and Wazuh manager 4.14.3 is supported, so I wouldn't expect this to be a compatibility issue. Compatibility issues are generally expected only when the agent version is newer than the manager version.
I have a few questions to better understand the issue.
Are all 8–9 affected agents running the same operating system? You mentioned Windows earlier. If all of them are Windows agents, it may point to a Windows-specific issue. If the affected agents use different operating systems, we can rule that out.In your first message, you mentioned moving the agent to a new manager. Could you explain what changes were made? For example:
- Did you update the manager IP or hostname in the agent configuration?
- Did you register the agent with a different manager?
- Or was there another change?
Are all 8–9 affected agents connected to the same manager, or are they connected to different managers?
Since the Windows Event Logs are still being collected, it looks like the issue may be specific to the Syscheck module rather than the manager connection. To confirm this, could you also share the manager log for one of the affected agents?
Please collect the logs for the same time period as the agent logs you shared earlier.
This information will help us determine whether the issue is on the agent side or related to the manager.
Ali Melikov
When I say the agent was moved to another manager, I mean that the agent automatically selected a different manager. When the agent starts, it chooses one of the cluster nodes to connect to. I also confirmed that the agents without this syscheck issue go through the same process and communicate correctly.
I tried commands such as grep <agent_name_or_agent_id> /var/ossec/logs/ossec.log, but there was no output related to the affected agent.
I would like to enable debug logging in another affected agents next. Hopefully, the additional logs will help us identify the root cause of the issue.
Stuti Gupta
Since the agent can reconnect to different cluster nodes and other agents continue to work correctly after the same failover, it does not appear that the failover itself is causing the issue.
I also noticed that there are no entries for the affected agent in the manager's ossec.log. Could you confirm whether the affected agent is shown as Active in the Dashboard while the issue is occurring? Also, does the manager continue to receive other events (for example, Windows Event Logs) from the same agent, or do only the Syscheck events stop?
In a cluster, each node has its own local ossec.log. If the agent connected to a different node than the one you grepped, you'd get no output even though the agent is communicating fine. Can you confirm which specific node this agent is currently connected to, and run the grep on that node specifically?
Try grepping by the agent's IP address as well as its name and ID, sometimes the manager log references the connection by IP rather than the agent name.
Since you plan to enable debug logging, could you collect debug logs from one affected endpoint?
On the affected endpoint, open:
Add the following line at the end of the file:
Save the file and restart the Wazuh agent. Once the issue occurs again, please share the ossec.log from the affected endpoint along with any manager logs for the same time period.
Ali Melikov
Stuti Gupta
In the debug logs, I have seen this issue :
Unable to add directory to real-time monitoring
It is mostly related to Unicode or wildcards, and the issue was resolved in an earlier Wazuh discussion.
Let me look into this internally and get back to you.
Ali Melikov
Olamilekan Abdullateef Ajani
I looked through the thread, and based on the latest debug message: Unable to add directory to real-time monitoring
I think the focus should be on the agent-side FIM real-time configuration, not the manager connection.
There are a few things we can look at.
First, this entry should be changed: <directories realtime="yes">C:\Windows\System32\drivers\etc\hosts</directories>
hosts is a file, but the realtime monitoring works on directories, not individual files. Monitor the parent directory instead, and lets see:
<directories realtime="yes" recursion_level="0">C:\Windows\System32\drivers\etc\</directories>
Based on the documentation, realtime works with directories, not individual files.
Second, please delete and retype that line manually in agent.conf. In the pasted config, there may be an invisible Unicode character before C:\Windows..., and that can make the path fail even though it looks correct. Your agent.conf also has several wildcard realtime paths under D:\*\Desktop, D:\*\Documents, D:\*\Downloads, and C:\Users\*\Downloads.
Third, reduce those wildcard recursions for testing only.
For example:
<directories realtime="yes" recursion_level="3">D:\*\Desktop\</directories>
<directories realtime="yes" recursion_level="3">D:\*\Documents\</directories>
<directories realtime="yes" recursion_level="3">D:\*\Downloads\</directories>
<directories realtime="yes" recursion_level="3">C:\Users\*\Downloads\</directories>
Also check whether D:\ is a local disk or a mapped/network drive. From version 4.13, Windows FIM does not support UNC paths or mapped network drives.
Please run this on one affected endpoint:
wmic logicaldisk get name,drivetype,providername
net use
If D: shows as DriveType 4, it is a network drive and the FIM will not monitor it properly.
Finally, enable debug on one affected endpoint and compare it with one healthy endpoint:
C:\Program Files (x86)\ossec-agent\local_internal_options.conf with:
syscheck.debug=2
windows.debug=2
Restart the agent, reproduce the issue, then check:
Select-String -Path "C:\Program Files (x86)\ossec-agent\ossec.log" -Pattern "Unable to add directory|Maximum size permitted|real-time|realtime"
If the affected endpoint shows many "unable to add directory" messages, then the issue is with realtime watch registration, most likely path/wildcard/limit related.
So please follow the steps above and let me know. Once we have those logs, it should be much clearer the next steps if this is configuration-related or something that needs escalation as a Windows FIM realtime bug.
I await feedback from you.