21. Monitoring and Recovery
While considerable effort is put into eliminating software bugs from NXLog, no complex piece of software is perfect. This section describes potential ways to automatically recover from an error that results in a crash of NXLog. Note that there are other monitoring solutions than those shown here which may also be of interest.
21.1. Monitoring on Unix Platforms
Monit can be used on several flavors of Unix and macOS to both monitor and recover NXLog after a crash. Monit can be installed directly from your distribution’s package manager—see Installation on the Monit wiki for more information about installing Monit. Precompiled binaries can also be found here.
While Monit can monitor and react to several conditions, the requirement presented here is to restart NXLog after a crash. To do so, include the following in the Monit configuration. It may be necessary to adjust the paths for the particular installation. Then restart Monit.
check process nxlog with pidfile /opt/nxlog/var/run/nxlog/nxlog.pid
start program = "/etc/init.d/nxlog start"
stop program = "/etc/init.d/nxlog stop"|
Note
|
On recent Linux distributions employing systemd, the start and stop
directives should use systemd calls instead (for example,
/bin/systemctl start nxlog).
|
To simulate an NXLog crash, execute the following in a shell (<PID>
is the process ID of NXLog).
# kill -9 <PID>21.2. Monitoring on Windows
The service control manager (SCM) in Microsoft Windows includes recovery options, as shown below; these can be adjusted as required.
|
Note
|
Newer versions of NXLog will enable automatic recovery during the installation. For older versions, automatic recovery can be enabled by manually editing the values in the recovery tab of the SCM. |
To simulate an NXLog crash, execute the following in PowerShell
(<PID> is the process ID of NXLog).
PS> Taskkill /PID <PID> /F