PRTG Manual: Introduction: Monitoring with PRTG
This section shows you how to prepare your IT infrastructure so that you can monitor it with PRTG.
In this section:
- What PRTG Does
- How to Monitor with PRTG
- What PRTG Monitors
- How to Prepare Monitoring
- Which Hardware Do I Want to Monitor
- Types of Logins and Credentials
- Monitoring Technologies
- Notifications from PRTG
To immediately start monitoring with PRTG, go to section Quick Start Guide.
PRTG is a unified monitoring tool that can monitor almost any object that has an IP address. It consists of the PRTG core server and one or more probes:
- The PRTG core server is responsible for configuration, data management, PRTG web server, and more.
- Probes collect data and monitor processes on devices via sensors.
Sensors are the building blocks of PRTG. A sensor can tell you about one or more aspects of a device:
- Interface throughput
- Bandwidth usage
- Loading times
- Hardware status
- Resource consumption
- User counts
- Record counts
- Log events
- Database requests
PRTG obtains monitoring data from target devices in the following ways:
- Polls or queries sensor data: PRTG actively gathers data from a device in regular intervals. This includes, for example, device status, resource usage, and performance metrics. Most sensors use this method. PRTG can also consume and collect sensor data based on interfaces with, for example, HTTP or HTTPS requests, port checks, email checks, File Transfer Protocol (FTP) downloads, and database requests.
- Listens for or receives sensor data: PRTG passively receives data from a device or application. This includes, for example, unexpected events, Syslogs and Simple Network Management Protocol (SNMP) traps, detailed data flow (bandwidth monitoring), and event log messages.
Most of the monitoring data that PRTG collects is actively queried. It is the basis for statistical sampling to see how a device or application performs over time.
For more information, see section Monitoring Technologies.
PRTG comes with more than 250 different sensors.They range from platform-specific sensors to generic hardware and bandwidth sensors. Some of them are preconfigured to immediately gather monitoring data from their target devices. You can also create custom sensors or write custom scripts that return data from applications. Visit the PRTG Sensor Hub to learn more about ready-to-use custom sensors.
The first step in comprehensive monitoring is to make a plan. Think about the following questions:
- What do I need to monitor in my IT infrastructure?
- How can I retrieve the needed information? Which technologies and credentials are required?
- Which notification methods do I want to use to receive alerts if something is wrong?
You can use the following sections as a basis for your monitoring plan.
Which Hardware Do I Want to Monitor?
We recommend that you start with your Business Critical Tier-1: the core network and other infrastructure that all network devices depend upon. This usually includes:
- Key infrastructure, such as core routers, switches, VPN and firewalls
- Basic network services, such as Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS)
- Authentication, like Lightweight Directory Access Protocol (LDAP)
Use the following list to help you plan the monitoring of your IT infrastructure with PRTG:
- Core infrastructure
- Routers, switches, firewalls
- Core network services: DNS, Active Directory (AD), LDAP servers
- For your hardware devices, you need statistics on availability, usage, and performance.
- PRTG retrieves data via standard protocols:
- Ping, SNMP; web queries via HTTP and HTTPS; email via Post Office Protocol version 3 (POP3), Internet Message Access Protocol (IMAP), Simple Mail Transfer Protocol (SMTP)
- Hardware parameters via SNMP, Secure Shell (SSH), Simple Object Access Protocol (SOAP)
- Bandwidth usage via Flow (NetFlow, jFlow, sFlow, IPFIX), packet sniffing, SNMP
- Windows systems via Windows Management Instrumentation (WMI)
- Other interfaces via SSH and scripts (for example, PowerShell and Python)
Types of Logins and Credentials
Many of the sensors included in PRTG rely on access through logins to specific systems. You need different credentials with sufficient permission for all of your devices, operating systems, and domains. The configuration might also be different if you want PRTG to act as a Syslog or SNMP trap receiver or to use it for flow-based monitoring.
In most cases, PRTG uses the following credential types to access the devices that you want to monitor:
- SNMP credentials
- Windows credentials (WMI)
- Linux, Solaris, and macOS credentials (SSH/Web-based Enterprise Management (WBEM))
- VMware and XenServer credentials
- Database management system (DBMS) credentials
- Other credentials (for example, Amazon Web Services (AWS) keys, HTTP proxy)
Define your (administrative) credentials for all types of target devices that you want to monitor in the root group of the device tree. Devices that you add to PRTG automatically inherit these credentials, so you usually do not need to reenter credentials.
This section briefly describes the most common monitoring technologies.
For more information, see section Sensor Technologies.
Monitoring with Simple Network Management Protocol (SNMP)
SNMP is a set of standards for communication with devices in a Transmission Control Protocol (TCP)/IP network. SNMP monitoring is useful if you are responsible for servers and network devices such as hosts, routers, hubs, and switches. It enables you to keep an eye on network and bandwidth usage, and to monitor important metrics such as uptime and traffic levels.
You can use SNMP to monitor the bandwidth usage of routers and switches on a port-by-port basis, as well as device readings such as memory and CPU load. The target devices must support SNMP. Most devices with enabled SNMP require the same configuration (identical SNMP version and community string). To learn how to set up SNMP on a specific device, search the internet for its name and SNMP configuration.
When you use a sensor with this technology, PRTG sends small data packets to a device, which in turn trigger reply packets. Compared to other bandwidth monitoring technologies via World Wide Name (WWN), packet sniffing, or Windows Management Instrumentation (WMI), the SNMP option creates the least CPU and network load.
PRTG supports three versions of the SNMP protocol: version 1, 2c, and 3.
This is the oldest and most basic version of SNMP.
- Pro: Supported by most SNMP-compatible devices.
- Con: Limited security because it only uses a simple password (community string) and sends data in clear text (unencrypted). Because of this, you should only use it inside LANs behind firewalls, but not in WANs. SNMP v1 only supports 32-bit counters, which are not enough for high-load (gigabits/second) bandwidth monitoring.
This version adds 64-bit counters.
- Advantage: Supports 64-bit counters to monitor bandwidth usage in networks with gigabits/second loads.
- Disadvantage: Limited security (see SNMP v1).
This version adds authentication and encryption to SNMP.
- Advantage: Offers user accounts and authentication for multiple users and optional data packet encryption to increase available security. Has all advantages of SNMP v2c.
- Disadvantage: Difficult to configure and higher overhead for the probe, which reduces the number of devices that you can monitor (see SNMP Overload and Limitations of the SNMP System for more information).
Various devices can send SNMP trap messages to notify you of system events.
- PRTG supports SNMP v1 and SNMP v2c traps.
- The destination for SNMP traps is the IP address of the trap receiver, which is the IP address of the probe system to which you add the SNMP Trap Receiver sensor.
Which SNMP Version Should I Choose?
This depends on your environment. Here are some guidelines:
- If your network is publicly accessible, you might want to use SNMP v3, which has encryption and secure access. However, this also adds overhead, which results in less performance.
- If your network is isolated or well-protected behind firewalls, the lower security level of SNMP v1 or SNMP v2c might be sufficient.
- If you have a lot of devices to monitor, SNMP v2c is preferable since it has a shorter scanning interval and supports 64-bit counters.
Make sure to set the same SNMP version in the PRTG settings (for example, in the root group settings) as in the target device. If you select an SNMP version that is not supported by the server or target device, you receive an error message. These error messages often do not explicitly say that you are using the wrong SNMP version and only provide minimum information, such as cannot connect. Similar errors occur when community strings, user names, or passwords do not match.
For more information about basic requirements for SNMP monitoring, see this Knowledge Base article: My SNMP sensors don’t work. What can I do?
You can monitor Windows systems via Windows Management Instrumentation (WMI) and Windows performance counters. WMI is the Microsoft base technology for monitoring and managing Windows-based systems. PRTG uses it to access data of various Windows configuration parameters and status values. Note that sensors that use the WMI protocol generally have a high impact on system performance. In addition to strict WMI sensors, there are sensors that can use performance counters to monitor Windows systems.
To monitor via WMI and performance counters, it is usually sufficient to provide credentials for Windows systems in PRTG. However, monitoring via WMI is not always trivial and can cause issues.
If you run into issues with WMI, see the Knowledge Base: My WMI sensors don't work. What can I do?
It is also possible to use Simple Network Management Protocol (SNMP) for Windows devices. The same information is often available using any of these protocols. Regarding performance, the preference is SNMP, then WMI or performance counters.
Monitoring Bandwidth via Flows
Using Flow (NetFlow, jFlow, sFlow, IPFIX) protocols, you can monitor the bandwidth usage of all packets going through a device. In PRTG, you can view Toplists for all xFlow sensors.
xFlows are monitoring data pushed from network devices to PRTG. You can use them to monitor where and how much data is traveling to and from. This way, they determine which machine, protocol, or user is consuming bandwidth. PRTG supports the following xFlow types:
- NetFlow v5/v9 and IPFIX: Originally introduced by Cisco and supported by several vendors.
- jFlow: Traffic sampling technology introduced by Juniper networks.
- sFlow: Short for sampled flow, introduced by HP. sFlow uses statistical sampling of the traffic at defined intervals to achieve scalability for high volume interfaces.
You can also use packet sniffing for bandwidth monitoring if your hardware does not support any of these xFlow versions.
Monitoring Passively Received Data
PRTG has the option to monitor passively received data. For this purpose, you can set up a device in a way that it automatically sends data to PRTG. Specific sensors can receive this data and alert you based on your individual settings. Usually, only the destination IP address and the port are required.
Examples for this monitoring technology are HTTP Push sensors, as well as Syslog Receiver and SNMP Trap Receiver sensors.
For more information, watch this video tutorial: SNMP Trap receiver and syslog receiver sensors.
HTTP is a standard application layer protocol and the basis for data communication on the internet. It is a request-response method for client-server architectures, where the client sends a request and the server processes and responds to the request.
Monitoring via HTTP is useful if you want to monitor websites or web servers. It enables you to keep an eye on the availability and download times of a website or the performance statistics of a web server. There are also a lot of other possible use cases for HTTP sensors. For example, you can request any application programming interface (API) that is reachable via HTTP and monitor returned values. This approach lets you include almost any type of device or application into your monitoring.
PRTG can notify you in various ways if it detects that there is something wrong in your network. You can individually define when (for example, based on sensor states) and how you want to receive notifications. The most common methods are email, SMS text message, and push notifications to your smartphone that runs the PRTG app for iOS or Android.
For your critical infrastructure, we recommend that you set up two redundant notifications with different delivery methods (for example, email and SMS via a gateway).
For more information about notifications, watch this video tutorial: Notifications.
The most common notification method is to send emails with the PRTG SMTP server. This means that no SMTP server setup or configuration is required. However, if you want to deliver emails through your email server, you must configure it in the SMTP settings.
PRTG Network Monitor can also notify you on your mobile phone. To deliver SMS notifications, select one of the SMS service providers that PRTG includes by default and use it with your credentials for this provider. Of course, you can also use any other service provider if you define a custom URL (search the documentation of your provider for the required format). You can also use an SMS gateway to receive messages even if your internet connection is down.
For a list of third-party tools, see the Knowledge Base: How can I send SMS text message notifications via a modem or a mobile phone with PRTG?
PRTG can send push notifications to your iOS and Android devices when you run the PRTG app on your smartphone.
For more information, see the Knowledge Base: How can I use push notifications with PRTG?
My SNMP sensors don’t work. What can I do?
My WMI sensors don't work. What can I do?
My HTTP sensors don't work. What can I do?
How can I send SMS text message notifications via a modem or a mobile phone with PRTG?
How can I use push notifications with PRTG?
SNMP Trap receiver and syslog receiver sensors