PRTG Manual: Remote Probes and Multiple Probes
Upon installation, PRTG automatically creates the first probe, the Local Probe in PRTG on premises, and the Hosted Probe in PRTG hosted by Paessler. They run on the same machine as the PRTG core server and monitor all reachable devices, servers, and services from this system, using the sensors you configured.
Working only with a local probe should suffice for LAN monitoring with PRTG on premises and if you want to monitor one location only. For LAN monitoring with PRTG hosted by Paessler, at least one remote probe is required because the hosted probe can only reach targets that are publicly available via the internet.
There are several situations that make it necessary to work with Remote Probes in the same LAN or in remote locations. Among these situations are the following:
- You run a PRTG hosted by Paessler instance 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 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 server and this network.
- You want to sniff packets on another computer.
- You want to monitor NetFlow data on another 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 PC.
The following chart shows an example for a remote probe scenario.
The PRTG core server inside the Corporate LAN (top left) can monitor:
- Services inside the Corporate LAN using the Local Probe.
- Services behind a firewall in the Corporate LAN using Remote Probe 1.
- Secured services 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.
As soon as a probe starts, it automatically connects to the PRTG core server, downloads the sensor configuration, and begins its monitoring tasks. The 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 core server for each check they have performed.
If the connections between core and probe fail for any reason (for example, a restart of the computer running the core server), the probe continues monitoring 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 monitoring results of up to 3 days can be buffered (or 52 minutes for 10,000 sensors with a 1-minute scanning interval). The probe automatically reconnects to the core as soon as it is available again and transmits all monitoring results gathered during the connection loss.
The connection between probe and core is initiated by the probe and is secured using Transport Layer Security (TLS). This means that the data sent back and forth between core and probe is not visible to someone capturing data packets. The 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 see the new probe in the device tree.
As a security precaution, you must manually approve the probe in the device tree before any sensors can be created and monitored. You can also deny a probe which is then disconnected. PRTG accepts no further connection attempts and it adds the probe IP to the Deny IPs list in the probes system settings (see section System Administration—Core & Probes). This ensures that unauthorized probes cannot connect to a core server.
Because the probe initiates the connection, you must ensure that a connection to your core server from the outside can be established. For example, you may need to open any necessary ports in your firewall and you may need to specify a network address translation (NAT) rule for your network. The process is the same as if you wanted to allow access to the web server provided by the PRTG core server via port 443, for example. Make sure that you have the Transmission Control Protocol (TCP) port 23560 open or forwarded on both your PRTG core server side and probe side.
If you run PRTG in a cluster installation, remote probes also connect to your failover nodes in addition to the master node and send monitoring data. This works as described above for a single PRTG server. If your master node fails, you can still see monitoring data on your failover nodes. You can define the Cluster Connectivity of each probe in its Administrative Probe Settings.
Whenever you install a new version of PRTG on the core server, all remote probes automatically download and install the updated version of the probe as soon as they reconnect to the updated core installation.
The local probe is updated during the core installation. All remote probes automatically download the new binaries using the TLS-secured probe or core connection. The download of the 4 MB file takes anywhere from a few seconds (in a LAN) to a few minutes (via internet connections), depending on the available bandwidth. As soon as the update has been downloaded, the probe disconnects, installs the update, and reconnects to the 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 required for the downloads.
If a remote probe keeps being disconnected after an update, check if the server with the remote probe has two network connections with different IP addresses. Make sure these addresses are in the list of allowed IPs in the System Administration—Core & Probes settings.
Paessler Website: How to connect PRTG through a firewall in 4 steps
Video Tutorial: Distributed Monitoring with PRTG
- Active Directory Integration
- Application Programming Interface (API) Definition
- Filter Rules for xFlow, IPFIX, and Packet Sniffer Sensors
- Channel Definitions for xFlow, IPFIX, and Packet Sniffer Sensors
- Define IP Ranges
- Define Lookups
- Regular Expressions
- Calculating Percentiles
- Add Remote Probe
- Failover Cluster Configuration
- Data Storage
- PRTG Housekeeping
- Using Your Own SSL Certificate