9 results found
-
High Availability Remote Probes with Automatic Sensor Replication and Failover
As an IT Infrastructure Manager, I want to deploy redundant remote probes that automatically replicate sensor configurations and provide seamless failover capabilities, so that I can ensure continuous monitoring coverage without manual intervention during probe outages and eliminate single points of failure in remote locations.
In environments where uptime and monitoring continuity are critical — especially in OT and industrial networks — a single PRTG Remote Probe represents a potential single point of failure. Currently, if a probe goes offline, all sensors assigned to it immediately lose visibility until the probe is restored.
I propose a High Availability (HA) Probe…
9 votes -
Remote Probe Installation for PRTG Non-Admin Users
As a PRTG Administrator, I want to be able to allow PRTG users in non-administrator groups the ability to download and install remote probes.
We're an MSP with a wide variety of needs and technical staff, we've sought to develop PRTG groups in conjunction with SSO to better control access to our environment (admins, full control, read-only, etc.).
During that process we discovered that only select users who are members of the 'Administrators' group - the same group with control over user accounts, groups, and setup settings - have the ability to download and install remote probes to set up…
6 votes -
Count of sensor types per probe
As a PRTG admin I want to know what sensor types are on each probe. For example if there are heavy probes like WMI running I have a more limited capacity on the probe so having the count would be helpful so that I can manage probe capacity (could be an addition to the PRTG Status page /status.htm?tabid=1).
6 votes -
Streamline the multi-platform probe experience for PRTG
Integrate the NATS server and simplify the multi-platform probes installation and set up process with self-signed certificates.
5 votes -
Organize Probes by Division and Groups for Better Management
As a network administrator at a large company with multiple sub-divisions, I want to organize probes into hierarchical groups by division so that I can better manage and navigate our monitoring infrastructure.
Division 1
├── Probe 1
│ ├── Group 1
│ │ ├── Device 1
│ │ │ ├── Sensor 1
│ │ │ └── Sensor 2
│ │ └── Device 2
│ └── Group 2
├── Probe 2
└── Probe 3Division 2
├── Probe 1
├── Probe 2
└── Probe 34 votes -
Multi-platform Probe on Kubernetes Cluster
User Story:
As a Platform Engineer managing distributed Kubernetes infrastructure,
I want to deploy PRTG Multi-Platform Probes natively within Kubernetes clusters
so that I can ensure continuous network monitoring with high availability and reduced infrastructure complexity.Acceptance Criteria:
- PRTG Multi-Platform Probes can be deployed as native Kubernetes resources (e.g., via Helm chart or Operator) without requiring Docker-specific host capabilities.
- The deployed probes support high availability and auto-recovery.
- All core probe monitoring features are functional and compatible when running inside Kubernetes, matching the capabilities available on standard Docker or VM-based deployments.2 votes -
OpenTelemetry probe
As a DevOps engineer who is user of OpenTelemetry and PRTG I would like to be able to send metrics and events from the Otel collector to PRTG (OTLP) so that I can have my monitoring and observability data in one tool.
2 votes -
Configurable Sensor Limit per Remote Probe (to prevent license overuse)
For us as an MSP, it is important to be able to define a clear upper limit for the number of sensors that can be used per remote probe.
Some remote probes run within our customers’ infrastructure. At the same time, customers have write permissions within their probe so they can independently add and manage devices and sensors in their environment. This creates a risk that more sensors may be activated than permitted by the license and billed by us.
Manually checking the sensor count per customer is no longer a modern approach and is difficult to scale reliably in…
1 voteThanks for submitting your idea, to Paessler! We really appreciate you taking the time to share your feedback and help us improve our products.
Your idea has been successfully received and is now in our review queue. Our team will carefully evaluate it, and we'll keep you updated on its status.
In the meantime, feel free to share your idea with others to gather more support and comments. The more input we get, the better!
Thanks again for your contribution.
Best regards,
The Paessler Product Team
-
Nagios/Icinga Check Results Push Probe for PRTG Integration
Organizations with existing Nagios/Icinga deployments have invested significant time and effort in configuring custom checks, plugins, and monitoring logic. Rather than recreating these checks in PRTG, they want to leverage their existing Nagios/Icinga check configurations and push the results directly into PRTG for centralized visibility and management.
As a Systems Engineer with existing Nagios/Icinga monitoring infrastructure,
I want a PRTG probe that can receive and process check results from my existing Nagios/Icinga checks,
so that I can leverage my current monitoring investments and display all check results within PRTG's interface without having to recreate or duplicate my monitoring configurations.Desired…
1 vote
- Don't see your idea?