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, please see the Index section. It is only available in the PDF version of this manual.
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 and traffic out. 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.
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 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.
In the Home menu of the web interface 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.
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 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.
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.
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.
Maps (sometimes referred to as "dashboard") are a way to present monitoring the way you want to arrange it. There is an editor available that allows creating maps directly in your browser.
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.
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.
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.
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.
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.
Sometimes used as synonym for device tree.
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 actions. You can access the list of tickets from the main menu.
Paessler designates all kinds of flow protocols as xFlow. Currently, PRTG supports NetFlow V5 and V9, IPFIX, sFlow V5, and jFlow V5.