Agent host offline issue, agent reports monitoring data error, agent logs printed Anti tampering verification failed Or If the number of tamper proof verification errors exceeds 10, no more data will be reported

As long as the agent of the controlled host fails to report monitoring data for more than 5 minutes, the system will determine that the host has been taken offline
Check in sequence
1、 It may be that the agent host cannot ping the server host or cannot access the server port
We can use ping [server IP] and telnet [server IP] 9999 on the agent host to test connectivity
You can also check the log files under agent/log for any error messages
2、 Check the serverUrl of the agent configuration file
Perhaps there is a problem with the character format, such as commas and colons being written as Chinese characters, or it could be an error in IP or port writing
3、 The time difference between the server and agent's host systems cannot exceed 16 hours
If the time difference does not exceed 16 hours, print a message similar to 'Anti tampering Verification Error' and ignore it. There will be no impact
4、Is it because the agent's process wgcloud-agent was killed, or the agent host was restarted or powered off, causing the agent to not run
We just need to start the agent again
Agent process inexplicably stopped running by kill, how to handle it
5、 wgcloud-server-release.jar Do not edit or modify
Do not change the file name either. If you have edited it, please restore it to the original wgcloud-server-release.jar in the installation package
6、 The server and agent should maintain the same version number
How to check the version numbers of servers and agents
7、Do not close the server-side daemon (wgcloud-daemon-release)
Especially on Windows, do not close the daemon window. If it's Linux, the daemon may have been killed. Check if the daemon is still alive (ps -ef | grep wgcloud
Another possibility is that the server is deployed on Windows and accidentally left clicked on the window of the daemon to enter edit mode. Right clicking on 'restore' will fix the issue
If it is caused by this reason, simply restart the server (the daemon will start with the server), and all controlled agents will gradually resume online within 1 hour. You can also manually restart the agents (go online immediately)
8、 The default port of the daemon wgcloud daemon release was modified, but the daemon port was not synchronously modified in the server configuration file
View modification instructions
9、Check if the local server can be accessed normally http://localhost:9997 Obtain return value
For example: 2faa233a1400201bedc199fe1d8ab393,If the localhost of the server host cannot be used, you can change the localhost in the configuration file server/config/application.yml to the server host IP in the following configuration items
Note that if changed to IP, check if there is a firewall blocking port 9997
10、Check the server logs to see if the server is unable to connect to the database
If this is the case, after handling the server, the agent will gradually go online within 1 hour, or you can restart the agent to go online immediately
11、If the server is running on a CPU architecture system such as ARM or MIPS, the daemon wgcloud-daemon-release needs to be replaced with the corresponding version
Click to download
12、If the server or daemon (wgcloud-daemon-release) does not start and run for a long time
So when the server restarts, the agent will automatically resume online within 1 hour without restarting the agent. You can also manually restart the agent and it will immediately resume online
13、Check if there is security software and set some filtering rules, which prevent the agent from reporting data to the server
Some firewalls have strange rules that allow agents to request data from the server, but cannot submit or report data to the server
14、If deploying a server on Docker
Let's check if we have changed the localhost in the daemon URL in config/application.yml to the host IP address, as follows
Generally, it needs to be modified unless it is accessible within the Docker container http://localhost:9997 If so, then it can be left unchanged
15、Generally, these are the reasons mentioned above