PRTG Manual: Introduction: Monitoring with PRTG
This manual section provides an overview of basic principles of PRTG Network Monitor. It shows you how you can prepare your IT infrastructure for monitoring with PRTG. Of course, you do not have to re-configure your whole network for PRTG, but there are several topics that are useful to consider before actually using PRTG.
You can immediately start monitoring without complicated configuration steps. See the Quick Start Guide for details. If you want to know more details right from the beginning, read through the manual section below. It covers these topics:
- What PRTG Does
- Where to Install PRTG
- How to Monitor
- What can PRTG Monitor
- How to Prepare
- What Hardware Do I Want to Monitor
- Types of Logins and Credentials
- Monitoring Technologies
- Notifications from PRTG
- Advanced Topics
PRTG Network Monitor is a monitoring software that is flexible and easy to use. You can download, install, and configure PRTG on premises or create a PRTG hosted by Paessler instance within minutes and start monitoring right away.
That said, you will not immediately have full access to all relevant information unless your network is completely ready for monitoring—for example, PRTG needs credentials to access devices in your network. During the PRTG on premises install process, PRTG will automatically add devices with some default sensors, such as the Ping sensor. But it will only add devices and sensors where no credentials or certain technologies are needed. For PRTG hosted by Paessler, you will need to install a remote probe in your LAN first to monitor your network.
PRTG is a Unified Monitoring Tool that allows you to monitor pretty much anything with an IP address. PRTG consists of a core server which is responsible, for example, for the configuration, data management, and web server, and one or more probes (local or hosted, remote), which perform data collection and monitoring processes on devices via sensors.
- Interface throughput
- Bandwidth usage (for example, flows)
- Loading times
- Hardware status
- Resource consumption
- User counts
- Record counts
- Log events
- Database requests
For best performance, we will always recommend that you install PRTG on premises on a physical machine. Any current PC or server with at least a dual core CPU and 2048 MB RAM will suffice for most average installations. PRTG can also run on a virtual machine (VM), but we have a recommended limit on the number of sensors due to the hypervisor overhead.
For remote sites and for offloading work, you can use the PRTG Remote Probe. Remote probes offer a smaller footprint data collector that reports back to the PRTG core server and so helps minimize performance impacts. 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 server, but at least one remote probe installation is necessary to monitor your local network when using PRTG hosted by Paessler.
There are the following ways for PRTG to receive monitoring data from target devices:
- Polling or querying 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 sensor types use this method. PRTG can also consume and collect sensor data based on interface with, for example, HTTP(S) requests, port checks, email checks, FTP downloads, and database requests.
- Listening or receiving sensor data: PRTG passively receives data that is pushed to PRTG by a device or application. This includes, for example, unexpected events, Syslogs and 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 is performing over time. For more information, see section Monitoring Technologies below.
Out of the box, PRTG comes with more than 200 different sensor types ranging from specific platform sensors over generic hardware and bandwidth sensors to custom scripts. Specific sensors that are pre-configured for common configurations allow you to quickly gather the information you need. Just add these sensors to the target devices they are designed for and receive monitoring data instantly.
Additionally, PRTG provides the possibility to add custom sensors. For example, you can create individual sensors for devices that PRTG does not provide sensor types for out of the box, or write scripts that return data from some application. See also the PRTG Script World for custom sensors that are ready to use.
Best practice for the first step in good monitoring is to make a plan. Think about the following questions.
- What needs to be monitored 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 get alerted if there is something wrong?
You can take the following sections as a basis for your monitoring planning.
When choosing what 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, Virtual Private Network (VPN), firewalls, and basic network services such as Dynamic Host Configuration Protocol (DHCP), Domain Name Service (DNS), and authentication like Lightweight Directory Access Protocol (LDAP).
As an example, if you are a web business, your web infrastructure is absolutely critical. You will want to add devices in order of importance to your business: file services, databases, and other systems. Usually, you would monitor devices from several perspectives, like hardware health, service availability, and performance.
See also our video tutorial on webserver monitoring.
There is a huge number of different vendors with uncountable variations of 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 will retrieve data using standard protocols:
- Ping, Simple Network Management Protocol (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, SSH, Simple Object Access Protocol (SOAP)
- Bandwidth usage via xFlow (NetFlow, IPFIX, sFlow, jFlow), packet sniffing, SNMP
- Windows systems via Windows Management Instrumentation (WMI)
- Other interfaces via Secure Shell (SSH) and scripts (for example, PowerShell and Python)
PRTG will monitor, track, and chart data, as well as generate alarms.
Many of the sensors included in PRTG rely on access through logins to specific systems. You will need different credentials with sufficient permission for all the different devices, operating systems, and domains. The configuration may also be different if you want PRTG to act as a Syslog or SNMP trap receiver or for tracking flows.
In most cases, PRTG will use the following credential types to access the devices that you want to monitor.
- SNMP credentials
- Windows credentials (WMI)
- Linux, Solaris, and macOS credentials (SSH/WBEM)
- VMware and XenServer credentials
- Database Management Systems (DBMS) credentials
- Other credentials (for example, Amazon CloudWatch 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 will inherit these automatically, so often you will not have to re-enter credentials, depending on the used monitoring technology.
This section briefly describes the most common monitoring technologies.
For details, see section Sensor Technologies.
SNMP is a set of standards for communication with devices in a 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 in the internet for your device name or model and SNMP configuration. You will likely get plenty of information on how to configure SNMP.
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 flows, packet sniffing, or WMI, the SNMP option creates the least CPU and network load.
PRTG supports three versions of the SNMP protocol: Version 1, version 2c, and version 3.
SNMP Version 1
This is the oldest and most basic version of SNMP.
- Pro: Supported by most SNMP-compatible devices; simple to set up.
- 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.
SNMP Version 2c
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).
SNMP Version 3
This version adds authentication and encryption to SNMP.
- Pro: Offers user accounts and authentication for multiple users and optional data packet encryption, increasing available security; plus all advantages of Version 2c.
- Con: Difficult to configure and higher overhead for the probe, which will reduce 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.
- Destination for SNMP traps: IP address of the trap receiver, which is the IP of the PRTG probe system (server with either a local or remote probe running on it) to which you add the SNMP Trap Receiver sensor.
Which SNMP Version Should I Choose?
The SNMP version to choose depends on your environment, but as a guideline:
- If your network is publicly accessible, you may want to use SNMP v3, which has encryption and secure access. However, security and encryption adds overhead, which results in less performance.
- If your network is isolated or well-protected behind firewalls, the lower security of SNMP v1 or SNMP v2c may be sufficient.
- From the PRTG perspective, if you have a lot of devices to monitor, SNMP v2c is preferable. It will allow you to monitor more devices on a shorter monitoring interval and supports 64-bit counters.
The most important thing is to set the same SNMP version in the PRTG settings (for example, on Root level) as you have configured in your target device. If you select an SNMP version that is not supported by the server or device you want to monitor, you receive an error message. Unfortunately, in most cases, these error messages 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 or similar. Similar errors occur when community strings, usernames, or passwords do not match.
For basic requirements for SNMP monitoring, see the Knowledge Base: 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.
See this article in our Knowledge Base if you run into issues: 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 would be SNMP, and then WMI or Performance Counters.
Using flow protocols, you can monitor the bandwidth usage of all packets going through a device. In PRTG, you can view Toplists for all xFlow (NetFlow, IPFIX, sFlow, jFlow) sensors.
Flows are a type of monitoring data pushed from network devices to PRTG. You can use it to monitor where data is traveling to and from, and how much. This way it determines which machine, protocol, and user is consuming bandwidth. PRTG currently supports the following flow 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 flow 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 sensor types can receive this data and alarm 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 PRTG probe system. Usually, only the destination IP and port are required.
The Hypertext Transfer Protocol (HTTP) is a standard application layer protocol and the basis for data communication in 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 makes it possible to 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 in which case (for example, based on thresholds or on sensor states) and how you want to receive notifications from PRTG. The most common methods would be email, SMS text message, and push notifications to your smartphone which runs a PRTG mobile app.
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).
The most common notification method is to send emails using a Simple Mail Transfer Protocol (SMTP) server built-in in PRTG. This means no SMTP server setup or configuration is required, but if you want to deliver through your email server, you will have to configure it in the PRTG SMTP settings.
SMS Text Notifications
PRTG on premises can also notify you on your mobile phone. To deliver SMS text 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 by defining 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-pary 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 iOS and Android when you run the according PRTG mobile app on your smartphone.
For more details, see the Knowledge Base: How can I use push notifications with PRTG?
So, now that you are ready for monitoring with PRTG, enjoy having all important information about your IT infrastructure available at a glance. To dive deeper into network monitoring with PRTG we entrust you to have a look at our video tutorials for advanced topics. Of course, you will also find all relevant information about network monitoring in the PRTG User Manual.
Video Tutorials: PRTG Basics
Video Tutorial: Webserver Monitoring
Video Tutorial: SNMP Trap Receiver
Video Tutorial: Syslog Receiver
Video Tutorial: PRTG – Notifications
Video Tutorial: Use Cases for PRTG Notifications
Knowledge Base: My SNMP sensors don't work. What can I do?
Knowledge Base: My WMI sensors don't work. What can I do?
Knowledge Base: How can I send SMS text message notifications via a modem or a mobile phone with PRTG?
Knowledge Base: How can I use push notifications with PRTG?
- Welcome to PRTG Network Monitor
- About this Document
- Key Features
- New in This Version
- Available Licenses
- System Requirements
- Detailed System Requirements
- Introduction: Monitoring with PRTG