One of the first questions when considering network monitoring with PRTG is certainly the question of the sensors. Ultimately, the number of sensors determines the price of the software.

PRTG is currently completely free as freeware with 100 sensors. And as we will see, this is a lot and more than enough for a typical audio or Dante network in a theater or similar permanent installation.

What is a Sensor?

The simplest way to imagine a sensor is as a single value or parameter on a device. Do you want to know how warm your switch is? For this you need a sensor. Do you want to log the data rate of an uplink port? For this you need another sensor.

The more parameters you want to query, the more sensors you have to create. The number of devices is irrelevant here. Because if you monitor the temperature on 10 devices, or 10 different parameters on a single device (e.g. temperature, traffic from 8 ports, IGMP snooping on/off), then that's 10 sensors in both cases. The purpose of creating devices is more to create a hierarchy and to announce the IP address through which a sensor can query its value.

The total number of sensors is determined by the number of devices multiplied by the sensors per device.

I had already shown a few examples in the last blog article about PRTG. Here is another list of devices from a theatre with almost 100 sensors that is still using the PRTG Free version:

Each of the currently 12 Netgear M4250* switches is monitored in its basic settings with around 5 sensors each. So these are about 60 sensors.

There are also traffic ports for important devices such as the mixer and the DSP, various Shure microphone receivers, amplifiers for the speakers, etc. With 100 sensors, not every port on all switches can be monitored, but the most important devices can.

What types of sensors are there?

The range of different sensors from PRTG is immense. To be honest, it's so big that I've only used a fraction of it so far.

We will mainly deal with ping and SNMP sensors when monitoring networks or switches. Nevertheless, I would of course like to mention a few keywords that might give you ideas - if you use such protocols or devices in your network:

• Ping

• SNMP

• SMTP/POP3/IMAP

• HTTP/FTP

• MySQL

• NetFlow/sFlow

• Radius

• RDP (Remote Desktop)

• SNTP

• WMI

SNMP sensors

SNMP (Simple Network Monitoring Protocol) is a very common protocol. Most devices that offer a network interface can be queried more or less via SNMP. The range of functions sometimes differs considerably. While some devices can not only be queried but also controlled almost entirely via SNMP, other devices only offer the most important functions. For other functions, you have to use the device's own website or setting options directly on the device itself.

You can read an overview of the SNMP functionality of common switches and the difference between different manufacturers (Cisco, HP, Netgear, Luminex) in this blog article.

Traffic

This sensor monitors traffic for a port on a switch. When creating it, PRTG displays all available ports on the switch. It is therefore easy to set up without much knowledge.

You can specify whether the sensor should produce an error message when it is down, i.e. when the connected device is switched off. On the other hand, threshold values can be set that issue a warning or error message if the traffic (data rate) exceeds or falls below a certain value.

As a rule, you will at least monitor the uplink ports of all switches. Because the best redundancy via additional fiber optic connections is of no use if you don't notice that a connection has failed somewhere.

Custom (1-fold)

All other parameters are queried using OID (Object Identifier). This value must be entered manually in PRTG for each sensor. Some research is therefore necessary to find the OID for the temperature on a switch, for example.

Basically, PRTG can query everything from a device that can be accessed from the manufacturer using an OID.

Since most parameters are output numerically, you also have to deal with a translation table in addition to the OID. This could be, for example: 1=enable, 2=disable. Of course, without precise knowledge of the values, the best monitoring is of no use. Many manufacturers therefore issue so-called MIB files, which not only list the OIDs, but also provide the meaning of each parameter.

Custom Advanced (10-fold)

Since it doesn't require a lot of resources to query and store a value once per minute, PRTG has added an advanced SNMP sensor. It can query up to 10 OIDs. The big advantage is that it still only counts as a single sensor in terms of the package limits (100 sensors for the free version). So it makes sense to use the 10x sensor whenever possible.

