PRTG Manual: Glossary
This section explains special words used in the context of PRTG Network Monitor.
Here, only explanations are given. For information on where to find detailed instructions for a specific key word, see the Index section.
The alarms list shows all sensors that are currently in a Down, Down (Partial), Down (Acknowledged), Warning, or Unusual status. This is useful for keeping track of all irregularities in your network.
The PRTG 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.
The cloud probe relates to PRTG in the cloud like the local probe relates to PRTG on premises. When creating a PRTG in the cloud instance, the system automatically adds the cloud probe. The cloud probe is always running on the PRTG core server system that we host for you and shows monitoring values of your PRTG instance in the cloud. You can use the cloud probe to monitor devices, servers, and services that are publicly accessible in the internet like, for example, websites. To monitor your Local Area Network (LAN), you need at least one remote probe installation in your network. The local probe is not available in PRTG in the cloud.
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 gapless monitoring, so you can additionally compare monitoring results measured from different perspectives. This feature is not available in PRTG in the cloud.
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 to monitor them fail-safely. If one node fails, the other nodes will 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.
The central unit of PRTG. It receives monitoring data from the probe(s) and handles reporting and notifications, provides the web server for the user interfaces, and many other things. 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 the requirement for a logged in user
In the Home menu of the web interface, there are several pre-configured dashboards available that show a quick 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 the network. For an easily understandable tree structure, you usually create one PRTG device for each physical device 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 will save 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.
The Enterprise Console (in old PRTG versions called "Windows GUI") is one alternative interface that you can use to connect to the PRTG core server to configure your setup, view monitoring results, and keep an eye on your network. It is a native Windows application for fast access to data and monitoring management.
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 sub-groups 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.
Libraries are a way to show parts of your device tree in a different layout or with different filters enabled. There is an editor available that allows you to 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 in the cloud, the cloud probe replaces the local probe. There are some differences between PRTG in the cloud and PRTG on premises.
PRTG uses lookups for some sensor types and for some sensors with custom channels. In general, lookups make data more human friendly because they map status values as returned by a device (usually integers) to more informative expressions in words that show you the status of a monitored device as a clear message.
Maps (sometimes referred to as "dashboard") are a way to present monitoring data the way you want to arrange it. There is an editor available that allows creating maps directly in your browser. Using this unique concept, 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 to all other nodes in real time.
If you create a sensor that uses the meta-scan function, for example SNMP sensors, the sensor will first look at the device to find what can be monitored. When the meta-scan is done, the second step of the add sensor dialog shows you the parameters that you can monitor.
In a cluster, there is one master node and one or more failover nodes. On each node, one PRTG core server installation is running 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 allowing the use of 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 re-joins the cluster.
The PRTG Administration Tool is part of your PRTG installation and helps you edit 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 in the cloud is the PRTG cloud solution where we at Paessler run the core server and cloud 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 in the cloud and PRTG on premises.
PRTG on premises is a powerful network monitoring application for Windows-based systems that allows you to 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 in the cloud.
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 in the cloud does not have release channels. Instead, we roll out the latest Stable version to PRTG in the cloud instances in stages.
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.
The root group is the topmost instance in the object hierarchy of PRTG. It contains all other objects in your setup. All other objects inherit the settings of the root group, making configuration easier later on.
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 will run in the background with low priority. The recommended setting for similar sensors detection is to let PRTG automatically decide how many channels will be 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 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 will indicate 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.