4 results found

1. Be able to install a probe on Windows to replace the WMI sensors

   With the high performance costs (to the PRTG hosting systems) of WMI sensors, since they are not availability (ping/port/url), have a Windows probe which would shift the WMI sensors to be local sensors to the windows host and then publish the metrics/state to the PRTG hosting systems. So this would shift the WMI sensors from a pull from the PRTG host, to a publish from a PRTG probe model.
   With this, the operational costs of the WMI are shifted to the target instead of at the PRTG hosting server side.

   2 votes

   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

   1 comment  ·  Delete…  ·  Admin →
   Declined  ·  Jonah Kowall responded

   Hi there,

   Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.

   Thank you for the idea, but due to the core limitations of 30-80 probes per core (based on installation specific sizing) this would not be a scalable solution. We are not planning to deliver an agent based solution anytime soon.

   After careful consideration by our team, we've decided to decline this idea at this time.

   While this particular idea won't be moving forward, please don't be discouraged! Your input is incredibly valuable, and we encourage you to continue sharing your thoughts and ideas with us.

   Thanks for your understanding and for helping us shape the future of Paessler.

   Best regards,

   The Paessler Product Team

2. 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 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 →
   Declined  ·  AdminIsidora Jeremic (Admin, Paessler) responded

   Thanks for this suggestion and for everyone's input here. We regularly review open ideas to keep our backlog focused on what will benefit the most users. Since this one hasn't gathered enough support over time to justify prioritizing it, we're closing it for now. This doesn't mean it's off the table forever - if priorities or demand change, we're always open to revisiting. In the meantime, please keep the ideas coming!

   Best regards,

   The Paessler Product Team

   
   

3. Classic remote probe for Linux / Docker

   More and more of our customers won't allow Windows hosts in their environments at all. The AI infrastructure customers in particular are Linux-only shops, and for them "the probe needs a Windows VM" has gone from an annoyance to a dealbreaker. We're an MSP running hundreds of thousands of sensors across plenty of cores, so this comes up constantly.

   I know the official answer is the multi-platform probe. We evaluated it seriously and it isn't a replacement for us yet. Sensor coverage is part of it, but the bigger problem was customer security reviews. InfoSec teams approve the classic probe fast because the model is easy to explain: one outbound TLS connection to the core on 23560, nothing listening on the probe side, manual approval on the core before any sensor runs. With the MPP we end up explaining NATS, its port, its certificates, and its patch history, and reviews that used to take days now won't even pass. The classic probe's simplicity is a feature. Please don't leave it without a Linux story.

   The old KB answers said a Linux probe was impossible because Wine couldn't run background services and had no usable .NET. That was true in 2013. It isn't anymore. I wrote and maintain an open source project that runs the stock, unmodified probe binary headless under Wine 11 in Docker:

   https://github.com/rtravellin/prtg-classic-probe-linux.

   WMI sensors, the .NET helpers, PowerShell sensors and packet capture all work. Nothing in the probe binary needed changing. Every fix lives in the open source Wine layer, which says to me the port is smaller than it once looked.

   So the request: an officially supported classic probe for Linux, ideally as a container image. Even an experimental or beta image with best-effort support would let us deploy to Windows-free sites today while the MPP catches up on sensors. Happy to share everything I learned getting it running under Wine, though most of it is already written up in the repo.

   More and more of our customers won't allow Windows hosts in their environments at all. The AI infrastructure customers in particular are Linux-only shops, and for them "the probe needs a Windows VM" has gone from an annoyance to a dealbreaker. We're an MSP running hundreds of thousands of sensors across plenty of cores, so this comes up constantly.

   I know the official answer is the multi-platform probe. We evaluated it seriously and it isn't a replacement for us yet. Sensor coverage is part of it, but the bigger problem was customer security reviews. InfoSec teams approve the classic probe… more

   1 vote

   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 →
   Declined  ·  AdminIsidora Jeremic (Admin, Paessler) responded

   Hello Richard,

   Thank you for this detailed and well-argued request, and for the impressive open-source work behind it! You're right: Windows-free environments are becoming more common, and the classic probe's simple security model is a real strength in customer security reviews. We hear this from other customers as well.

   Still, we have to decline this request. The classic probe is architecturally tied to Windows, and officially supporting it on Linux via a compatibility layer isn't a path we will take. Our strategic direction for Linux is the multi-platform probe.

   What we can share: the friction you describe is on our radar. We're actively working on simplifying the MPP's connection architecture and deployment model, with the explicit goal of making security reviews much easier, and sensor coverage continues to grow with every release.

   We'd genuinely encourage you to re-evaluate the MPP as these improvements ship, and we're sorry this isn't the answer you were hoping for. Thank you again for the effort! Feedback at this level of depth is exactly what we want, even when we can't act on it the way you'd like.

   Best regards,

   The Paessler Product Team

   Hello Richard,

   Thank you for this detailed and well-argued request, and for the impressive open-source work behind it! You're right: Windows-free environments are becoming more common, and the classic probe's simple security model is a real strength in customer security reviews. We hear this from other customers as well.

   Still, we have to decline this request. The classic probe is architecturally tied to Windows, and officially supporting it on Linux via a compatibility layer isn't a path we will take. Our strategic direction for Linux is the multi-platform probe.

   What we can share: the friction you describe is on our radar. We're actively working on simplifying the MPP's connection architecture and deployment model, with the explicit goal of making security reviews much easier, and sensor coverage continues to grow with every release.

   We'd genuinely encourage you to re-evaluate the MPP as these improvements ship, and we're sorry this isn't the… more

4. Cluster Compatibility for Multi-Platform Probe

   As an IT Infrastructure Manager managing a large-scale, enterprise PRTG deployment with a clustered core server setup,
   I want the multi-platform probe to fully support PRTG clusters,
   so that I can leverage non-Windows monitoring capabilities without sacrificing the high availability and redundancy that my enterprise environment requires.

   1 vote

   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 →
   Declined  ·  AdminIsidora Jeremic (Admin, Paessler) responded

   Hi there,

   Thank you again for submitting your idea to Paessler. We truly appreciate you taking the time to share your feedback.

   After careful consideration by our team, we've decided to decline this idea at this time. This decision was made based on several factors, which may include:

   • It doesn't align with our current product roadmap or strategic priorities.
   • The resources required for implementation outweigh the current projected benefits for our user base.
   • There are technical limitations that prevent us from moving forward.
   • A similar feature is already available or planned in a different way.

   While this particular idea won't be moving forward, please don't be discouraged! Your input is incredibly valuable, and we encourage you to continue sharing your thoughts and ideas with us.

   Thanks for your understanding and for helping us shape the future of Paessler.

   Best regards,

   The Paessler Product Team