In both cases, OIDs are queried and monitored by a device. And in both cases only numerical values are possible. Technically speaking, there are initially no hurdles to using the extended sensor.

The question of 1x or 10x is more of an organizational one. Each sensor can assume the status ok, warning, error or pause. Depending on the parameters, it is simply more practical if you don't put everything in one sensor, but rather group them together. I usually use temperature sensors individually and not mixed with other parameters. Because if the temperature is too high, different colleagues or departments usually have to take action than if the IGMP setting is incorrect.

Notifications can be sent via sensors. For this purpose, different users or user groups can be created who are only notified of certain sensor errors. The sensor that triggered the error is also named as part of a notification. It makes a big difference whether the sensor is only called “Switch 17” (and includes all 10 parameters that are actually queried), or whether the sensor reports “Switch 17 - Spanning Tree” and the appropriate colleague is informed directly.

At the latest when you create a map and want to display the values of the sensors, the 10x sensor reaches its limit. Only one of the 10 OIDs can be designated as the main channel of a sensor and displayed on a map.

Whenever information is to be displayed per port or per uplink in a map, it must be created individually as a sensor or only combined with those parameters that should not be displayed.

However, the 10x sensor can be used for certain basic parameters that never actually change, but which simply have to be right. For example, the basic settings for EEE, SmartPort or IGMP snooping simply have to be identical on all switches. It is not strictly necessary to show the details on a map. It is enough for an error message to appear if any of the 10 parameters accidentally change one day.

String

Whenever a device supplies the data for an OID as a string (i.e. not as a numeric value), there is no getting around the string sensor. Unfortunately, this is only available as a simple sensor, not as a 10-fold sensor.

The advantage of this sensor is that text is displayed in a readable form. For example, you can not only read the switch name, the firmware version or the MAC address, but also monitor it and send a warning if there are deviations from the usual status.

Sample calculation

PRTG is of course a very universal tool that can monitor all conceivable devices and parameters. In accordance with my usual field of activity, I limit the example calculation to an audio network of a medium-sized theater, i.e. primarily IT switches and the (audio) devices connected to them.

To estimate your approximate need for sensors, I would differentiate between two groups: firstly, those parameters that should be monitored equally on all switches. Secondly, parameters or ports that are only relevant on individual switches.

Global switch parameters

The number of parameters and therefore the number of sensors required per switch naturally varies depending on the basic setup. The more VLANs, the more parameters are relevant. And if MSTP is used (Multiple Spanning Tree), parameters are relevant for each created instance.

The following table should only be used as an idea for your own calculation.

Port / device monitoring

In addition to the basic parameters that affect all switches, the individual parameters - i.e. the number of ports to be monitored - must then be determined. Of course, a compromise needs to be found here. Not every port is equally important for the process, and therefore not every port and every device necessarily needs to be monitored.

A table could ultimately look like this:

Total sensors

The total number of sensors required is now the number of switches multiplied by the number of sensors per switch from the first table. For example, 8 switches x 7 sensors = 56 sensors for the basic parameters.

Added to this is the sum of individual sensors from the second table, for example 29. 56 + 29 results in 85 sensors that need to be created for our example calculation. The 100 sensors that PRTG supplies as freeware would be sufficient here.

A network with up to 10 switches can usually be monitored quite well with the free version. As soon as there are more switches or if more individual devices need to be monitored, you will eventually go beyond the limit of 100. PRTG can then be licensed in the first level with 500 sensors for around $1,899. Even for larger networks, i.e. for example a theater with several venues or stages etc., this should leave enough reserves for every conceivable parameter or port.

You can find more information about the PRTG packages from the manufacturer (Paessler).

I hope I was able to give you some insight into how to determine the number of sensors required for your network using the example tables. Have fun doing your own calculations!

More articles on the topic:

• PRTG: Which switches support SNMP?

• PRTG: Network monitoring - benefits and examples

• Dante: Typical Network Topologies

• Switch comparison: Cisco SG350 vs CBS350