<%NUMBERING1%>.<%NUMBERING2%>.<%NUMBERING3%> PRTG Manual: Monitoring Syslogs and SNMP Traps

PRTG is utilizable as a full scale syslog server and SNMP trap receiver. Every PRTG installation includes this functionality so no additional software is needed. This manual section describes a sample configuration for PRTG's syslog and SNMP trap receiver and gives you an idea about how to use these features.

Syslog is a well-established standard for computer message logging. Many network devices support sending syslogs to communicate informational, analysis, and debugging messages which are intended for network management and security auditing. SNMP traps are asynchronous notifications from SNMP-enabled devices and can be used to report important incidents and data, just like syslog messages. Devices trigger these messages for various reasons, such as system events, outages, critical conditions, and many more.

PRTG provides two dedicated sensor types that work as full scale syslog and SNMP trap receivers:

• SNMP Trap Receiver Sensor
• Syslog Receiver Sensor

Because both the syslog and the trap receiver are implemented as common sensor types, you do not need to install software in addition to PRTG (for example, you do not need an extra syslog server but only the PRTG web server). You can create the Syslog Receiver as well as the SNMP Trap Receiver sensors in the usual PRTG way via the add sensor dialog. Then configure your syslog or SNMP trap–enabled device(s) to send messages to PRTG.

Under lab conditions, PRTG could handle about 10,000 syslog and trap messages per second on a quad core desktop machine when using a single sensor without filters.

The number of messages PRTG can process actually depends on your configuration and system setup. It might be significantly fewer messages.

You can filter the incoming messages by various parameters so that PRTG will process only specific messages and purge other data right away. Processed messages are stored in an internal high-performance database on the particular probe machine and are available for review and analysis via the PRTG web interface. The main limiting factor for storing syslog and trap messages is the hard disk space on the machine running the PRTG probe with these sensors.

Sample Configuration

Follow the steps below for a sample configuration of Syslog and SNMP Trap Receiver sensors. You can apply these instructions to both the SNMP Trap Receiver as well as the Syslog Receiver because the setup works in a similar way for both.

1. Adding the Receivers
2. Configure the Source Devices
3. Collect Messages
4. Review and Analyze Messages
5. Refine the Filters
6. Create Notification Triggers

Step 1: Add a Syslog Receiver or SNMP Trap Receiver sensor to PRTG.
Both sensor types inherit an implicit filter from the IP address of the parent device. So, on the one hand, it is possible to add these sensors to a probe device. Then you will receive all messages from the system running the probe and can optionally filter for specific sources later. On the other hand, you can add these sensors directly to the source device. Then only messages from this device will be processed.

Add the receiver sensors to the desired device in the common way, for example, via the device's context menu. We recommend leaving the sensor's default settings unchanged for the first configuration (port, include and exclude filter, warning and error filter) to see what data actually comes in.

Adding the sensor to a network device directly will increase its speed in comparison to a filter definition in the sensor settings. Distributing Syslog and SNMP Trap Receiver sensors over different probes will make the overall performance scalable and gives you flexibility with the data storage location.

If you do not add the sensor to a probe device but to another device in PRTG, be careful with the configuration: Ensure that the IP address or DNS name of the parent device matches the proper sender. For example, if you want to receive syslog or trap messages from a Storage Area Network (SAN), you might have to add a device to PRTG using the IP address of a specific array member that sends the messages. Providing a DNS name that points to the IP address of a whole group might not work for SANs.

 
Step 2: Configure your network device(s) that support sending syslogs or SNMP traps appropriately.
Configure your syslog or SNMP trap ready devices to send syslogs or traps (see the documentation of the respective device vendors). They have to address the PRTG probe where your Syslog or SNMP Trap Receiver sensor runs. So specify the IP address of the machine with the respective PRTG probe. If you keep your syslog or trap receiver's default settings, use the port 514.

The protocol is User Datagram Protocol (UDP).

The SNMP Trap Receiver does not support SNMP v3 traps. Please use SNMP v1 or v2c instead.

 
Step 3: Start collecting syslog or SNMP trap messages from your devices.
You do not have to complete any further configuration steps to use PRTG as a syslog server or SNMP trap receiver. When your device(s) send syslogs or SNMP traps to the specified PRTG probe machine, the messages appear automatically in the PRTG web interface. After each sensor scan (by default, the scanning interval is inherited from the parent device), PRTG will count the received syslogs or traps in the according channels (total number of messages during the last interval, error and warning messages, or dropped packets).

