Settings and activity
14 results found
-
1 vote
AdminIsidora Jeremic
(Admin, Paessler)
shared this idea
·
-
3 votesAdminIsidora Jeremic
(Admin, Paessler)
supported this idea
·
-
19 votes
An error occurred while saving the comment -
2 votes
An error occurred while saving the comment AdminIsidora Jeremic
(Admin, Paessler)
commented
Thank you for your feedback!
We want to let you know that we are planning a complete rewrite of the SNMP Cisco System Health sensor. While we can't share specific details about which features and options will be included at this point, the new version will bring significant improvements over the current sensor. We'll keep you updated as we make progress.
Best regards,
The Paessler Product Team -
4 votes
An error occurred while saving the comment AdminIsidora Jeremic
(Admin, Paessler)
commented
The PRTG Database was introduced as a beta feature, with an opt-in mechanism for activation, to explore how a modern, scalable database engine could benefit large and complex monitoring environments. Based on the recent feedback and evaluation of the installation experience, we recognized that while the current implementation provides significantly increased scale per installation, it does not yet meet our standards for ease of use and reliability. With this in mind, we are now evaluating options to provide the same levels of scale while maintaining ease of use across the installation and overall user experience.
Supporting large and complex monitoring environments remains a core part of our PRTG capability. The decision to pause the PRTG Database feature is specifically about ensuring that any solution we deliver meets our quality and usability standards, while keeping our goal of maintaining an easy "Monitor in Minutes" experience. We are actively working on a more streamlined and reliable approach, targeted for 2027, that will better serve enterprise-scale environments. -
22 votes
An error occurred while saving the comment AdminIsidora Jeremic
(Admin, Paessler)
commented
The PRTG Database was introduced as a beta feature, with an opt-in mechanism for activation, to explore how a modern, scalable database engine could benefit large and complex monitoring environments. Based on the recent feedback and evaluation of the installation experience, we recognized that while the current implementation provides significantly increased scale per installation, it does not yet meet our standards for ease of use and reliability. With this in mind, we are now evaluating options to provide the same levels of scale while maintaining ease of use across the installation and overall user experience.
Supporting large and complex monitoring environments remains a core part of our PRTG capability. The decision to pause the PRTG Database feature is specifically about ensuring that any solution we deliver meets our quality and usability standards, while keeping our goal of maintaining an easy "Monitor in Minutes" experience. We are actively working on a more streamlined and reliable approach, targeted for 2027, that will better serve enterprise-scale environments. -
20 votes
Hi 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…
-
3 votes
An error occurred while saving the comment AdminIsidora Jeremic
(Admin, Paessler)
commented
Hello Daniel,
Thank you for submitting this idea; we understand the security concern of having credentials visible in clear text within the notification template configuration.
While we evaluate this feature request and gather further feedback, we'd like to point out a workaround that may already help improve your setup:
Instead of using a plain-text password in your Execute HTTP Action URL, you can use a passhash for authentication. For example, instead of:
http://yourserver/api/pause.htm?id=%sensorid&action=0&username=myuser&password=mypassword
you can use:
http://yourserver/api/pause.htm?id=%sensorid&action=0&username=myuser&passhash=1234567890
You can find your passhash by navigating to Setup → My Account in the PRTG web interface.
Additionally, you can use various placeholders in the URL and Parameters fields of the Execute HTTP Action. For a full list of available placeholders, please refer to our documentation: https://www.paessler.com/manuals/prtg/list_of_placeholders_for_notifications#availableplaceholders
Best regards,
The Paessler Product TeamAn error occurred while saving the comment AdminIsidora Jeremic
(Admin, Paessler)
commented
Customer's use case:
I have devices that are only occasionally online (laptops, dual-band Wi-Fi devices with different IPs for 2.4 or 5 GHz) and all sort of other devices that are usually offline, but for which I want to collect data automatically when they come on-line.
I have a "Script v2" sensor running regularly a Python script that fetches the list of paused devices, pings each one to see if it is online, and sends an HTTP API request to resume each device that responds to ping. This takes care of the "device reappearing" part. The required HTTP API credentials are passed securely through the %scriptplaceholder1 method provided by PRTG.
The flip side of the operation is to pause the device when it goes offline. Of course, ping is the Master sensor for the device, but unfortunately, it stays in alarm (or acknowledged alarm if so configured). When my system is running "nominal", I only want "Up" and "Paused" devices, not a ton of acknowledged "normal" alarms in which it becomes impossible to distinguish the "normal" ones that can be ignored from the ones that need to be worked on.
The quick fix is to simply create a Notification Template "Pause device" that will send a Pause HTTP API request to a sensor's parent device and add this to the Ping sensor of devices that are not expected to be online according to a regular schedule.
The issue, however, is that there is no way to securely pass the required API credentials in a Notification Template. The "Execute HTTP Action" does not support the secure placeholders. When I requested support from Paessler, the agent’s solution was to use the “Execute Program” section of the Notification Template, defining the API credentials in the OS environment itself. To me, the suggestion of putting the API token in clear text in a script file, or as a parameter visible on the command line, negates all the good security work implemented in PRTG.
PRTG goes to great lengths to protect API tokens:
• It is shown only once when creating
• It cannot be seen again when put in credentials placeholders
• Script v2 passes the credentials through a pipe, to avoid them being able to be seen on the command line.If the Notification Template’s Execute HTTP Action section could accept secure placeholder and use them internally when generating the HTTP request, which seems simple enough at first glance, then this would preserve the credential’s security and restrict it’s use to within PRTG for this use case.
-
13 votes
An error occurred while saving the comment AdminIsidora Jeremic
(Admin, Paessler)
commented
Hello,
Please note that MFA is already available through SSO (Okta and Microsoft Entra ID) options:
You might want to try some workarounds:
- AD FS (Active Directory Federation Services): Use your existing Windows Server infrastructure to act as the SAML provider. You can configure AD FS to require certificates or smart cards.
- Reverse Proxy (Authelia/Authentik): Place PRTG behind a proxy (like Nginx) paired with a tool like Authelia. The proxy intercepts traffic and forces an MFA check before the user can even see the PRTG login screen.
However, please note that these suggestions have not been tested by Paessler. They are not natively supported, and our team is unable to assist with setup or troubleshooting.
Best regards,
The Paessler Product Team
-
4 votesAdminIsidora Jeremic
(Admin, Paessler)
shared this idea
·
-
8 votes
An error occurred while saving the comment AdminIsidora Jeremic
(Admin, Paessler)
commented
Hello Eugene,
We are still gathering feedback and measuring customer demand for this request. -
15 votes
An error occurred while saving the comment AdminIsidora Jeremic
(Admin, Paessler)
commented
Hello Manfred,
The multi-platform probe is our way to offer a modern, 64-bit probe. Currently, it is available for Linux environments only. We are also working on providing a multi-platform probe for Windows, which is planned for this year.
The multi-platform probe doesn't have the full sensor set yet, but we're adding more continuously. If you have specific sensors, you need urgently, let us know. This will help us in prioritizing further sensor development. We are working on this with high focus, but due to the enormous amount of sensor types PRTG offers, it will take us beyond this year to complete the full sensor set. -
5 votes
An error occurred while saving the comment AdminIsidora Jeremic
(Admin, Paessler)
commented
Use case:
We are building an integration between PRTG and our monitoring platform that requires tracking individual sensor event occurrences through their complete lifecycle (open → close). Currently, there is no way to uniquely identify the same event occurrence across both real-time notifications and the API messages endpoint.Our integration needs to:
1. Capture event creation: When a sensor goes DOWN (or WARNING), create an event record in our system
2. Track event resolution: When the same sensor recovers (goes UP), update the same event record to mark it as resolved
3. Maintain historical tracking and allow Synchronization for missed events through API.
Current Limitation:
The /api/table.json?content=messages endpoint provides a unique objid for each message, which identifies individual event occurrences. However, this same objid value is not available as a notification placeholder for Execute Program notifications. And potentially gives a different id per event update.
This creates a fundamental integration problem:
- API sync can retrieve message objid: 5428 for a DOWN event
- Webhook notification for the same event has no way to reference objid: 5428
- We cannot correlate the webhook notification with the API message
Why the Suggested Workaround Doesn't Work ("...you can combine placeholders such as (%sensorid & %datetime & %status) to create a reasonably unique identifier."):
The suggested approach of using %sensorid%-%datetime%-%status% has critical flaws:
Issue 1: Timestamps change during event lifecycle
DOWN event fires at 14:30:00 → Webhook sends: "2092-2025-01-02-14:30:00-Down"
UP event fires at 14:35:00 → Webhook sends: "2092-2025-01-02-14:35:00-Up"
Result: Different IDs for the SAME event occurrence → Cannot close the event
Issue 2: Synchronization timing mismatch
Notification fires at 14:30:03.245
API sync runs at 14:30:07.891
Webhook creates: "2092-2025-01-02-14:30:03-Down"
API returns: "2092-2025-01-02-14:30:03-Down" (from message datetime field)
Result: Cannot match webhook to API message
Issue 3: Only shows latest state per sensor
Using %sensorid% alone:
- Monday DOWN → Event "2092" created
- Monday UP → Event "2092" closed ✓
- Tuesday DOWN → Event "2092" reopened (overwrites Monday's data) ✗
Result: No historical tracking of separate incidents
Proposed Solution:
Expose the existing message/event objid value as a notification placeholder (e.g., %messageid% or %objid%).
Why This Works:
The message objid is generated by PRTG when logging state changes. We simply need access to this same value in notifications ( and of course be able to identify an event uniquely ):
When sensor goes DOWN:
- PRTG logs message with objid=5428
- Notification template receives: %messageid% = 5428
- API endpoint /api/table.json returns: {"objid": 5428, "status": "Down"}
- Both use identical ID: 5428 ✓
When sensor goes UP:
- PRTG logs message with objid=5429
- Notification template receives: %messageid% = 5429
- API endpoint /api/table.json returns: {"objid": 5429, "status": "Up"}
- Both use identical ID: 5429 ✓
Alternative Solution:
If exposing message objid is not feasible, add a %triggerid% placeholder that returns the notification trigger ID. And return this triggerid in Api calls for synch too. This would allow constructing: sensorid-triggerid-server state, though this is less optimal as it requires additional logic.
Benefit to PRTG Users:
This enhancement would enable proper event lifecycle tracking for:
- External integrations and SIEM systems
- Ticketing platforms
- Event management systems
- Historical incident tracking
- MTTR (Mean Time To Resolution) calculations
Request:
Please expose the objid/eventid value as a notification placeholder (e.g., %messageid% or %objid%). This would provide parity between the API and notification system, enabling proper event lifecycle tracking for external integrations.From my understanding in the API the objid is actually just the id of the message sent and doesn't indicate to what event the message/event belongs to. So my request is also relevent for the Api - show the Event ID ( so we can also know what to resolve ) or the workaround is showing the Trigger ID to create a accurate composite key with Sensor and Server.
Thank you for considering this enhancement!
Best Regards,
Daniel -
23 votes
An error occurred while saving the comment AdminIsidora Jeremic
(Admin, Paessler)
commented
Previous feedback on this topic: https://helpdesk.paessler.com/en/support/solutions/articles/76000076829-time-to-support-group-managed-service-accounts-gmsa
Hi Jasper,
Thank you for reaching out! Unfortunately, we don't have any updates on this request at the moment. Rest assured, your feedback is noted and we'll keep you posted if anything changes.
Best regards,
The Paessler Product Team