Setting up Syslog monitor

Table of contents

Q: What is Syslog monitor and how can I use it? A: This monitor provides a powerful tool to get quickly notified on events on systems supporting RFC 3164 and RFC 5424 type of BSD Syslog Protocol. Simply speaking, all system events on all network devices supporting syslog protocol (that includes almost all Unix-like systems and many network devices) can be monitored this way. That includes modern implementations (such as rsyslog which is currently de facto logging standard). Below we provide short instructions on setting up your first Syslog monitor for a Linux-powered system. We assume that you are fluent enough with a Linux system to do that.

Create monitor with default values

To begin, create a Syslog monitor for the specified Linux host. Its Main parameters should look like this:

Setup syslog service to send messages

On the target (Linux, in our example) host, sudo as root user and open for editing file /etc/rsyslog.conf. Add to its end line like this:

user.info      @192.168.122.11:514

Meaning of above:

user: facility name (choose one of “auth”, “clock”, “cron”, “daemon”, “ftp”, “kernel”, “local0”, “local1”, “local2”, “local3”, “local4”, “local5”, “logalert”, “logaudit”, “lpr”, “mail”, “ntp”, “news”, “security”, “syslog”, “user”, “uucp”, or “*” to match any facility)
info: level (severity) of event (choose one of “emerg”, “alert”, “crit”, “err”, “warning”, “notice”, “info”, “debug”, or “*” to match any level)
@ means use UDP as transport protocol (note: IPNetwork only supports UDP)
192.168.122.11: IP address or host name of system running IPNetwork (the one that listens to syslog messages)
514: port on IPNetwork system to send events to (514 is a standard syslog port)

Restart rsyslog daemon (depending on the system in use, that can be done by running corresponding command, i.e. “sudo service rsyslog restart” or “systemctl restart rsyslog” etc). You have instructed rsyslog to send syslog messages from “user” facility and “info” level to your IPNetwork installation.

Test configuration

On IPNetwork side, run the newly created Syslog monitor. It should enter “Unknown” state:

On Linux side, run the below command:

logger -n 192.168.122.11 -p user.info "Test message"

where “user.info” should match the corresponding string added to /etc/rsyslog.conf, parameter after “-n” is IPNetwork system IP address, and the message itself is an arbitrary string. On IPNetwork side, monitor should switch to “OK” state:

If you have set alerting to send event emails, like this (click “Alerting” tab):

then the above test will result in email being sent; if default email template is used, there will be syslog event information within, similar to this one:

Details:          Is RFC 5424 = 1
 IP = 192.168.122.1
 Host = linux-host
 Application (tag) = ubuntu
 Process Id = 0
 Message Id = 
 Severity level = INFO
 Facility = user
 Date and time = 2018-07-26T14:09:12+07:00
 Structured data = [timeQuality isSynced="1" syncAccuracy="1011000" tzKnown="1"]
 Message = Test message
Last result:      N/A at 7/26/2018 2:09:12 PM

Run the logger command again, on Linux side, to see new Event email coming, with corresponding data.

Adapting to real-life cases

Let’s get more realistic type of Syslog monitor. Assume you need to get notified every time a valid user fails to login to Linux host. Since that can be a frequent event, let’s only get no more than 4 events per minute. “Main parameters” for your Syslog monitor might look like below:

Similarly, adjust /etc/rsyslog.conf line on Linux host to

auth.info      @192.168.122.11:514

(use actual IP address of your IPNetwork system) Do not forget to stop and start monitor every time you change its settings. Now try to log in to the Linux host as a valid user (e.g. root) and as an invalid one, every time entering invalid password, and see an event alert executing. Please read more about Syslog monitors parameters in corresponding monitor type description.

Tips and tricks

1. Every time you cannot catch a Syslog event, try setting monitor to default (catch any type of event) state, in both /etc/rsyslog.conf and locally, stop and start monitor and use logger utility remotely to simulate an event. 2. If a Linux system supports “conf.d” configuration, you might wish to create a separate file, say, /etc/rsyslog.d/10-ipnetworkt.conf and place all your rsyslog configuration lines into it. 3. Avoid using wildcard (“*”) facility and/or level settings in rsyslog, since that can result in sending really much data to your IPNetwork system. For the same reason, always restrict amount of events accepted (using “Accept no more than…” settings). On a busy system, dozens event per second can be an usual situation, thus setting facility.level mask to “*.*” can result in overwhelming stream of email messages. 4. You can place several rsyslog lines, for different facility.level combinations (if you need several Syslog monitors for the same host). 5. Since UDP doesn’t guarantee delivery, the event messages can be lost if network load is very high; please monitor traffic speed at your IPNetwork system, if you think your Syslog messages can be lost. 6. You can set up a dedicated Linux host accepting syslog events from other hosts, and use it as syslog events aggregator (to avoid creating multiple separate Syslog monitors).