What if PRTG suddenly acts up?

Paessler’s PRTG is a very powerful, yet easy-to-use monitoring software for networks, IT and OT. Monitoring infrastructure with PRTG leads to proactive fault prevention, if implemented correctly.

When planning to use PRTG it helps to understand how it works.

PRTG consists of the Core Server that runs all the calculations, stores credentials and settings, and provides the GUI together with all graphs. The workload is done by the Probe Server. Every PRTG installation comes with one local probe, running on the same system as the Core Server. The local probe cannot be moved.

When running PRTG for the first time, it will scan the network for IP addresses, find devices, query those devices and create sensors for each reply that it receives. Queries will start with a simple ICMP request (ping). If PRTG receives a reply for this, it will start querying different methods, like WMI, SNMP and other protocols. This way, it can monitor Windows machines with WMI queries, Linux devices with SSH queries and both of them with SNMP (if activated on the target devices).

Queries can run from every 5 seconds up to once a day. Some queries need more resources than others. For example: An SNMP request, using the SNMPv2 protocol, uses way less CPU power than a WMI query or an SNMP query using SNMPv3 protocol (due to encryption).

When deploying many sensors with a high load, the refresh rate is important. The recommendation is to not have more than 200 WMI sensors every 5 minutes. Sure, having them at a shorter interval (e.g. 60 seconds) might work, even for a while. But someday it will fail!

Similar for SNMPv3 sensors. You can deploy several thousands of them with a refresh rate of 60 seconds, if your hardware specifications are alright (at least 8, better 16 CPU cores, lots of RAM (32-64 GB)) and it might run for a while. But it will run into problems if some queries receive the reply just a little bit too late. In those cases, PRTG waits for the answer, while already starting a new query. Those will pile up and PRTG gets stuck.

Planning Your PRTG Setup for Optimal Performance

To avoid these performance issues and ensure your PRTG installation runs smoothly, follow these proven guidelines from Paessler’s technical support team:

Sensor Count Limits

The performance of your PRTG installation depends heavily on the type and quantity of sensors you use. The ultimate guide to boosting… provides these critical thresholds:

One PRTG core server should not exceed 10,000 sensors in total
One PRTG probe device should not exceed around 5,000 sensors
Stay below 50 Netflow sensors and 50 Packet Sniffer sensors per probe device (these have very high performance impact)
Limit Sensor Factory sensors to 50 per core server
Keep WMI-based sensors below 200 per probe device

Scanning Interval Best Practices

Scanning intervals shorter than 30 seconds usually don’t provide more accuracy but cause unnecessary load. The ultimate guide to boosting… recommends:

Sensors with “high” and “very high” performance impact should not use scanning intervals of 60 seconds or less
Use scanning intervals of 300 seconds (5 minutes) or above for resource-intensive sensors
Ensure Sensor Factory sensors have scanning intervals equal to or higher than their source sensors

Deploy Sensors That Make Sense

Beyond technical limits, consider the logical purpose of each sensor when setting scanning intervals. Deploy sensors in a way that matches their actual use case:

Windows Update Status sensors running every 60 seconds make no sense – Windows updates don’t change that frequently. Set these to run once daily or even once a day, as update status typically changes only during maintenance windows.

Certificate expiry sensors checking SSL certificates every minute is wasteful. Certificates don’t expire suddenly – checking once per day or even once per day is perfectly adequate to catch expiring certificates with plenty of advance notice.

Backup job status sensors should align with your backup schedule. If backups run nightly, there’s no point checking the status every 5 minutes during business hours. Set the scanning interval to match when you actually expect status changes.

This approach not only reduces system load but also makes your monitoring data more meaningful and reduces alert fatigue from sensors that change status predictably.

Channel Management

Too many channels within one sensor can lead to performance issues since all channels need to be scanned simultaneously:

Avoid sensors with more than 50 channels
If you need more channels, distribute them across multiple sensors

Hardware Considerations

As your monitoring environment grows, ensure your hardware still meets requirements:

Use dedicated servers for PRTG – don’t run it alongside other applications
When using virtualization (VMware/Hyper-V), keep all CPU cores on one socket
Configure the data directory on local disks, not network drives
Whitelist PRTG in antivirus software and firewalls
For cluster setups, use identical hardware specifications for master and failover nodes

Remote Probe Strategy

When your monitoring requirements exceed single-probe limits, deploy remote probes strategically:

Distribute sensors across multiple probes to balance load
Place probes close to monitored devices to reduce network latency
Monitor probe performance and redistribute sensors if needed

Proactive Monitoring of PRTG Itself

Monitor your PRTG installation’s health:

Watch for increasing response times
Monitor memory and CPU usage on core and probe servers
Set up notifications for probe disconnections
Regularly review sensor error rates

When Performance Issues Occur

If you experience performance problems despite following these guidelines:

Check current sensor counts against the limits above
Review scanning intervals for resource-intensive sensors
Examine hardware utilization (CPU, memory, disk I/O)
Consider redistributing sensors across additional probes
Contact Paessler support with a support bundle for detailed analysis

By following these planning principles from the start, you’ll build a PRTG installation that scales reliably and provides consistent monitoring performance as your infrastructure grows. Remember: exceeding one recommendation might not cause immediate issues, but exceeding multiple recommendations will likely push your PRTG installation to its performance limits.