Paessler PRTG is a network-monitoring system that measures devices and services through individual sensors. A sensor performs one defined job: pinging a host, reading an SNMP value, checking an HTTP response or collecting another metric. Sensors sit under devices, groups and probes, while the core server stores results, evaluates states and sends notifications.
Sensors are the unit
One physical server can need many sensors because availability, processor load, disks, interfaces and applications are separate measurements. The device tree organizes those checks and lets settings flow downward through inheritance. Pausing a device pauses its child sensors without deleting their history.
A growing device count does not describe load as clearly as the sensor count and sensor type. A simple ping costs much less than a complex script, flow collector or WMI query. Paessler PRTG should begin with the measurements tied to an action, not every sensor that auto-discovery can create.
Discovery needs boundaries
Auto-discovery scans an address range, identifies reachable devices and creates sensor sets from templates. Credentials inherited at the probe or root group let it inspect SNMP, Windows and other protected services more deeply. Without credentials, a device may appear with only basic checks.
Broad or frequent discovery can consume substantial time and resources. The official guide warns that large ranges may take days and can lower performance. A defined subnet, selected templates and a one-time schedule keep discovery from creating repeated noise or duplicate devices.
Intervals create load
The scanning interval is the time between measurements. Short intervals detect changes sooner and also multiply requests, processing and stored data. Some sensors impose a fixed minimum because their checks are too expensive to run rapidly.
Paessler recommends avoiding very short intervals that add load without useful accuracy. A Windows update status check does not need the same frequency as ping. The interval can inherit from a parent, so changing a group may affect hundreds of sensors at once. Multi-edit results need review before saving.
Probes define reach
Paessler PRTG’s local probe monitors targets reachable from the core server. A remote probe runs inside another site or network segment and sends results back. Remote probes are also needed when a hosted PRTG instance must reach private LAN devices.
Firewall rules, name resolution and credentials must work from the probe’s location, not from the administrator’s browser. A check that succeeds manually on the core server may fail from a remote probe. Deleting a connected remote probe also stops its service and changes its startup behavior, so deletion is not merely a way to hide it from the tree.
Dependencies reduce noise
A dependency pauses child monitoring when a parent sensor fails. If the router to a site goes down, Paessler PRTG can avoid sending a separate alarm for every unreachable server behind it. The dependency must point to a check that accurately represents the shared path.
A bad dependency can hide a real failure. If an unrelated parent is paused or down, dependent sensors stop measuring even when their own target remains reachable. Dependency design should follow network topology, and an independent external check can cover paths whose failure would otherwise silence all local evidence.
Notifications need thresholds
Notifications can react to sensor states, thresholds and elapsed time. Delays prevent a brief packet loss from becoming an immediate incident, while escalation can notify another channel if the condition persists. Schedules and maintenance windows suppress expected alerts.
A threshold copied across unlike sensors can be meaningless. Disk latency, temperature and bandwidth use different units and normal ranges. Paessler PRTG records data, but the administrator must choose when a value deserves action. Testing each notification route confirms delivery before the first real outage.
Clusters add more work
A failover cluster uses multiple core servers so another node continues monitoring when one fails. Each node performs its own checks for devices on the cluster probe. Monitoring traffic and target load therefore increase with every node.
Cluster data can contain gaps for a node that was offline; another node’s data does not fill those missing records. Remote-probe connectivity and reachable node addresses also need deliberate configuration. High availability protects the monitoring service, but it does not remove capacity planning or the need to secure every cluster node.
