6 results found

1. 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 feature, where two probes can be deployed as a redundant pair and configured with an “HA Mode” option.
   In this setup:

   Primary Probe runs active monitoring and synchronizes its configuration and sensor definitions to the Secondary Probe in real time.

   When the Primary Probe becomes unavailable (due to maintenance, network issue, or failure), the Secondary Probe automatically detects the failure and takes over all sensor operations.

   Once the Primary Probe returns, synchronization resumes, and historical data merges seamlessly.

   This feature would ensure continuous monitoring, no data loss, and no manual reconfiguration during probe outages.

   Such a feature would be especially valuable in segmented OT environments following the Purdue Model, remote sites, and distributed enterprise networks where reliability and redundancy are vital. It would also align PRTG with enterprise monitoring standards that already offer agent failover capabilities.

   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… more

   5 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminIsidora Jeremic (Admin, Paessler) responded

2. 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

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   In Progress  ·  AdminIsidora Jeremic (Admin, Paessler) responded

3. 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).

   5 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminIsidora Jeremic (Admin, Paessler) responded

4. 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

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminIsidora Jeremic (Admin, Paessler) responded

5. 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

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminIsidora Jeremic (Admin, Paessler) responded

6. 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 Outcome/Acceptance Criteria:
   PRTG probe can receive Nagios/Icinga check results via standard protocols (NSCA, passive checks, HTTP)
   Check results appear as native PRTG sensors with appropriate status mapping (OK=Up, Warning=Warning, Critical=Down, Unknown=Unknown)
   Performance data from Nagios/Icinga checks is extracted and displayed as PRTG channels
   Service and host check results are automatically organized under appropriate PRTG devices/groups
   Historical performance data is preserved and graphed using PRTG's visualization capabilities
   Alert thresholds and states from Nagios/Icinga are respected in PRTG notifications
   The probe supports bulk data ingestion for environments with hundreds or thousands of checks

   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… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   Gathering Feedback  ·  AdminIsidora Jeremic (Admin, Paessler) responded