[OPEN] Customize default naming for devices and sensors, global custom naming conventions

Want this feature implemented, too? Please upvote by clicking Thumbs up!

(Posts as a reply won't be published in this feature request thread. Read Me!)

User story

in addition to

https://kb.paessler.com/en/topic/87714-customize-sensor-default-names https://kb.paessler.com/en/topic/81276-open-device-name-placeholder-for-sensor-names https://kb.paessler.com/en/topic/70780-ping-sensor-naming ...and others

i would suggest that you implement a feature which enables the PRTG Admin to set global custom naming conventions for both devices and sensors. It would be great to have variables (like DNS-Name, IP-address, parent device, parent-probe, parent-group etc.), dividers and auto numbering per sensor type for both.

Details of user story

In larger PRTG environments, naming can be a huge effort (even through mass changes) if you want it to be consistent and informative. The larger the environment gets, the more you will want to use the search feature to find devices or sensors. Distinguishing the search results will depend on consistent naming, if each "Ping" sensor will be named the same, you will get probably lost and return to down-climb your hierarchy.

Also, in larger environments your customers will probably have own naming conventions for their devices, which should probably be obeyed in PRTG. This would increase usability and acceptance for the administrators.

This feature could add value to your auto discovery, which will in most environments require manual intervention after each change, if you want to follow a consistent naming scheme. For ex, if you configure auto discovery for hypervisors (where scheduled auto discovery is especially helpful), auto naming of newly discovered guest devices and their sensors could entirely eliminate the need of manual name correction.

I bet i could find a lot lore argument for this feature. I would be thrilled if you could evaluate it for implementation.

Acceptance criteria

• Criterion #1
• Criterion #2 This basically gives us a set of cornerstones that need to be there in order for the feature to be implemented.

Status

Open

add-feature enterprise improve-prtg naming prtg-kbtracker