We recently migrated all of our java services to new hosts with an upgraded OS version. Instead of updating the hosts/properties on our existing services, Dynatrace automatically created new process groups and services and did not migrate our settings. This created a host of issues.
None of our service settings are showing on the duplicate services. Request naming rules are not working. Many request attributes were tied to a process group and are now all broken.
All of our multi-dimension analysis rules are also not present, as they were on the original service and did not get auto-migrated to the new.
When I tried to pin attributes to a service or process group, I now see two of every service in the list, and don't know which is the correct one without trial and error on every single service.
Why did Dynatrace create duplicates of all our services, and is there something we could have done to prevent it or ease the migration pain?
Answer by Sebastian K. ·
In general if for Example command linę arguments, binary location, host group or other things changed during migration, this is behavior that should may be expected. This is because Dynatrace detects it as some new process that has nothing in common with old one. There is no option for merging process groups. Not all services may be merged. In general new process group always results with separate set of services. You can use configuration API in dynatrace to migrate some of configurations. Not all endpoints that you may need exists, but there is always something.Old process should not be visible when You have timeframe that not covers their existence. If you don’t have agents on old hosts that, they should disappear almost instant. Only archival data will be possible.
DIagnose CPU Usage for .NET Application 2 Answers