PRTG Manual: Glossary
This section explains special words used in the context of PRTG Network Monitor.
These are only explanations. For information on where to find detailed instructions for a specific key word, see the Index section.
The auto-discovery process scans your network for devices using Ping (for groups only), it assesses the device type for all discovered devices, and it creates sensor sets that match the discovered device types based on built-in templates or your custom device templates.
The monitoring data of a sensor is shown in sensor channels. For example, for sensors that measure network traffic, there is one channel each for traffic in, traffic out, and traffic total. You can set various triggers for each channel, so you can define sensor status changes or notifications based on the monitoring data received.
You can configure PRTG as a failover cluster for fail-safe monitoring. In a cluster, one or more core servers work together in one configuration. Every node can monitor every device in a network for fail-safe monitoring, so you can additionally compare monitoring results measured from different perspectives. This feature is not available in PRTG hosted by Paessler.
Sometimes used as synonym for Node.
When running PRTG in cluster mode, a cluster probe is automatically created. All objects created on the cluster probe or below in the device tree are monitored by all nodes in the cluster. Create or move objects there for fail-safe monitoring. If one node fails, the other nodes continue to monitor them. You can add groups and devices to the cluster probe. On a PRTG installation, the cluster probe runs as part of this installation's local probe. Your remote probes can send monitoring data to your cluster nodes so you can view the data of each probe on each cluster node.
This is the central unit of PRTG. It receives monitoring data from the probes and handles reporting and notifications, provides the web server for the user interfaces, and much more. In a cluster, one core server is installed on every node. The core server is configured as a Windows service that is permanently run by the Windows system without requiring a user that is logged in.
In the Home menu of the web interface, several preconfigured dashboards are available that provide an overview of the overall status of your monitoring configuration. You can create custom dashboards using the Maps function.
A device in PRTG represents a real physical device in your network. For a clear tree structure, you usually create one PRTG device for each physical device that you want to monitor (exceptions apply to some sensors that you can only create on the local probe device, and for sensor types that are not bound to a certain device, such as HTTP sensors, which are also usually created on the local probe). You can add one or more sensors on every device.
If you want to add a certain device several times, you can create a device template from an existing device in your device tree. When creating a device template, PRTG saves information for nearly all sensors on this device to a template file that you can later use in combination with Auto-Discovery (restrictions apply for a few sensor types).
The configuration of PRTG is represented in a hierarchical tree structure, the device tree, containing all objects. While building the tree, you can relate to your network's topology to make your monitoring setup easy to understand.
Geo Maps show the different locations of your devices on a map, depending on the location data that you provide in the settings of probes, groups, or devices. The tiles on the maps that represent your devices also show the overall status of a location. This is useful for monitoring distributed networks.
A group is an organizational unit in your PRTG tree structure that helps to arrange your devices. You can add devices or additional subgroups to existing groups. This way, you can model your physical network's topology within the PRTG configuration. You can use groups to arrange similar objects so that they inherit the same settings.
The hosted probe relates to PRTG hosted by Paessler like the local probe relates to PRTG on premises. When creating a PRTG hosted by Paessler instance, the system automatically adds the hosted probe. The hosted probe is always running on the PRTG core server system that we host for you and shows monitoring values of your PRTG instance hosted by Paessler. You can use the hosted probe to monitor devices, servers, and services that are publicly available in the internet like, for example, websites. To monitor your LAN, you need at least one remote probe installation in your network. The local probe is not available in PRTG hosted by Paessler.
Libraries are a way to show parts of your device tree in a different layout or with different filters enabled. An editor is available that lets you create libraries directly in your browser.
Libraries use library nodes to reference objects in your monitoring setup. Library nodes can show a subtree of the device tree in the library or they can show a collection of filtered sensors in the library.
When installing PRTG on premises, the PRTG local probe is installed together with the PRTG core server. All objects created on the local probe, or below it in the device tree, are monitored by the local core system. You can add groups and devices to the probe. If you use PRTG hosted by Paessler, the hosted probe replaces the local probe. There are some differences between PRTG hosted by Paessler and PRTG on premises.
PRTG uses lookups for some sensor types and for some sensors with custom channels. In general, lookups make map status values as returned by a device (usually integers) to more informative expressions in words.
Maps (sometimes referred to as dashboards) are a way to present monitoring data the way you want to arrange it. An editor is available that lets you create maps directly in your browser. Using maps, you can also make your overview pages of live data publicly available.
In a cluster, the master node controls the settings and cluster management. It also takes over notifications. All changes to the monitoring configuration are made on the master node, which distributes the changes among all other nodes in real time.
Sensors that use the meta-scan function, for example SNMP sensors, first look at the device to find what can be monitored. This can be tables, object identifiers (OID), or disks, for example. When the meta-scan is done, the second step of the Add Sensor dialog shows you the parameters that you can monitor. Some sensors require basic information before they can perform a meta-scan. Provide the requested information, such as credentials, in the appearing window. PRTG then scans and recognizes all parameters available for monitoring based on your input.
In a cluster, there is one master node and one or more failover nodes. On each node, one PRTG core server installation runs independently. All nodes are connected to each other, exchanging configuration and monitoring data.
PRTG uses notifications to send you alerts whenever PRTG discovers a defined status, such as slow or failing sensors, or when sensor channels breach threshold values. You can define an unlimited number of notifications. You can use one or more of several communication channels like email, text messaging, push notifications to Android and iOS devices, and many more.
All objects are arranged in a hierarchical order that makes it easier to navigate and arrange settings. The object hierarchy is used to define common settings for groups of objects.
The object selector enables you to browse all objects in your configuration and select an object in two steps. The left-hand side shows your device tree. If you have selected a device, the right-hand side shows the sensors on the device.
The primary master node in a cluster is the node that is master by configuration. Only if it fails, one of the failover nodes becomes failover master and takes over the master role until the primary master node rejoins the cluster.
The PRTG Administration Tool is part of your PRTG installation and helps you to edit the administrative settings of your local probe and your remote probe installations. You can launch the PRTG Administration Tool from the Windows start menu on your core server or on your remote probe server.
The PRTG application programming interface (API) enables you to access monitoring data and manipulate objects using HTTP requests, run your own written sensors and notifications, and implement Mini Probes.
PRTG Desktop is an alternative interface that you can use to connect to the PRTG core server or a PRTG hosted by Paessler instance to configure your setup, view monitoring results, and keep an eye on your network. It is a cross-platform application for fast access to data and monitoring management.
PRTG hosted by Paessler is the PRTG cloud solution where we at Paessler run the core server and hosted probe for you. No core server installation inside your network is necessary. The PRTG web interface for monitoring configuration and reviewing monitoring data is the same for both PRTG hosted by Paessler and PRTG on premises.
PRTG on premises is a network monitoring application for Windows-based systems with which you can monitor your entire network. A core server installation inside your network is necessary. The PRTG web interface for monitoring configuration and reviewing monitoring data is the same for both PRTG on premises and PRTG hosted by Paessler.
With the sensor recommendation engine, PRTG can analyze devices in your network and suggest sensors that are still missing for a complete monitoring. The analysis runs with low priority in the background when you add a new device, when the last analysis was executed more than 30 days ago, or when you manually start it.
PRTG updates are delivered in different release channels. With PRTG on premises, you can choose between maximum stability (Stable), or most early access to new features (Canary or Preview). PRTG hosted by Paessler does not have release channels. Instead, we roll out the latest stable version to PRTG hosted by Paessler instances in stages, so your instance automatically updates to the latest stable version.
A remote probe is a small piece of software installed on a computer in the local or remote network. It scans the network from there and sends monitoring results to the core server. Once the connection is established, the remote probe is shown in the PRTG tree structure. All objects created on the remote probe, or below it in the device tree, are monitored by the remote system running the remote probe. You can add groups and devices to the probe. In a cluster, remote probes can connect to all cluster nodes so you can view monitoring data of a probe on all nodes.
You can use schedules to pause monitoring/notification for certain time periods or at certain times. You can also use schedules to define the time periods that are to be covered when creating reports.
A sensor monitors one aspect of a device. For example, monitoring if a device responds to a Ping request is done by one sensor. Monitoring the traffic of one Ethernet port of a router device is done by another sensor. For monitoring the CPU load of the local system yet another sensor is set up, and so on. The data of sensors is shown in their respective channels. Each sensor has at least one channel.
The color of a sensor always shows its current status. There are 8 different sensor states: Down, Down (Partial), Down (Acknowledged), Warning, Unusual, Up, Paused, and Unknown.
Sometimes used as synonym for device tree.
Similar sensors detection enables PRTG to analyze sensor data for similarities. The detection runs in the background with low priority. The recommended setting for similar sensors detection is to let PRTG automatically decide how many channels are analyzed.
Tickets are created by the system or a PRTG user and contain important messages or action steps for the administrator or another specific user to take. Every ticket should be viewed to take appropriate action. You can access the list of tickets from the main menu.
Packet Sniffer and xFlow (NetFlow, jFlow, sFlow, IPFIX) sensor types can break down the traffic by IP address, port, protocol, and other parameters. The results are shown in graphs that are known as Toplists.
PRTG sends a notification when a defined event evokes it. These events are known as triggers. The following events can trigger notifications: sensor status changes, sensor value threshold breaches, speed threshold breaches, volume threshold breaches, and sensor value changes.
The unusual detection can set sensors to an Unusual status when there are values that are untypical for the time span in which they are measured. PRTG compares the current average values to the historic monitoring results for this purpose. If the current values show a big difference to the values that are normally retrieved by a sensor, this sensor indicates this with the Unusual status.
Paessler designates all kinds of flow protocols as xFlow. Currently, PRTG supports NetFlow V5 and V9, IPFIX, sFlow V5, and jFlow V5.