12 results found
-
Supported Interface Filtering for SNMP Auto-Discovery Templates
As a Network Engineer managing hundreds of Cisco switches and routers,
I want to define supported, documented interface filters (by name, operational status, speed, and type) within SNMP Object Discovery Templates,
so that auto-discovery only creates SNMP Traffic sensors on the interfaces I actually need to monitor — eliminating manual post-cleanup and unsupported XML hacks.Problem: When using ODTs to auto-discover SNMP Traffic sensors on Cisco switches and routers, PRTG creates sensors on all interfaces — including loopbacks, VLANs, tunnels, and inactive ports — with no officially supported way to filter them at discovery time. The <include> filter in device…
19 votesHi everyone,
Thank you all for voting on this idea.
Before we can commit to developing this idea, we need more input from the community.
We want to clarify: filtering/controlling which interfaces are monitored by the SNMP Traffic sensor during Auto-Discovery has actually been possible in PRTG for quite some time, by editing the ODT file: https://helpdesk.paessler.com/en/support/solutions/articles/76000041645-how-can-i-include-and-exclude-sensors-from-device-templates-
Since version PRTG .118, it has also been feasible with the SNMP Traffic v2 sensors.
That said, we understand that manually editing ODT files is not the most intuitive experience, and we suspect that's exactly the pain point many of you are hitting.
To help us prioritize the right improvements, we'd love to hear from you:
- What is your specific use case? (e.g., filtering by interface name, speed, type, etc.)
- What makes the current ODT-based approach difficult or impractical for you?
- Would a graphical UI for managing these filters solve your problem?
Thanks…
-
Flexible template adjustment in the UI
As a network administrator managing multiple similar devices, I want to modify existing device templates by adding new sensors or adjusting thresholds directly in the web interface, so that I can maintain consistent monitoring standards without recreating templates from scratch every time requirements change.
26 votes -
Column-Based Row Filtering for SNMP Custom Table Sensors in Device Templates
As a Network Engineer,
I want to filter (include/exclude) SNMP Custom Table rows based on column values when using device templates,
so that only relevant table entries (e.g., specific BGP neighbors or access points) are automatically created as sensors during auto-discovery, reducing noise and manual cleanup.Background:
I have been using custom device templates for quite some time. I particularly like the SNMP table template for automatically adding elements such as BGP neighbors on routers or access points on FortiGates.
However, I am facing a limitation regarding the ability to filter (include / exclude) table rows based on the content…2 votes -
Auto‑Attach Relevant Sensors Based on Service Detection
As a PRTG user, I want discovery and port workflows to detect the services a device offers (e.g., HTTP/S, LDAP/S, SSH, SNMP, databases) and automatically add the most relevant sensors with sensible defaults—so setup is faster and cleanup is minimal.
7 votesHi there,
Great news! Your idea has been reviewed and is now officially on our roadmap! This means we've committed to developing it in the future.
While we don't have an exact release date yet, we're planning to implement this feature/improvement as part of our upcoming development cycles. We're excited about the value this will bring to our users.
We appreciate your patience as we work to bring this to fruition. We'll let you know once it moves into active development.
Thanks for helping us build a better Paessler!
Best regards,
The Paessler Product Team
-
UVexplorer - Netbox Integration
As an IT Infrastructure Manager,
I want a native bidirectional integration between UVexplorer and Netbox that automatically synchronizes discovered devices, topology, IP information, and device attributes,
so that I can eliminate manual data transfer between my discovery and IPAM/DCIM systems, maintain a single source of truth for network documentation, and accelerate asset management workflows across large-scale environments.Business Value:
- Eliminate manual data transfer between discovery and IPAM/DCIM systems
- Improve data accuracy through automatic synchronization
- Accelerate network documentation workflowsKey Functionality:
- Auto-import: Push discovered devices, topology, and IP information from UVexplorer to Netbox
- Sync: Bidirectional updates…1 vote -
Save and Reuse Credentials for Discovery
As a PRTG user, I want to securely save my credentials (e.g., accounts, passwords, SNMP keys) in one place so I can easily reuse them for any discovery job.
9 votesHi there,
Great news! Your idea has been reviewed and is now officially on our roadmap! This means we've committed to developing it in the future.
While we don't have an exact release date yet, we're planning to implement this feature/improvement as part of our upcoming development cycles. We're excited about the value this will bring to our users.
We appreciate your patience as we work to bring this to fruition. We'll let you know once it moves into active development.
Thanks for helping us build a better Paessler!
Best regards,
The Paessler Product Team
-
Automatic Cleanup of Obsolete and Duplicate Devices
As a Systems Engineer monitoring dynamic cloud environments, I want an option in auto-discovery groups to automatically delete all existing devices before creating new ones during each discovery run,
so that I can maintain a clean, accurate monitoring configuration without manually removing obsolete devices or duplicates (like Azure VMs that are deleted and recreated with new names/IPs) after each discovery cycle.3 votes -
Control What Auto-Discovery Finds
As a system engineer, I want to set rules (e.g., exclude certain devices or sensors) and review changes before they’re applied so I can avoid unnecessary cleanup and keep my monitoring focused.
7 votesHi there,
Great news! Your idea has been reviewed and is now officially on our roadmap! This means we've committed to developing it in the future.
While we don't have an exact release date yet, we're planning to implement this feature/improvement as part of our upcoming development cycles. We're excited about the value this will bring to our users.
We appreciate your patience as we work to bring this to fruition. We'll let you know once it moves into active development.
Thanks for helping us build a better Paessler!
Best regards,
The Paessler Product Team
-
Manage All Discovery Jobs in One Place
As a system engineer, I want a single place to manage and schedule all my discovery jobs so that I can save time and avoid conflicts with other network tasks.
7 votesHi there,
Great news! Your idea has been reviewed and is now officially on our roadmap! This means we've committed to developing it in the future.
While we don't have an exact release date yet, we're planning to implement this feature/improvement as part of our upcoming development cycles. We're excited about the value this will bring to our users.
We appreciate your patience as we work to bring this to fruition. We'll let you know once it moves into active development.
Thanks for helping us build a better Paessler!
Best regards,
The Paessler Product Team
-
Preserve Inheritance of Schedules, Dependencies, and Maintenance Window Settings in Auto Discovery Templates
As a PRTG user, I want auto discovery templates to apply the same default schedule, dependency, and maintenance window settings as manual device creation, so that I can deploy monitoring consistently without requiring manual post-configuration steps.
The default behaviour when manually adding a device without a template is for the “schedules, dependencies and maintenance window “ option to be toggled on however when using an auto discovery template this is toggled off. This behaviour is not intuitive and requires manual intervention after using a template to ensure this is toggled on.
5 votes -
Automatic Cisco Meraki Network Health Sensor Creation with Template-Based Discovery
As an IT Infrastructure Manager, I want PRTG to automatically add Cisco Meraki Network Health sensors for new networks discovered in my Meraki Dashboard without requiring manual API key entry for each sensor, so that I can ensure comprehensive monitoring coverage across hundreds of networks while eliminating repetitive configuration tasks that don't scale with our rapid network deployment schedule.
Currently, there appears to be no way to have any new networks in Meraki Dashboard to be auto-discovered and added automatically to the Cisco Meraki Network Health.
When we create a new network in Meraki, we need to manually add it…
4 votes -
Auto-Discovery with Custom Device Template Presets
As an IT Infrastructure Manager, I want to use Auto-Discovery with Custom Templates, that would provide the ability to select a set of specifics sensors for determined device type (including icons), in addition this would give the ability to customize sensors channel settings. Example: uptime parameters.
2 votes
- Don't see your idea?