Previous Next

PRTG Manual: Remote Probes and Multiple Probes

Upon installation, PRTG automatically creates the first probe, namely the local probe in PRTG Network Monitor, and the hosted probe in PRTG Hosted Monitor. They run on the PRTG core server system and monitor all reachable devices, servers, and services from the system, using the sensors you configure.

Working only with a local probe should suffice for LAN monitoring with PRTG Network Monitor and if you want to monitor one location only. For LAN monitoring with PRTG Hosted Monitor, at least one classic remote probe is required because the hosted probe can only reach targets that are publicly available via the internet.

Scenarios That Require Remote Probes

There are several situations that make it necessary to work with remote probes in the same LAN or in remote locations:

You use PRTG Hosted Monitor and want to monitor your local network.
You have more than one location and you need to make sure that services are available from all locations.
Your network is divided into several LANs that are separated by firewalls, and the local probe cannot monitor specific services across these firewalls.
You want to monitor systems in a secure network and you need a secure connection between the PRTG core server and that network.
You want to sniff packets on a different computer.
You want to monitor NetFlow data on a different computer.
You experience performance issues with CPU-intensive sensors like Packet Sniffer or NetFlow sensors and need to distribute the load among more than one computer.
You want to monitor a non-Windows system. This is only possible with a multi-platform probe.

The following chart shows an example for a remote probe scenario.

Monitoring a Distributed Network with PRTG

The PRTG core server inside the corporate LAN (top left) can monitor:

Services that are inside the corporate LAN using the local probe.
Services that are behind a firewall in the corporate LAN using remote probe 1.
Secured services that are inside the branch office (bottom right) using remote probe 2.
Secured services on mail server and web server using remote probe 3 and remote probe 4 installed directly on these servers.
Public services on the internet using any of the probes.

How Probes Work

As soon as a probe starts, it automatically connects to the PRTG core server, downloads the sensor configuration, and begins its monitoring tasks. The PRTG core server sends new configuration data to a probe as soon as the user changes the monitoring configuration. Probes monitor autonomously and send the monitoring results back to the PRTG core server for each check that they perform.

If the connections between the PRTG core server and a probe fail for any reason (for example, restarting the PRTG core server system), the probe continues to monitor and stores the results. During a connection loss, a buffer stores a maximum of 500,000 sensor results in the RAM of the remote probe system (up to 50 - 200 MB). This means that for 100 sensors with a 1-minute scanning interval, the probe can buffer the monitoring results of up to 3 days (or 52 minutes for 10,000 sensors with a 1-minute scanning interval). The probe automatically reconnects to the PRTG core server as soon as it is available again and transmits all monitoring results that it gathered during the connection loss.

The connection between a probe and the PRTG core server is initiated by the probe and is secured with Secure Sockets Layer (SSL)/Transport Layer Security (TLS). This means that the data that is sent back and forth between the PRTG core server and the probe is not visible to someone that is capturing data packets. The PRTG core server provides an open TCP/IP port and waits for connection attempts from probes. If a new probe connects for the first time, you receive a ToDo ticket and then you see the new probe in the device tree.

As a security precaution, you must manually approve the probe in the device tree before you can create any sensors. You can also deny a probe. PRTG then disconnects it. PRTG accepts no further connection attempts and it adds the probe IP address to the Deny IP Addresses list in the probe's system settings. This makes sure that unauthorized probes cannot connect to a PRTG core server.

Because the remote probe initiates the connection, you must make sure that a connection to your PRTG core server from the outside can be established. The process is the same as if you wanted to allow access to the PRTG web server provided by the PRTG core server via port 80 or 443. In most cases, this means that you will require an allow or allow-nat network address translation (NAT) rule that enables a remote probe to reach the PRTG core server via the Transmission Control Protocol (TCP) port 23560. Then, the remote probe uses a dynamic port from the high port range (49152 - 65535) for outgoing connections.

For remote probe connections to PRTG Hosted Monitor instances, the above also applies with the main difference that you only have to configure the remote probe side so that the outgoing connection to your PRTG Hosted Monitor (DNS name or underlying IP address) is possible and is reachable under this specific port.

If you run PRTG in a cluster, remote probes also connect to all cluster nodes and send monitoring data. This works as described above for a single PRTG core server. If the master node fails, you can still see monitoring data on the failover nodes. You can define the Cluster Connectivity of each probe in the probe's settings, section Administrative Probe Settings.

Automatic Probe Update

Whenever you install a new version of PRTG on the PRTG core server, all classic remote probes automatically download and install the updated version as soon as they reconnect to the updated PRTG core server.

PRTG does not automatically update multi-platform probes. If you installed a multi-platform probe via the Paessler Linux package repository, your package manager notifies you when there is an update. Otherwise, manually update your multi-platform probes with the updated package. For more information, see the Multi-Platform Probe for PRTG manual.

PRTG updates the local probe when you update the PRTG core server. All classic remote probes automatically download the new binaries via the SSL/TLS-secured probe connection or PRTG core server connection. Downloading the 4 MB file takes anywhere from a few seconds (in LANs) up to a few minutes (via internet connections), depending on the available bandwidth. As soon as the update is downloaded, the remote probe disconnects, installs the update, and reconnects to the PRTG core server. This takes between 20 and 100 seconds. Note that during the update phase, monitoring by the local probe can be affected because of the bandwidth that is required for the downloads.

If a classic remote probe keeps disconnecting after an update, check if the server with the remote probe has two network connections with different IP addresses. Make sure that these addresses are in the list of allowed IP addresses in the Core & Probes settings.

Delete Remote Probe

If you delete a connected remote probe via the device tree, it stops the PRTG probe service on the remote probe system and sets the startup type to manual. We recommend that you additionally uninstall the remote probe on the remote probe system.

If you delete a disconnected remote probe, it does not stop the PRTG probe service on the remote probe system and does not affect the startup type. The remote probe will continue to try to reconnect to the PRTG core server until you manually stop the PRTG probe service or uninstall the remote probe on the remote probe system.

PAESSLER WEBSITE