IN THIS ARTICLE:
Introduction to Syslog Monitoring
LogicMonitor can monitor syslog messages pushed to the Collector for alerting purposes, but is not intended as a syslog viewing or searching tool. Consequently, alerts can only be generated for syslog messages assigned severities of Warning, Error, Critical, Alert, or Emergency. (Debug, Informational, and Notice messages are discarded.)
Setting Up Syslog Monitoring
To set up your system for syslog monitoring, complete the following steps:
Step 1: Configure the Syslog Collector
By default, the Collector listens on port UDP/514 to receive the incoming syslog messages. You can edit
The following example configures the Collector to use port UDP/8888:
There are two typical scenarios:
- Configure the syslog daemon running on the monitored device to forward syslog messages to the Collector.
- If you have a central syslog server, configure it to forward syslog messages to the Collector.
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.
Please refer to your syslog server/daemon manual for information on how to configure message forwarding.
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
LogicMonitor Alert Severity
|5- Notify||Ignored (not used)|
|6- Informational||Ignored (not used)|
|7- Debug||Ignored (not used)|
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.