Renaming a service should include moving perfdata

37 votes

There are multiple reasons why a service gets renamed: Either because tribe29 changed the way the service name gets generated (mostly to make it more defined, ie include volume name in netapp_api_qtree_quota) or because the customer changes something (like going from if index to alias/descriptions)

There should be at least a command line tool I can give a simple CSV with instance, host, old service and new service names which does the renaming for me. Workflow could be to change the naming rules (or apply the update with the check causing the change), run inventory on the host, create CSV with the proposed new and vanished service name data, accept the changes, and the tool would stop the instance, rename the files and starts the instance.

Best would be to auto detect these changes, but that would surely include changing the way check data is generated, like including an invisible GUID for every check. Going purely by name changes wouldn't work I think.

Under consideration Graphing Usability Suggested by: Christian (14 Jun, '22) • Upvoted: 09 Apr • Comments: 3

Comments: 3

20 Jun, '22
Robert Sander
The issue here is that as soon as the configuration would use the new service name there is no connection to the old service name any more.
02 Jul, '22
Marsellus Wallace
Do you really think perfdata is the only needed change here? What about monitoring events (state changes, downtimes, notifications, etc.)?
20 Jul, '22
Daniel Roettgermann
@Marcel
fully agree - all data needs to be renamed as for all reports, data would be gone too.
Same goes when moving a host/service from one site to another - all data is gone
https://features.checkmk.com/suggestions/316727/copy-graph-history-and-checks-to-new-site-when-changing-a-hosts-monitoredon-site
1