Settings and activity
6 results found
-
1 vote
AdminIsidora Jeremic
(Admin, Paessler)
shared this idea
·
-
6 votes
An error occurred while saving the comment -
2 votes
An 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.
-
7 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 -
19 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
Hello Eugene,
We are still gathering feedback and measuring customer demand for this request.