Prtg

---
name: prtg
description: "Expert coverage of PRTG Network Monitor by Paessler: sensor-based monitoring model, auto-discovery, SNMP/WMI/flow/packet sensors, maps and dashboards, notification and escalation, PRTG Hosted Monitor SaaS, remote probes, and REST API automation. Use for \"PRTG\", \"Paessler\", \"PRTG sensor\", \"PRTG Hosted Monitor\", \"remote probe\", \"PRTG map\", \"PRTG auto-discovery\". Do NOT use for cross-vendor comparison, platform selection, or category-wide architecture -- use the `network-monitoring` skill."
license: MIT
---

# PRTG Network Monitor

This skill covers PRTG Network Monitor by Paessler. Areas of expertise include:

- Sensor-based monitoring model and licensing
- Auto-discovery and device templates
- Sensor types (SNMP, WMI, NetFlow/IPFIX/sFlow, packet sniffing, HTTP, ping, custom script)
- Maps and custom dashboards for NOC display
- Notification system with escalation chains
- PRTG Hosted Monitor (SaaS) and remote probes
- REST/HTTP API for automation
- Windows-based architecture (on-premises)

## How to Approach Tasks

1. **Classify** the request:
   - **Sensor configuration** -- Select appropriate sensor types, configure thresholds, optimize sensor count
   - **Architecture** -- On-premises vs Hosted Monitor, remote probe design, capacity planning
   - **Alerting** -- Notification triggers, escalation chains, maintenance windows
   - **Visualization** -- Maps, dashboards, reports
   - **Automation** -- API for sensor/device management, custom script sensors

2. **Identify deployment model** -- PRTG on-premises (Windows) or PRTG Hosted Monitor (SaaS)? Remote probes involved?

3. **Analyze** -- Apply PRTG-specific reasoning. Everything is a sensor. Optimize sensor count for licensing.

4. **Recommend** -- Provide specific sensor selections, configuration guidance, and API examples.

## Core Concept: Sensor-Based Model

Everything monitored in PRTG is a **sensor**. One sensor monitors one metric on one device.

### Examples
- 1 SNMP Traffic sensor = monitors In/Out traffic on 1 interface = 1 sensor
- 1 Ping sensor = monitors availability of 1 device = 1 sensor
- 1 WMI CPU sensor = monitors CPU of 1 Windows host = 1 sensor
- 1 HTTP sensor = monitors 1 URL = 1 sensor
- 1 NetFlow receiver = monitors flow data from 1 source = 1 sensor

### Licensing Tiers
| Tier | Sensors | Use Case |
|---|---|---|
| Free | 100 | Small network, evaluation |
| 500 | 500 | Small business |
| 1,000 | 1,000 | SMB |
| 2,500 | 2,500 | Mid-market |
| 5,000 | 5,000 | Enterprise |
| XL1 / XL5 | 10,000 / 50,000 | Large enterprise |
| Unlimited | No cap | Largest deployments |

### Sensor Count Optimization
- Disable auto-discovered sensors you don't need (each interface is a sensor)
- Use device templates to deploy only relevant sensors per device type
- Group monitoring: one ping sensor per device group instead of per device (where appropriate)
- Pause sensors on decommissioned devices rather than leaving active

## Auto-Discovery

### Discovery Process
1. PRTG scans IP range via ICMP (ping sweep)
2. For responsive hosts, attempts SNMP/WMI connection
3. Identifies device type (router, switch, server, printer, etc.)
4. Applies **device template** -- pre-defined sensor set for the device type
5. Creates device with recommended sensors

### Device Templates
Pre-defined sensor configurations for common device types:
- **Cisco Router**: Ping, SNMP Traffic (per interface), CPU, memory, uptime
- **Windows Server**: Ping, WMI CPU, WMI memory, WMI disk, WMI service
- **VMware Host**: Ping, VMware sensor (CPU, memory, datastore per host)
- **Generic SNMP Device**: Ping, SNMP uptime, SNMP system info
- Custom templates: Create your own for standardized deployments

### Auto-Discovery Schedule
- One-time scan or recurring (daily, weekly)
- IP range based or SNMP/CDP/LLDP neighbor-based
- Configurable: which subnets, which sensor types, which device templates

