Hi Le Sok,
I hope you are doing well. Thank you for using Wazuh.
If some of your agents disconnect it is mostly because of the network connectivity issue or authentication issue. You can find the related logs on your agent’s side.
cat /var/ossec/logs/ossec.log | grep -i -E "error|warn"
There can be many reasons for agents to disconnect from the Wazuh manager.
The most common is the network issue.
Check the status of your agent if is active and running.
Linux: systemctl status wazuh-agent
Windows: open the Wazuh agent app and check the status.
Test if your agent can communicate with the manager.
On Linux and macOS systems (with netcat installed), open a terminal and run the following command:
nc -zv <MANAGER_IP> 1514 1515 55000
If there is connectivity, the output should be a connection success message
On Windows, open a PowerShell terminal and run the following command:
(new-object Net.Sockets.TcpClient).Connect("<MANAGER_IP>", 1514)
(new-object Net.Sockets.TcpClient).Connect("<MANAGER_IP>", 1515)
(new-object Net.Sockets.TcpClient).Connect("<MANAGER_IP>", 55000)
If there is connectivity, there is no output, otherwise, an error is shown.
If you see a connection error check if those IP and ports are allowed in the firewall.
Go to the ossec.conf file and check if your agent has the right manager address inside the client block. vi /var/ossec/etc/ossec.conf
<address>Manager's_IP</address>
Ex:
<client>
<server>
<address>192.168.44.134</address>
<port>1514</port>
<protocol>tcp</protocol>
</server>
……………….
</client>
Check if there is any error log in the agent’s ossec.log and manager’s ossec.log
For Linux-based systems, the log file is located at /var/ossec/logs/ossec.log
Share the output of this command from both the agent and the manager.
cat /var/ossec/logs/ossec.log | grep -i -E "error|warn"
For Windows endpoints, the location of the log file is dependent on its architecture:
For a 64-bit endpoint, it is located at C:\Program Files (x86)\ossec-agent\ossec.log
For a 32-bit endpoint, it is located at C:\Program Files\ossec-agent\ossec.logs
For a macOS endpoint, the log file is located at /Library/Ossec/logs/ossec.log
Make sure to restart the agent after making changes.
Please let me know the update on your issue. Also if you still face the issue, please share the above findings so that I can guide you further.
Regards
Md. Nazmur Sakib
--
You received this message because you are subscribed to the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/40273c8c-d078-47ef-8c31-e7ebd7a8d815n%40googlegroups.com.
Hi Le Sok,
If the problem is occurring because of a network issue you can not make any changes to the agent from your manager as the agent is not connected with your manager now. You need to check the status of your agent. You can follow the below steps to resolve the issue.
Test if your agent can communicate with the manager.
On Linux and macOS systems (with netcat installed), open a terminal and run the following command:
nc -zv <MANAGER_IP> 1514 1515 55000
If there is connectivity, the output should be a connection success message
On Windows, open a PowerShell terminal and run the following command:
(new-object Net.Sockets.TcpClient).Connect("<MANAGER_IP>", 1514)
(new-object Net.Sockets.TcpClient).Connect("<MANAGER_IP>", 1515)
(new-object Net.Sockets.TcpClient).Connect("<MANAGER_IP>", 55000)
If there is connectivity, there is no output, otherwise, an error is shown.
If you see a connection error check if those IP and ports are allowed in the firewall.
Go to the ossec.conf file and check if your agent has the right manager address inside the client block. vi /var/ossec/etc/ossec.conf
<address>Manager's_IP</address>
Ex:
<client>
<server>
<address>192.168.44.134</address>
<port>1514</port>
<protocol>tcp</protocol>
</server>
……………….
</client>
Check if there is any error log in the agent’s ossec.log.
For Linux-based systems, the log file is located at /var/ossec/logs/ossec.log
cat /var/ossec/logs/ossec.log | grep -i -E "error|warn"
For Windows endpoints, the location of the log file is dependent on its architecture:
For a 64-bit endpoint, it is located at C:\Program Files (x86)\ossec-agent\ossec.log
For a 32-bit endpoint, it is located at C:\Program Files\ossec-agent\ossec.logs
For a macOS endpoint, the log file is located at /Library/Ossec/logs/ossec.log
I hope this helps. Let me know If you need any further information or assistance
Regards
Md, Nazmur Sakib
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/ae92dcb1-bb58-44b7-9005-60b65bac3fd9n%40googlegroups.com.
Hi Le Sok,
Hope you are doing well. Thank you for using Wazuh.
To find logs related to why your agent got disconnected check the ossec.log of the agent.
cat /var/ossec/logs/ossec.log | grep -i -E "error|warn"
Now, about the logs of your endpoint that were not sent during the agent were disconnected.
Wazuh agent does not store the endpoint’s logs from its end. It simply collects and forwards the log to the Wazuh manager. While an agent is disconnected, it will stop monitoring the log files configured to monitor, and therefore, it should only lose the logs that were being sent at the same moment that the communication got interrupted, independently of the buffer. The time that the agent can verify its disconnection and stop monitoring files will be much shorter when using the TCP protocol, and therefore, the lost logs would be decreased.
All the new logs ingested into the log file while the agent is disconnected should be sent to the Manager side once the agent reconnects.
You could perform a test by monitoring a specific log file, disconnecting the agent, then introducing new log lines to the monitored file, and monitoring the archives.json once the agent reconnects. You should be able to verify that all the logs ingested during the disconnection were sent once it reconnected.
Additionally, the Wazuh agent has a log buffer. The buffer mechanism (Anti-flooding mechanism) is designed to prevent large bursts of events on an agent from negatively impacting the network or the manager. Its functionality is not to store events in a cache and flush them to disk. You can read more about this buffer here and here.
I hope this information helps.
Regards
Md. Nazmur Sakib