Let the syslog receiver or the SNMP trap receiver collect data for a while to see what comes in. By default, the respective sensor will go into a Warning status if there was at least one message with severity 4 and into an Error status if there was at least one message with severity 3 or lower during the last sensor scan.

Incoming messages are counted per scanning interval, so it might take a few moments to see the received syslogs and traps, depending on the remaining time until the next sensor scan. Of course, you can use Check Now via the sensor's context buttons to perform an immediate scan and see corresponding data. The sensor states are also defined per scan.
So, for example, a message that is classified as an error will count for the error channel only for one scanning interval. If there is no new error message in the following scanning interval, no message is shown in the error channel and the error status will disappear after the next sensor scan. The syslog or trap itself will still be accessible on the Messages tab.

 
Step 4: Review and analyze the collected data.
All incoming messages that match the include filter are processed and stored in PRTG's internal high-performance database. Review and analyze the received syslogs and traps via PRTG's web interface. For details, see the respective manual sections of SNMP Trap Receiver Sensor and Syslog Receiver Sensor. Then you can decide about further filtering of the incoming messages.

The received data is also available in PRTG's data folder as common files. One data file is created per hour.

In PRTG on premises you can add the Management Information Base (MIB) files of your devices to the \MIB subfolder to use them with the SNMP Trap Receiver sensor. This will result in Object Identifier (OID) resolution and makes trap messages more comprehensible. For example, instead of the OID 1.3.6.1.4.1.32446.1.1.2 you would see SNMPv2-SMI-v1::enterprises.32446.1.1.2 = 0 (example from the PRTG MIB).

 
Step 5: (Optionally) refine the filters.
In order to increase productivity with your PRTG syslog servers and trap receivers, you can adjust the default filter settings. PRTG provides you a comprehensible formula system that you can use to describe what kind of messages you want to process and which of them will count as error or warning messages. You can configure the following filters for received messages in the settings of the respective receiver:

• Include filter: Process and store specific types of messages only.
• Exclude filter: Do not process specific types of messages and discard them.
• Warning filter: Define rules to categorize received messages as warnings.
• Error filter: Define rules to categorize received messages as errors.

Use the syntax that is provided in the corresponding manual sections to define your individual filter rules: SNMP Trap Receiver Sensor and Syslog Receiver Sensor.

You can create filter rules with a few mouse clicks in the Advanced Filter on the Messages tab of a specific sensor and copy these rules into the sensor settings to apply them.

 
Step 6: (Optionally) create notification triggers.
By default, the warning and error channels of the Syslog and SNMP Trap Receiver sensors have a very low upper warning or error limit (0.00000001). The reason for this is that even when only one syslog or trap has been counted in the respective channel during a scanning interval, the overall status of the sensor will show this with the corresponding status. This way, you always recognize if there is something wrong on the monitored system.

Because of this sensor behavior, best practice would be to add a State Trigger on the Notifications tab of the sensor if you want to get a notification when a warning or error message type comes in. Define 0 seconds Down or Warning time condition to not miss any warnings, errors, or any other messages. Another option would be a Speed Trigger for notifications regarding messages per second.

See also this Knowledge Base article: How can I configure sensors using speed limits to keep the status for more than one interval?

 
You can use syslog and trap specific placeholders in notification templates in order to see the messages when you receive a notification. See the More section below for more information.

Click here to enlarge: https://media-s3.paessler.com/prtg-screenshots/syslog_howto7_notification.png

More

Knowledge Base: How can I configure sensors using speed limits to keep the status for more than one interval?

• https://kb.paessler.com/en/topic/73212

Knowledge Base: What placeholders can I use with PRTG?

• https://kb.paessler.com/en/topic/373

Sensor Technologies—Topics

• Monitoring via SNMP
• Monitoring via WMI
• Monitoring via SSH
• Monitoring Bandwidth via Packet Sniffing
• Monitoring Bandwidth via Flows
• Bandwidth Monitoring Comparison
• Monitoring Quality of Service
• Monitoring Email Round Trip
• Monitoring Backups
• Monitoring Virtual Environments
• Monitoring Databases
• Monitoring Syslogs and SNMP Traps