PRTG Manual: System Requirements

Hardware

We recommend that you use x64 server hardware or a properly configured virtual environment.

Operating system

We recommend that you use Microsoft Windows Server 2022, Microsoft Windows Server 2019, Microsoft Windows Server 2016, or Microsoft Windows Server 2012 R2.

Microsoft .NET Framework

It is required that .NET 4.7.2 or later of the Microsoft .NET Framework is installed on the PRTG core server system or the remote probe system. For new installations of the PRTG core server or remote probes, we recommend .NET Framework 4.8.

For more information, see the Knowledge Base: Which .NET version does PRTG require?

Web browser

The following browsers are officially supported by the PRTG web interface (in order of performance and reliability):

• Google Chrome 72
• Mozilla Firefox 65
• Microsoft Internet Explorer 11

For security and performance reasons, we strongly recommend that you always use the latest version of Google Chrome to access the PRTG web interface.

Hardware

We recommend that you use compatible x86 hardware or a properly configured virtual environment.

Operating system

We recommend that you use Microsoft Windows Server 2022, Microsoft Windows Server 2019, Microsoft Windows Server 2016, Microsoft Windows Server 2012 R2, or Microsoft Windows 10.

Microsoft .NET Framework

It is required that .NET 4.7.2 or later of the Microsoft .NET Framework is installed on the PRTG core server system or the remote probe system. For new installations of the PRTG core server or remote probes, we recommend .NET Framework 4.8.

For more information, see the Knowledge Base: Which .NET version does PRTG require?

Stable network connection

Remote probes require a stable network connection between the PRTG core server and the remote probe. Remote probes that connect to a PRTG Hosted Monitor instance need a reliable internet connection. Unstable connections, for example via 3G, might work but you might lose monitoring data if the connection is unreliable.

Hardware resources

For a PRTG core server to work properly, it is crucial to have a certain amount of hardware resources available. If the server runs out of resources, PRTG sends warning and emergency messages to the primary email address of the PRTG System Administrator user.

You receive warning messages if the available disk space falls below 1 GB or if the available memory falls below 500 MB, and emergency messages if the available disk space or memory fall below 50 MB. In this case, react immediately and free up system resources.

Sensors

Ping and SNMP sensors create much less load than complex sensors like flow sensors, VMware sensors, Sensor Factory sensors, WMI sensors. or Syslog Receiver or SNMP Trap Receiver sensors, for example.

There are also limitations for some sensors that do not depend on hardware resources, for example, WMI and SNMP v3 sensors. You can overcome these limitations if you distribute the sensors between remote probes.

For clusters, we recommend that you stay below 2,500 sensors per cluster.

Channels

We recommend that you use sensors with less than 50 channels. Note that sensors with more than 50 channels are not officially supported. PRTG will try to display all channels but it will limit usability and have a high impact on system performance.

Scanning interval

For a single PRTG core server setup without a cluster, we recommend that you mainly use 1-minute scanning intervals for up to 2,000 sensors and 5-minute intervals if you have more sensors.

To give you an impression: To monitor 5,000 sensors with a 1-minute scanning interval, PRTG takes 7.2 million measurements and evaluates, notifies, and stores them. This adds 700 MB of additional data to the database every single day.

CPU-intensive features

Try to limit the use of the following features:

• Many quickly refreshed maps,
• The frequent generation of huge reports,
• Heavy usage of packet sniffing, Sensor Factory sensors, and Toplists,
• Frequent automatically scheduled auto-discoveries for large network segments, and
• Constant queries of monitoring data via the PRTG API.

Network connection quality

The quality of your network also plays an important role. When you monitor via User Datagram Protocol (UDP), for example, a high packet loss rate can lead to frequent timeouts. Remote probes that connect via unstable (WAN) connections can lead to delays as well.

Supported operating systems

The 32-bit and 64-bit versions of the following operating systems are officially supported for the PRTG core server service and PRTG probe service:

• Microsoft Windows Server 2022*
• Microsoft Windows Server 2019*
• Microsoft Windows Server 2016*
• Microsoft Windows Server 2012 R2*
• Microsoft Windows Server 2012*
• Microsoft Windows 11
• Microsoft Windows 10

* Windows servers in Core mode or Minimal Server Interface are not officially supported.

Operating system version

The version (32-bit or 64-bit) of the PRTG core server depends on the version of your operating system.

Microsoft .NET Framework

It is required that .NET 4.7.2 or later of the Microsoft .NET Framework is installed on the PRTG core server system or the remote probe system. For new installations of the PRTG core server or remote probes, we recommend .NET Framework 4.8.

For more information, see the Knowledge Base: Which .NET version does PRTG require?