## Sensor Types

### SNMP Sensors
| Sensor | Monitors |
|---|---|
| SNMP Traffic | Interface in/out bandwidth |
| SNMP CPU Load | Device CPU utilization |
| SNMP Memory | Device memory utilization |
| SNMP Disk Free | Disk space (servers) |
| SNMP Custom | Arbitrary OID polling |
| SNMP Trap Receiver | Incoming SNMP traps |
| SNMP Custom Table | Table-based OID walks |
| SNMP Uptime | Device uptime counter |

### WMI Sensors (Windows)
| Sensor | Monitors |
|---|---|
| WMI CPU | Per-core CPU utilization |
| WMI Memory | Physical and virtual memory |
| WMI Disk Space | Per-volume disk usage |
| WMI Process | Specific process CPU/memory |
| WMI Service | Windows service state |
| WMI Event Log | Windows event log entries |
| WMI Security Center | Antivirus/firewall status |

### Flow Sensors
| Sensor | Monitors |
|---|---|
| NetFlow v5 | NetFlow v5 traffic analysis |
| NetFlow v9 | NetFlow v9 traffic analysis |
| IPFIX | IPFIX flow analysis |
| sFlow | sFlow traffic analysis |
| Packet Sniffer | Protocol-level packet capture |

### HTTP/Web Sensors
| Sensor | Monitors |
|---|---|
| HTTP | URL availability and response time |
| HTTP Advanced | Response content verification (regex) |
| HTTP Full Web Page | Full page load time (all resources) |
| SSL Certificate | Certificate expiry and validity |
| REST Custom | REST API endpoint with assertions |

### Custom Sensors
| Sensor | Method |
|---|---|
| EXE/Script | Run PowerShell/VBScript/EXE on probe |
| EXE/Script Advanced | Same with multi-channel output |
| SSH Script | Execute script on Linux host via SSH |
| Python Script Advanced | Run Python script on probe |
| REST Custom | Query REST API, parse JSON/XML response |

## Architecture

### On-Premises
- **Core Server** -- Windows Server (2016/2019/2022); runs PRTG Core Service
- **Local Probe** -- Runs on Core Server; monitors local network
- **Remote Probes** -- Windows agents deployed at remote sites; connect to Core Server over TLS
- **Database** -- Embedded database (proprietary); no external SQL required
- **Web Interface** -- Built-in web server; HTTPS

### PRTG Hosted Monitor (SaaS)
- Core Server hosted and managed by Paessler
- No on-premises server infrastructure required
- **Remote Probes** -- On-premises probe agents connect to cloud Core
- Monitor internal networks without exposing SNMP to internet
- Same sensor model and UI as on-premises
- Automatic updates, backups, and infrastructure management

### Remote Probe Architecture
```
[Remote Site A]
  [Devices] --> [Remote Probe A] --TLS (port 23560)--> [PRTG Core Server (HQ or Cloud)]

[Remote Site B]
  [Devices] --> [Remote Probe B] --TLS--> [PRTG Core Server]

[HQ]
  [Devices] --> [Local Probe] --> [PRTG Core Server]
  [PRTG Core Server] --> [Web Interface] --> [Admin Browser]
```

### Probe Use Cases
- Monitor remote sites without SNMP over WAN
- Monitor DMZ networks from isolated probe
- Monitor cloud VPCs from cloud-hosted probe
- Reduce WAN bandwidth (probe polls locally, sends summaries to Core)

## Maps and Dashboards

### Maps
- Visual network diagrams with live sensor status overlays
- Drag-and-drop editor with device icons, connections, labels
- Background images (floor plans, geographic maps, network diagrams)
- Live data overlay: traffic gauges, status indicators, graphs
- **Public URL**: Publish maps as web pages for NOC displays (no login required)
- **Rotation**: Cycle through multiple maps automatically

### Dashboards
- Configurable overview screens with widgets
- Widget types: Sensor list, graph, map, top 10 lists, alarms, gauges
- **Geo Maps**: Plot devices on world map by location
- Per-user dashboard customization
- Embeddable in external web pages

### Reports
- **Scheduled reports**: PDF or HTML, emailed on schedule
- **Report types**: Availability (SLA), uptime, sensor data, top 10
- **Custom time ranges**: Daily, weekly, monthly, custom
- **Compliance**: Availability reports for SLA documentation

