Sneak Peek into Our Labs: Introducing the New High Performance Syslog and SNMP Trap Receiver Sensors
Originally published on October 10, 2013 by Gerald Schoch
Last updated on February 10, 2020 • 14 minute read
Today we have good news for all administrators who are tired of redundant one-trick-pony software products: PRTG Network Monitor will soon include a new Syslog Receiver as well as an SNMP Trap Receiver. Both sensor types are currently running in our labs and are still smelling pleasant like freshly brewed coffee in the morning. We can already safely say: Wow! What a high performance, what an intuitive and easy handling!
Syslog is a well-established standard for computer message logging. Many devices support sending syslogs to communicate informational, analysis, and debugging messages that are intended for network management and security auditing. SNMP Traps are asynchronous notifications from SNMP-enabled devices and can, like syslog messages, be used to report important incidents and data. Devices trigger these messages for various reasons, such as system events, outages, critical conditions, etc.
Our Syslog and SNMP Trap Receiver sensors will help a system administrator analyze a network in detail and to gain a new look at it. The receivers are designed for high performance usage in larger networks: They are able to handle more than 10,000 messages per second on a quad core desktop machine as we have seen in our labs (when using one single sensor without filters; the number of messages PRTG can process actually depends on your system setup)—which is faster than most of our competitors' products!
Network devices send syslog or SNMP trap messages to the machine running PRTG—depending on the number of devices, this can be quite a lot of messages! PRTG is able to filter the incoming messages by manifold parameters like, among others, source, severity, and facility, to name a few. You can define corresponding filter rules via filter fields in the sensor settings and tell PRTG what kind of messages you want to monitor and store for later analysis. The received data is stored in an internal high performance database and available on your respective probe system as common files (one file is created per hour).
You can add the Syslog and SNMP Trap Receiver sensors either to a probe device—receiving all messages of the system running the probe—or to a device directly. You will receive the syslogs from this device when adding the sensor directly, making the sensors even faster than if you use source filters in the sensor settings. Distributing Syslog and Trap sensors over different probes makes the performance scalable and gives you variability for the place of data storage.
Reviewing and Analyzing
You can review and analyze all received messages later in a comprehensible way in PRTG's web interface by accessing the data directly via the respective sensors! There you also have display filter options to drill down into the data for specific events of your interest. This works really easy—just click on the filters of interest in the received messages overview and provide additional information like source or severity, whatever you wish.
Besides the usual downtime of a sensor, there are three special channels: One sums up all received messages over time. The other two channels count all warning and all error messages, and show the total per scanning interval. With filters, you can also individually define the messages that will be assigned to a certain channel. For example, you can account certain severity levels to the "warning" or the "error" channel, respectively. Additionally, the sensor shows dropped packets in a dedicated channel.
Filtering Incoming Messages: Avoiding Useless Information
In the sensor settings, you can define which messages PRTG will process. The more specific you are on which messages you're interested in, the better PRTG can provide interesting data and purge other data right away. However, if you decide to keep most of the incoming messages, all you need is a large hard drive, and PRTG will help you with filters to explore historic data later on. For the purpose of filtering, PRTG provides you two fields:
- In the "Include" field, enter a filter for messages you want to monitor. Only messages which match this filter will be processed and stored. You can choose all incoming messages with "any" or by leaving this field empty.
- In the "Exclude" field, enter a filter for messages you do not want to monitor. Messages matching this filter will be discarded.
Two other filter fields are available to define which messages will count for the "warning" or "error" channel. By default, both channels have a very low warning respectively error limit (0.00000001). The idea behind this is that the sensor will immediately go into the corresponding status as soon as "bad news" comes in. Of course, you can set your own limit as desired—as is usual with PRTG.
For example, in order to receive, an email if there are warning or error system messages, you can add a notification trigger to the sensor. Triggers of choice would be a certain status—notifying you when the sensor is down or warning—or speed, notifying you, for example, when there are ten error messages per second.
You are free to use various filters to suit your needs though we recommend running the Syslog or Trap receiver with default filter settings first. Once you've run the sensor for a little while, take a look at the results and adjust the filters to fit your needs. In the sensor settings, you can use formulas to define your filters. You can also link conditions in a respective filter field with Boolean operators (and, or, not) and parentheses.
Below, we list available filter options with possible parameters and the corresponding syntax for the syslog receiver. But don't be afraid if it looks a bit complicated to you, PRTG wouldn't be PRTG if there wouldn't be an easy way to use it: When our new Syslog and Trap receivers are ready to leave our lab, you will be able to create these rules with a few mouse clicks via a filter creator in the messages overview.
- source[<ip>]: the IP address where the messages will be received from; masks and ranges are also possible here
- facility[<number>]: any number from 0 to 23 (or range) specifying the type of program which is sending the message
- severity[<number>]: any number from 0 to 7 (or range) specifying the type of message
- hostname[<string>]: any string specifying the hostname of a device in the message
- tag[<string>]: any string specifying the tag of a program or process in the message
- appname[<string>]: any string specifying the appname part of the message
- procid[<string>]: any string specifying the process identifier part of the message
- msgid[<string>]: any string specifying the message identifier part of the message
- message[<string>]: any string specifying the message part of the message (substring match)
- data[<SD-ID>,<PARAM-NAME>,<PARAM-VALUE>]: checks the SD-ID block of the message's structured data for a parameter matching the given value
Note that the strings have to match exactly the particular parts of the message (case sensitive!). The relevant supported RFCs are RFC 3164 and RFC 5424. Boolean operators (AND, OR, NOT) and brackets are available.
- severity[0-3]: matches only messages with a severity of 0, 1, 2, or 3 (error messages)
- facility OR facility: matches messages having the facility 2 (mail system), or messages with the facility 4 (security/authorization messages)
- appname[demo] AND msgid[m42]: matches only messages having "demo" in the appname part and the "m42" in the msgid part
- data[exampleSDID@12345,eventSource,Application]: matches only messages where the "exampleSDID@12345" block of the message's data structure has the parameter "eventSource" with the value "Application"
No Add-Ons—All in for Free!
Both the Syslog Receiver and the SNMP Trap Receiver sensor will be available in PRTG Network Monitor soon, even in the Freeware Edition. These new sensor types will enable you as a PRTG user to keep an eye on your Syslog messages and SNMP Traps in an effective and systematic way without the need of annoying add-ons or complicated settings. You will gain an even deeper understanding of your network, plus you save a considerable amount of money.
Giving you this outlook on some of PRTG's upcoming features, we are sure you will appreciate this new functionality as much as we do. The whole PRTG experience is ready to move on to the next level! You can test it soon in our Preview channel (not for use on live systems!).
By the way, you can have a preview of these features at IP Expo in London and at VMworld Europe in Barcelona this week. Or get yourself a free Trial version for a deep first impression of PRTG.