The .NET framework is imperative if you want to monitor VMware and XenServer virtual environments. Many other sensors also need an installed Microsoft .NET Framework.

Disabled FIPS mode

Make sure that the Federal Information Processing Standards (FIPS) mode (Windows security option "System Cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing.") is disabled on Windows systems that run the PRTG core server service or PRTG probe service. FIPS-compliant encryption can cause issues with sensors that use the .NET framework.

For more information, see the Knowledge Base: What security features does PRTG include?

Up to 500

4

4 GB

100 GB

< 30

< 30

Up to 1,000

6

6 GB

500 GB

< 30

< 30

Up to 2,500

8

8 GB

750 GB

< 20

< 60

Up to 5,000

8

12 GB

1,000 GB

< 20

< 60

Up to 10,000

10 - 12

16 GB

1,500 GB

< 15

< 80

> 10,000

We recommend that you set up additional PRTG core servers. For more information on scaling, you can also contact the Paessler Presales team.

Up to 200

2

2 GB

40 GB

200 - 2,000

4

4 GB

40 GB

2,000 - 5,000

6

6 GB

40 GB

> 5,000

We recommend that you set up additional remote probes. For more information on scaling, you can also contact the Paessler Presales team.

SNMP v1 and v2, Ping, Port, and HTTP

We recommend that you use these sensor types for scenarios with thousands of sensors.

SNMP v3

SNMP v3 has performance limitations because of the use of encryption. Furthermore, keep in mind that SNMP v3, unlike SNMP v1 and v2c, does not scale with more CPU power. Because of this limitation, PRTG can only handle a limited number of requests per second so that you can use only a limited number of sensors using SNMP v3.

WMI

Try to keep the number of WMI sensors per probe below 120 sensors (with a 60-second scanning interval), or below 600 sensors (with a 300-second scanning interval).

Flow

The maximum number of flow sensors depends on the traffic pattern, the number of flow packets per second that the probe receives, as well as the performance of the probe system.

Packet Sniffer

This sensor type creates the highest CPU load on the probe system. We only recommend this technology for monitoring low traffic connections (< 50 Mbit/s steady stream). If the traffic often exceeds 10 Mbit/s, use a dedicated remote probe.

VMware monitoring

Monitoring VMware is limited to about 30 sensors at a 60-second scanning interval, or 100 sensors at a 5-minute scanning interval. On probes that run on at least Windows Server 2012 R2, you can use more VMware sensors. These limitations issue from the VMware platform.

For more information, see the Knowledge Base: How can I increase the connection limit on VMware systems? PE121

Mozilla Firefox

Mozilla Firefox is potentially vulnerable to cross-site scripting (XSS) attacks. These XSS exploits are possible if you click, for example, phishing links in emails that contain malicious code, and you are logged in to PRTG with Mozilla Firefox.

For more information, see the Knowledge Base: How secure is it to access the PRTG web interface with Firefox?

Microsoft Internet Explorer 11 and unsupported browsers

• Microsoft Internet Explorer 11 and older versions of Microsoft Edge, as well as other browsers that are not officially supported, have issues with some functionalities of the PRTG web interface. However, you can access the PRTG web interface with any browser.
• Deprecated Internet Explorer versions as well as some mobile browsers might not be able to display all features of the PRTG web interface.

Plugins

Plugins can also have an effect when you view the PRTG web interface. Make sure that you add exceptions for PRTG in the plugins' settings, particularly if you use ad blockers.

For more information, see the Knowledge Base: The logs page in the PRTG web interface does not load. What can I do?

SNMP monitoring

The target devices must support SNMP v1, v2c, or v3. An SNMP-compatible software must be installed on the device. You must enable SNMP on the device and you must grant the PRTG core server system access to the SNMP interface.

For more information, see section Monitoring via SNMP.

Windows/WMI monitoring

To monitor via WMI, you need a Windows network. Use only the officially supported operating systems except for Microsoft Windows Server 2008 that has strong performance issues when you monitor via WMI.

For more information, see section Monitoring via WMI.

Flow monitoring

The target devices must be able to send NetFlow (NetFlow v5, NetFlow v9, or IPFIX) data packets or sFlow v5 packets to the probe system.

For more information, see section Monitoring Bandwidth via Flows.

Packet sniffer monitoring

PRTG can only analyze data packets that pass the network card of the local machine. Switches with monitoring ports are necessary for network-wide monitoring in switched networks.

For more information, see section Monitoring Bandwidth via Packet Sniffing.

Other sensor types

You can find specific sensor and device requirements (for example, modules, components, device configurations) in the corresponding sensor section and in the Add Sensor dialog.