## Notifications and Escalation

### Notification Triggers
| Trigger | Description |
|---|---|
| State change | Device/sensor changes state (up/down/warning) |
| Threshold | Metric exceeds configured value |
| Speed change | Metric changes rapidly |
| Volume | Cumulative volume exceeds threshold |
| Unusual | Deviation from learned baseline |

### Notification Methods
| Method | Configuration |
|---|---|
| Email | SMTP relay; HTML template |
| Push notification | PRTG mobile app (iOS/Android) |
| SMS | HTTP-to-SMS gateway or SMTP-to-SMS |
| Slack | Incoming webhook |
| Microsoft Teams | Incoming webhook |
| PagerDuty | API integration |
| Execute Program | Run script on PRTG server |
| HTTP Action | Custom HTTP request (webhook) |
| SNMP Trap | Send trap to another NMS |
| Syslog | Send syslog message |
| Amazon SNS | AWS notification |
| Ticket System | Create ticket via API |

### Escalation Chains
```
Level 1: Sensor down for 5 minutes --> Email to NOC team
Level 2: Not acknowledged in 15 minutes --> SMS to on-call engineer
Level 3: Not acknowledged in 30 minutes --> Page network manager
Level 4: Not acknowledged in 60 minutes --> Email to IT director
```

### Maintenance Windows
- Schedule per device, group, or sensor
- One-time or recurring (daily, weekly, monthly)
- Sensors paused during window (no alerts, no data collection)
- Or: continue monitoring but suppress notifications

## API

### HTTP API
PRTG provides an HTTP-based API for automation:

```
# Get sensor details
GET /api/table.json?content=sensors&output=json&columns=objid,device,sensor,status,lastvalue&apitoken=xxx

# Pause sensor
GET /api/pause.htm?id=2001&pausemsg=Maintenance&action=0&apitoken=xxx

# Resume sensor
GET /api/pause.htm?id=2001&action=1&apitoken=xxx

# Get sensor data (historic)
GET /api/historicdata.json?id=2001&avg=3600&sdate=2026-04-01&edate=2026-04-08&apitoken=xxx

# Add sensor (clone from template)
GET /api/duplicateobject.htm?id=2001&name=NewSensor&host=DeviceID&apitoken=xxx

# Set object property
GET /api/setobjectproperty.htm?id=2001&name=interval&value=300&apitoken=xxx
```

### Authentication
- API token (recommended): Generate in Setup > Account > API Keys
- Passhash: User-specific hash for legacy compatibility
- Username + password: Basic auth (not recommended for production)

### Use Cases
- Bulk sensor deployment (script creates sensors from inventory)
- Maintenance window automation (pause/resume via CI/CD pipeline)
- Custom dashboards pulling PRTG data into Grafana or web apps
- Integration with ITSM (auto-create tickets from sensor alerts)

## Common Pitfalls

1. **Sensor count explosion** -- Auto-discovery creates sensors for every interface, disk, and service. Review and disable unnecessary sensors immediately after discovery.

2. **WMI performance** -- WMI polling is resource-intensive on both PRTG and the target Windows host. Prefer SNMP for network devices; use WMI only for Windows-specific metrics.

3. **Remote probe connectivity** -- Remote probes need outbound TLS (port 23560) to Core Server. Firewalls blocking this port cause probe disconnection and data gaps.

4. **Polling interval too aggressive** -- Default 60-second interval is unnecessary for most sensors. Use 5-minute intervals for capacity metrics, 60 seconds only for critical availability.

5. **Not using device templates** -- Without templates, auto-discovery creates inconsistent sensor sets. Define templates for each device type in your network.

6. **Map performance** -- Maps with hundreds of live sensor overlays can be slow. Break large networks into multiple focused maps.

7. **Flow sensor licensing** -- NetFlow/IPFIX/sFlow sensors count toward sensor limit AND may require additional flow sensor license tier. Verify licensing before deploying flow sensors.

8. **Single Core Server** -- PRTG on-premises has no native Core Server HA. Plan for server-level HA (VM HA, clustering) or use PRTG Hosted Monitor for managed availability.