My suggestions to PRTG

Dear Bastiaan

Thank you for taking the time and letting us know what you would like to see from PRTG.

We try to keep the custom sensor API as clean as possible. A behavior to trigger an error on no data could be implemented in the custom script itself, that is why we intentionally offer no API support to do the same. The PRTG database structure does not allow the deletion of existing channels. An existing channel can be hid manually, but not fully removed. This decision was made to trade flexibility for high database performance.

Device templates can be edited manually in a text editor, though we do not recommend this. In many cases it is faster to save a new device template than editing an existing one. This would still be the case if a device template editor would be available. The sensor default limits for manually created sensors cannot be edited either, but you can bulk-edit channel limits of existing sensors via multi-edit. (We are aware that the user interface could use some polish, but we try to avoid adding additional interfaces unless really required.)

The standards you mention gain more popularity and we already offer some WBEM and SOAP sensors; however we also have to keep our overall user base in mind which mostly focuses on SNMP. We plan to offer more support for newer standards in the future as they grow in importance.

We offer email support only because this is the most efficient way for most support cases. In many countries, Paessler partners can offer (paid) telephone support. This provides the options for local assistance in the native language for the users. You can look for partners here (please check the option "Paessler Certified Monitoring Expert".)

Thanks again for your time. We discuss user feedback on a regular basis to make sure that we prioritize features which would provide the most benefit for the most users.

Hi Arne, thank you for your reply. It's good to know you read customer feedback. I appriciate you anwser each item in order to help find a way to solve the issue. But i already had noumerous contact and posts. The feature requests are needed. Let me explain:

The way we use the api, for example is to enumurate all vCenter datastores with their health state thru a powerhsell script. Each VMFS datastore is a channel. With each run of the script it did not know the previous amount or names of the datastores. Therefore we cant posible determen if the previous enumurated datastore object is now gone and not giging any data. So the script cant tell PRTG a channel is gone. A work arond is to add each datastore as an scripted monitor, but that would loose the auto-add of new datastores. The same way we created noumerous powershell scripts. Therefore we would like to have an error on a channel who is no longer providing data, (objects / datastores who are no longer there or renamed), and we would like the option to delete the stalled channel.

Not all default sensors are editable thru a text editor, like the WMI disk full.

With device templates you loose auto-discovery functionality. So this is not an option when you have multiple device types per auto-discovery group, and when you want new devices in an object ot be auto-discoverd. I've discussed this in many posts. The only option is to add more flexability to autodiscovery. Exclusion methods. IP exlusions. Channel/sensor exclusions).

A big standard to focus on is SMI-S. We have a lot of storage boxes (HP MSA, HP 3PAr, EMC, HP Lefthand, Utanix, ext) With this openstandard you can monitor all storage boxes, without creating a custom sensor per box. (Even windows supports SMI-S).

Hooping these features will come to PRTG to make my day as an admin a lot easier. :-)

Kind Regards, Bastiaan

Dear Bastiaan

Please let me reply in a more general way this time. We consider PRTG to be a standard software, meaning we aim to provide the most features for the most users.

Reworking PRTG like optimizing the user interface is an ongoing process. It takes a considerable amount of development resources, but every user gets a benefit. That is why refinement of this kind has a high priority compared to more specific cases.

PRTG would not be what it is, if we hadn't a lot of good user feedback. Decisions of implementing a new feature, or reworking an existing one are always made using the collected user feedback. In many cases, we don't decide to implement a suggestion as it is. We try to find a solution which provides something for many users. This is one of the reasons we like to hear a lot of users first.