Syslog Monitoring

Using the Syslog EventSource, LogicMonitor can monitor syslog messages pushed to the Collector for alerting purposes only. The Syslog EventSource is not intended as a syslog viewing or searching tool.  For Syslog viewing and searching, you can use LM Logs. See Collecting and Forwarding Syslog Logs.

Setting Up Syslog Monitoring

To set up your system for syslog monitoring, complete the following steps:

1. Configure the syslog Collector
2. Configure the syslog message source
3. Create the syslog EventSource

Step 1: Configure the Syslog Collector

By default, the Collector listens on port UDP/514 to receive the incoming syslog messages. If you would like the Collector to listen on a different port, you can edit the eventcollector.syslog.udp.port property found in the Collector’s agent.conf file. (For instructions on editing a Collector’s configurations, see Editing the Collector Config Files.)

Step 2: Configure the Syslog Message Source

There are two typical configuration scenarios:

• Configuring the syslog daemon. Configure the syslog daemon running on the monitored device to forward syslog messages to the Collector.
• Configuring the central syslog server. If you have a central syslog server, configure it to forward syslog messages to the Collector. Under normal circumstances, the Collector will parse the syslog message for a hostname and assign the event to the monitored resource; if that resource property cannot be found within the message, it will associate the event with the centralized log server instead (assuming it has been added into LogicMonitor.)

The following example configures a UNIX syslog daemon to forward all syslog messages with the severity err to the device 172.16.0.12 on which the Collector is running.

*.err @172.16.0.12

Please refer to your syslog server/daemon manual for information on how to configure message forwarding.

Step 3: Create the Syslog EventSource

You can create a new EventSource by selecting Settings | LogicModules | EventSources | Add | EventSource. As shown next, be sure to set the Type field to “SysLog.” This will ensure you see the appropriate filter options.

The figure above creates a syslog EventSource titled “Syslog Test” that applies to device 172.16.19.185. Only syslog messages that satisfy ALL four of the configured filters will be stored in the LogicMonitor database and trigger alerts:

• Severity | MoreUrgentThan | Warning. The first filter listed is a Severity filter type. It requires the severity of the message to be more severe than Warning (i.e. Error, Critical, Alert, or Emergency). Note that syslog assigns numerical values to severity levels, with lower values indicating higher urgencies.
• Facility | Equal | local use 0 (local0). The second filter listed is a Facility filter type. It requires the facility of accepted messages to equal “local0” (which syslog identifies with the facility code of 16).
• Message | RegexMatch | 15031|15033|15035. The third filter listed is a Message filter type. It requires the syslog message to contain the substring of either “15031,” “15033,” or “15035.” The RegexMatch comparison operator can be effectively used to build an OR statement that returns TRUE if one or more of the substring values is present.
• Message | Contain | attack. The fourth filter listed is also a Message filter type. It requires the syslog message to contain the substring “attack.” Note that the Contain comparison operator is case-insensitive.

Note: If alerting is disabled for a syslog EventSource (or is disabled at a higher level such as a device or group) no syslog events will be displayed.

Mapping Between Syslog and LogicMonitor Alert Severities

High Availability Syslog Alerting

Syslog monitoring alerts can use LogicMonitor’s backup Collectors for high availability alerting of syslog events. In order to do this, configure your devices to send syslog messages to both the primary and backup Collectors. LogicMonitor Collectors only alert on syslog messages from devices they are currently monitoring. Therefore, the backup Collector will ignore all syslog messages while it is not monitoring the syslog device, but will commence alerting on them in the event of a Collector failover.