We are planning to rename some System Profiles and would know what are exactly the consequences:
Solved! Go to Solution.
I'm using Appmon 6.5.3
P.S: Maybe one alternative to rename a System Profile is to create a new System Profile and relocate agents? But how it is have to be done using the same names for it's agents?
I recently faced a similar scenario, I walked into customer site a Monday morning just to find out nobody could have access to Purepaths stored before the name change.
Dashboards were working as expected, but because the name reference in the saved sessions didn't match with the new name in the System profile, we couldnt access previous data.
Because nobody told me about this change, we had to go with the workaround, copy the system profile and rename it with the old name just to access the old data. Eventually we didn't have the need to go back that long anymore and we could discard the copy.
As long as the performance warehouse (PWH) is connected no historical data is lost. The PWH stores historical time series data i.e. this applies only to data that is visualized in charts. Dashboards are automatically updated as long as they are stored on the AppMon server. Locally stored dashboard will still reference the old system profile and may therefore require manual changes (a warning is displayed if there should be still a reference to the old system profile).
Dynatrace AppMon records information about type hierarchy whenever types are loaded within Java and .NET process. This information is required to interpret sensor rules that are based on type hierarchy. During a rename of a system profile this information gets lost and has to be recorded again.
To guarantee that complete type information is available again when new classes are loaded a "discovery run" is recommended. A discovery run is the execution of the application with injected Dynatrace agent that covers startup and all or most of the application functions.
If you do not have any Java or .NET processes no action is required. For all Java and .NET processes, you have to restart the processes as soon as possible after the renaming and ensure that most of the application functions are used. Only after this, it is guaranteed that all sensor rules work as expected at the next startup of the process.
In contrast to time series data, transactional data (i.e. PurePaths, User Actions and Visits) is stored in the continuous transaction store. This data will not be accessible anymore after a rename of the system profile. There is no easy workaround, e.g. by renaming any files or folders. But as Axel already suggested, you can at least make historical data accessible through a copy of your system profile with the old name. Old transactional data (before the renaming) is accessible by selecting the system profile copy with the old name as data source, new data is available by selecting the renamed system profile as data source. Old transactional data will get replaced over time by new data until complete covered time frame (depends on your load and amount of available disk space) is accessible through new system profile.
To avoid that agents get accidentally assigned to the system profile copy, please disable the system profile copy in the Cockpit.
If you should have long running processes, please also restart your Collectors after renaming the system profile. Otherwise configuration changes for agents that are assigned to the renamed system profiles will not be pushed to the agents until the processes get restarted.