That's not a bad idea. To it improve a little, perhaps each of the clients could be configured to send a message at a regular interval (providing a "heartbeat" or a "mark"). With Rsyslog, the directive is
[on|off]. But heed the man page:
Note that this option auto-resets to "off", so if you intend to use it with multiple actions, it must be specified in front off all selector lines that should provide this functionality.
What if there is an undiscovered configuration problem on the Syslog server that causes messages to be directed to an unexpected location, such as the file you monitor to show that the client is alive? Perhaps a more rigorous test might be to (grep/awk) for the "heartbeat" or "mark" messages provided by
$ActionWriteAllMarkMessages, looking for the time of the message from a specific host.
To verify that the remote Syslog server is running, you could use netcat (
nc) with the
-u switches. From the manual:
-u Use UDP instead of the default option of TCP.
-z Specifies that nc should just scan for listening daemons, without sending any data to them. [...]
For example, with a five-second timeout (
hostname="<FQDN or IP Address>"
if (nc -z -u -w5 "$hostname" "$port" > /dev/null 2>&1); then
echo "Syslog is up."
echo "Syslog could not be reached."
Or, if the Syslog server also uses TCP, then you might omit the
-u switch to take advantage of the reliability of TCP, if only for this purpose. This checks that the Syslog server is listening and available from the location of the server performing the connectivity check. There's another facet that has equal importance: disk space. (If the Syslog server runs out of space to write messages, then the Syslog server may as well be considered down.)
Considering that UDP can be "unreliable" by design, counting on the "mark" or "heartbeat" message might not always work in a congested network or Syslog server. Another approach might be to install a script on each client. The script (BASH, Python, or whatever works) could return whichever error code you devise (e.g.: Syslog process not running? return 1 or try to start the Syslog process first, or devise other tests like connectivity tests, et al). Use
xinetd to start the script from
/etc/xinetd.d/script_name (on RHEL/CentOS):
type = UNLISTED
port = 6777
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/local/sbin/script_name
only_from = 127.0.0.1 10.0.0.110
disable = no
On RHEL the restart command is
service xinetd restart. Edit
/etc/services to give a name to port 6777. I like to use
iptables to augment the
only_from stanza. By the way, the port, 6777, was used just for illustration.