PRTG | Network Monitoring Sensors


Network Monitoring

PRTG Network Monitoring Sensors

Show Network Sensors
This is a partial list of PRTG sensors that can be used for network monitoring.

SNMP Traffic - Use to display live total traffic, traffic in, traffic out and optionally errors. Great way to detect how "busy" a circuit is.
Ping - Used to detect network latency (delay) to a particular destination address. Great way to determine how responsive a circuit is based upon a single or multiple destination address tests. Yes, ping isn't a perfect way.
Jitter - Loosely stated the variance of ping latency, important metric for phone calls (audio).
http - Used to detect web site availability and/or responsiveness.
http advanced - Good way to detect download bandwidth, use with discretion.
hops/traceroute - Good way to detect routing changes that impact site responsiveness.
SNMP RMON - Used to detect part statistics, see sensor for more information.
Flow data - Supports Netflow (Cisco) and SFlow (Sampled Flow data). Great way to look at current or historical top talking IP addresses and/or protocols.
The SNMP Traffic sensor monitors traffic on a device using Simple Network Management Protocol (SNMP). You can create it on a device that provides traffic data, one traffic sensor for each individual port.
It can show the following:
  • Traffic in
  • Traffic out
  • Traffic total
You can also add additional channels:
  • Errors in and out
  • Discards in and out
  • Unicast packets in and out
  • Non unicast packets in and out
  • Multicast packets in and out
  • Broadcast packets in and out
  • Unknown protocols
Which channels the sensor actually shows might depend on the monitored device and the sensor setup.

SNMP Traffic Sensor

Click here to enlarge:

The SNMP RMON sensor monitors traffic on a device using the Remote Monitoring (RMON) standard via Simple Network Management Protocol (SNMP). You can create it on an SNMP compatible device that provides traffic data via RMON. Depending on the data returned by your device, traffic data for each port can be displayed in different channels, allowing detailed analysis. If available, the sensor queries 64-bit counters.
For each port, the sensor can show, for example:
  • Transmitted kbit/s
  • Packets (#/s)
  • Broadcast Packets (#/s)
  • Multicast Packets (#/s)
  • CRC Errors (#/s)
  • Undersize Packets (#/s)
  • Oversize Packets (#/s)
  • Fragments (#/s)
  • Jabbers (#/s)
  • Collisions (#/s)
  • Packets <= 64 Byte (#/s)
  • Packets 65 - 127 Bytes (#/s)
  • Packets 128 - 255 Bytes (#/s)
  • Packets 256 - 511 Bytes (#/s)
  • Packets 512 - 1023 Bytes (#/s)
  • Packets 1024 - 1518 Bytes (#/s)
  • Drop Events (#/s)
Which channels the sensor actually shows might depend on the monitored device and the sensor setup.  


Click here to enlarge:

The NetFlow V9 sensor receives traffic data from a NetFlow V9 compatible device and shows the traffic by type. Please make sure the sensor matches the NetFlow version your device is exporting! There are several filter options available to divide traffic into different channels.
This sensor can show the following traffic types in kbit per second:
  • Chat (IRC, AIM)
  • Citrix
  • FTP/P2P (file transfer)
  • Infrastructure (network services: DHCP, DNS, Ident, ICMP, SNMP)
  • Mail (mail traffic: IMAP, POP3, SMTP)
  • NetBIOS
  • Remote control (RDP, SSH, Telnet, VNC)
  • WWW (web traffic: HTTP, HTTPS)
  • Total traffic
  • Other protocols (other UDP and TCP traffic)
Which channels the sensor actually shows might depend on the monitored device and the sensor setup.

NetFlow V9 Sensor

Click here to enlarge:

The Ping sensor sends an Internet Control Message Protocol (ICMP) echo request ("Ping") from the computer running the probe to the device it is created on to monitor the availability of a device. Default is 5 pings per scanning interval.
It can show the following:
  • Ping time
  • Minimum ping time when using more than one ping per interval
  • Maximum ping time when using more than one ping per interval
  • Packet loss in percent when using more than one ping per interval

Ping Sensor

Click here to enlarge:

The Ping Jitter sensor sends a series of  Internet Control Message Protocol (ICMP) echo requests ("Pings") to the given URI to determine the statistical jitter.
This sensor shows the following:
  • Statistical jitter value
  • Execution time
The Real Time Jitter value is updated every time a packet is received using the formula described in RFC 1889:
Jitter = Jitter + ( abs( ElapsedTime – OldElapsedTime ) – Jitter ) / 16
The Statistical Jitter value is calculated on the first x packets received using the statistical variance formula:
Jitter Statistical = SquareRootOf( SumOf( ( ElapsedTime[i] – Average) ^ 2 ) / ( ReceivedPacketCount – 1 ) )

Ping Jitter Sensor

Click here to enlarge:

Other sensors:

QoS - Quality of Service
Traceroute - To determine hop count to a destination
http advanced - To determine download bandwidth (use with caution)
Syslog receiver - Not to replace syslog, but log for existence or not of certain messages
Other customer SNMP:
- Firewall examples: Sessions
Sample of a custom PRTG map (dashboard) showing some sensors.

PRTG Real World Troubleshooting

Show Example
This example shows a combination of items. It starts with an example of a circuit use notification setting and then some investigative work. This was cobbled together from a couple different samples to protect the innocent, but the general process is an exactly what I do to investigate abnormal traffic and how PRTG helps immensely to alert and assist in the process.
PRTG - Proactive Alert
Below is an example of a proactive traffic threshold alert setting. This will send an Email (or other) notification that the circuit has been busy for a period of time. That's the first clue that something unusual might be happening.

NOTE: While not shown, I could have additionally used a traffic chart to visually confirm the traffic spike and known the duration.

Result: From this we know that the circuit was busy for some period of time. We know the date/time, but not much else. Further investigation is warranted, but I prefer the system telling me versus getting a user complaint.
prtg traffic alert
Using Flow Data
Now that we know when, we'll use flow data to determine what devices and basic protocol information.

Flow data can show the source/destination IP addresses involved as well as the protocol. It's enough to potentially resolve the investigation. However, sometimes we need more.

Result: From this we know what type of protocol was involved and while not shown on the sample we would also know the source/destination address. That's good, but we don't yet know who as in user and we don't know a lot about the protocol.

NOTE: Network flow sensors are included with PRTG. You do need devices that can provide flow data to PRTG or use a span/mirror port.
Show Flow Data
PRTG flow example
Using a Next Gen Firewall - Part 1
The previous data got me curious to know more. In this case we're showing the results from a next generation firewall to show more information.

NOTE: While PRTG provided the bread crumbs, we're using a next generation firewall to get more information beyond general ip address, protocol and date/time. At this point, we're looking at internal tools to further compliment what PRTG has alerted us to.

Result: This is good, we have confirmation now on the firewall of the observed traffic. I'm starting to feel relieved as now I know it was an apple update that occurred on one of my servers during the early morning hours.
Show NextGen FW data
Nextgen Firewall
Using a Next Gen Firewall - Part 2
I feel relatively confident, but I want more data, so this confirms now the application, source and destination address (along with countries). Since this was a server versus a user, the source user isn't known, but isn't applicable.

I can now feel confident this was legitimate traffic.

We went from getting an abnormal traffic alert to learning what device was involved, when it was involved, what application generated it along with where it went.

We can now close this incident.
Show NextGen FW data
Nextgen firewall
PRTG | Network Monitoring Sensors