7 results found
-
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 -
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 -
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 -
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 -
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
- Don't see your idea?