How To - Direct Backup Manager logging to syslog

Notice:
The standard syslog location for Debian / Ubuntu systems : /var/log/syslog
The standard syslog location for RHEL / CentOS systems : /var/log/messages

Redirecting server.log output to syslog

The Backup Manager's server.log file contains startup and operational messages, such as task info, user logins, Backup / Restore / Verification task info etc...

Logging configuration for server.log is located here : /usr/sbin/r1soft/conf/log4j.properties

The section containing the log output destination looks like this by default :

 # 3 defined output destination for logs are console, log file and unix syslog. Appenders for 3 have been defined as
 # STDOUT, LOGFILE and SYSLOG. Logging to log file is enabled by default.
 # To enable logging to any of the 3 destinations, add corresponding appender to below configuration separated by coma.
 # e.g to log to console as well as log file, make it log4j.rootLogger=INFO, LOGFILE, STDOUT
 log4j.rootLogger=INFO, LOGFILE  

To redirect server.log output to ONLY syslog , set the log destination options like this example, in log4j.properties:

 # 3 defined output destination for logs are console, log file and unix syslog. Appenders for 3 have been defined as
 # STDOUT, LOGFILE and SYSLOG. Logging to log file is enabled by default.
 # To enable logging to any of the 3 destinations, add corresponding appender to below configuration separated by coma.
 # e.g to log to console as well as log file, make it log4j.rootLogger=INFO, LOGFILE, STDOUT
 log4j.rootLogger=INFO, SYSLOG  

Save and exit the file, and restart the Backup Manager service.

To redirect server.log output to BOTH server.log and syslog , set the log destination options like this example, in log4j.properties:

 # 3 defined output destination for logs are console, log file and unix syslog. Appenders for 3 have been defined as
 # STDOUT, LOGFILE and SYSLOG. Logging to log file is enabled by default.
 # To enable logging to any of the 3 destinations, add corresponding appender to below configuration separated by coma.
 # e.g to log to console as well as log file, make it log4j.rootLogger=INFO, LOGFILE, STDOUT
 log4j.rootLogger=INFO, LOGFILE, SYSLOG  

Save and exit the file, and restart the Backup Manager service.

To redirect server.log output to an external or central log host

Configure the rootLogger as explained above, and then update the following line in log4j.properties to reflect the hostname or IP of the central log host.

Example:

 log4j.appender.SYSLOG.SyslogHost=example.host.com 

It's also possible to specify a custom port by appending :PORT to the end of the line.

Example:

 log4j.appender.SYSLOG.SyslogHost=example.host.com:514 

Save and exit the file, and restart the Backup Manager service.

.

Typically these steps are sufficient to successfully send the server.log output to syslog. If after making the change listed above, the server.log output is not being sent to syslog (or if only startup messages are being sent), some additional configuration may be necessary to redirect the complete log. In most cases, this is because the UDP receiver may not be enabled. This option provides the ability to receive syslog messages via UDP.

.
This option can be enabled in : /etc/rsyslog.conf
Add or uncomment the following lines:

 $ModLoad imudp
 $UDPServerRun 514  

Save and exit the file, and restart the rsyslog service for the changes to take effect.

NOTE : In some cases, additional configuration to firewall and/or SELinux rules may be necessary.

Redirecting monitor.log output to syslog

The Backup Manager's monitor.log file contains port bindings, Tomcat Web Server messages, Java and resource messaging ..etc.

Logging configuration for monitor.log is located here : /usr/sbin/r1soft/conf/server.conf

To direct monitor.log output to syslog :

Edit /usr/sbin/r1soft/conf/server.conf , and change the following line :

 syslog.loglevel=NONE
 To...
 syslog.loglevel=INFO 

Save and exit the file, and restart the Backup Manager service.

NOTE : When restarting the Backup Manager, it's always good practice to enable Maintenance Mode, and allow all running tasks to complete before restarting the service.