PRTG Manual: Introduction: Monitoring with PRTG
This section provides an overview of basic principles of PRTG. It shows you how to prepare your IT infrastructure for monitoring with PRTG. You do not have to re-configure your whole network for PRTG, but there are several topics that are useful to consider before you actually use PRTG.
In this section:
- What PRTG Does
- Where to Install PRTG
- 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
You can also see section Quick Start Guide to immediately start monitoring.
However, you do not immediately have full access to all relevant information unless your network is completely ready for monitoring. PRTG needs credentials to access devices in your network. During the PRTG on premises install process, PRTG automatically adds devices with some default sensors, such as the Ping sensor. But it only adds devices and sensors where no credentials are needed or where certain technologies are needed. For PRTG hosted by Paessler, you first need to install a remote probe in your LAN to monitor your network.
PRTG is a unified monitoring tool with which you can monitor almost any object with an IP address. PRTG consists of the PRTG core server that is responsible, for example, for the configuration, data management, and web server, and one or more probes that perform data collection and monitoring 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. For example:
- Interface throughput
- Bandwidth usage
- Loading times
- Hardware status
- Resource consumption
- User counts
- Record counts
- Log events
- Database requests
For best performance, we always recommend that you install PRTG on premises on a physical machine. A PC or server with at least a dual core CPU and 2048 MB RAM suffices for most average installations. PRTG can also run on a virtual machine (VM), but we have a recommended limit on the number of sensors because of the hypervisor overhead.
For remote sites and to distribute load, you can use remote probes. Remote probes have a data collector with a smaller footprint, which minimizes the performance impact. At least one remote probe is required for PRTG hosted by Paessler to monitor your local network.
PRTG hosted by Paessler does not require any hardware for the PRTG core server, but at least one remote probe installation is necessary to monitor your local network when you use PRTG hosted by Paessler.
PRTG uses the following ways to receive monitoring data from target devices:
- Poll or query sensor data: PRTG actively obtains data from a device and refreshes it 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.
- Listen for or receive sensor data: PRTG passively receives data that is pushed to PRTG by 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 200 different sensors that range from platform-specific sensors to generic hardware and bandwidth sensors to custom scripts. It also comes with preconfigured sensors for common configurations. Add these sensors to the target devices that they are designed for to immediately receive monitoring data.
Additionally, you can add custom sensors in PRTG. For example, you can create individual sensors for devices for which PRTG does not provide native sensors, or you can write scripts that return data from applications. See also the PRTG Sensor Hub for ready-to-use custom sensors.
Best practice for taking 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.
When you plan what you want to monitor, we recommend that you add the most important devices within your infrastructure first. Start with the core network and other infrastructure that all network devices depend upon, your Business Critical Tier-1. This usually includes key infrastructure such as core routers, switches, VPN, firewalls, and basic network services such as the Dynamic Host Configuration Protocol (DHCP), the Domain Name System (DNS), and authentication like the Lightweight Directory Access Protocol (LDAP).
There is a huge number of different vendors with a lot of different hardware devices, so hardware details go beyond the scope of this article. Every IT infrastructure is individual, but here are the main points you should consider.
- Core infrastructure
- Routers, switches, firewalls
- Core network services: DNS, Active Directory, 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 xFlow (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)
PRTG monitors, tracks, and charts data, as well as generates alarms.
Many of the sensors included in PRTG rely on access through logins to specific systems. You need different credentials with sufficient permission for all the different 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 track xFlows.
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, 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 do not usually have to reenter credentials, depending on the used monitoring technology.
This section briefly describes the most common monitoring technologies.
For more information, see section Sensor Technologies.
Simple Network Management Protocol (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 monitor important issues 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 like SNMP version and community string. To find out how to set up SNMP on a specific device, search the internet for your device name or model and SNMP configuration.
When you use a sensor with this technology, PRTG sends small data packets to devices, for example, querying routers, switches, and servers for the traffic counters of each port. These queries trigger reply packets from the device. 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 Simple Network Management Protocol (SNMP) protocol: version 1, version 2c, and version 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. Version 1 only supports 32-bit counters, which are not enough for high-load (gigabits/second) bandwidth monitoring.
This version adds 64-bit counters.
- Pro: Supports 64-bit counters to monitor bandwidth usage in networks with gigabits/second loads.
- Con: Limited security (same as with SNMP v1).
This version adds authentication and encryption to SNMP.
- Pro: Offers user accounts and authentication for multiple users and optional data packet encryption to increase the available security, and has all advantages of Version 2c in addition.
- Con: Difficult to configure and higher overhead for the probe, which reduces the number of devices that you can monitor (see here 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 of the probe system to which you add the SNMP Trap Receiver sensor.
Which SNMP Version Should I Choose?
The SNMP version you should choose 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, security and encryption add 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.
- From the perspective of monitoring with PRTG, SNMP v2c is preferable if you have a lot of devices to monitor. This lets you monitor more devices with a shorter scanning interval, and it supports 64-bit counters.
The most important aspect is to set the same SNMP version in the PRTG settings (for example, in the root group settings) as you have configured in your target device. If you select an SNMP version that is not supported by the server or device that you want to monitor, you receive an error message. Unfortunately, these error messages, in most cases, do not explicitly point to the possibility that you are using the incorrect SNMP version. These messages provide minimum information only, such as cannot connect. Similar errors occur when community strings, usernames, 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 this technology to access data of various Windows configuration parameters and status values. However, sensors using 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 often causes issues.
If you run into issues, 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. From a performance perspective, the preference is SNMP, then WMI or performance counters.
Using xFlow (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.
PRTG provides the option to monitor passively received data. For this purpose, you can set up a device in a way that it automatically sends the data to PRTG. Specific sensors can receive this data and alert you based on your individual settings. For example, all Linux/Unix and most network devices support remote devices generating data that has to be configured on each device, and sending the messages to a probe system. Usually, only the destination IP and port are required.
For more information, see the 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. HTTP 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 thresholds or on sensor states) and how you want to receive notifications from PRTG. The most common methods are email, SMS text message, and push notifications to your smartphone that runs a PRTG app for iOS or Android.
For your critical infrastructure it is best practice to set up two redundant notifications with different delivery methods (for example, email and SMS via a gateway).
For more information about notifications, see the video tutorial: Notifications.
The most common notification method is to send emails with the SMTP server built into PRTG. This means that no SMTP server setup or configuration is required, but if you want to deliver emails through your email server, you have to configure it in the SMTP settings.
PRTG on premises can also notify you on your mobile phone. To deliver SMS notifications, you can 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 (look in your provider's documentation 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 according 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
Welcome to PRTG