6.OneAgent 升级规划

6.OneAgent 升级规划

GSP-UPG-212_OneAgent Upgrade Planning
Understanding and thoroughly documenting your current OneAgent deployment will ensure a successful SaaS upgrade.
To begin, create an updated list of all current OneAgent instances.
Remember that OneAgents can be installed on nearly any host, operating system, cloud, or other container platform.
Therefore, a complete accounting of the existing OneAgent installation will ensure a smooth transition with no data loss.
Next, note whether any OneAgent extensions were implemented in your environment.
A reminder of how to create and implement extensions is available in our online documentation.
If OneAgent-enabled hosts have been organized by host groups, ensure that a list of those configurations has been noted in the upgrade plan.
Likewise, if customized tags or metadata have been defined, include a list of those configurations as well.
Network zone design should be considered to allow for the most optimized routing of telemetry data, including configurations for failover behavior.
And finally, determine where you wish your SaaS platform to be hosted, and make a plan to re-home data as needed.
Since the Dynatrace platform operates on clusters deployed in different regions of the hyperscalers, you have control over where your data will be hosted.
Once you have a complete list of all OneAgents and their versions, you will need to determine whether to update the OneAgents in place or re-install the software in the new SaaS environment.
The OneAgent software version will significantly affect the ability of the agents to connect to the Dynatrace SaaS platform, as well as determine what methods are available for upgrade.
If possible, update your existing Managed OneAgent software to the latest version.
We recommend automating the deployment of OneAgents: this ensures that specific installation parameters such as SaaS tenant ID and token, network zones, host groups, custom metadata, and the like can also be automated.
To automate OneAgent deployment, you may wish to consider using the “Migrate OneAgent” tool, also known as the one agent ctl command-line interface.
On the other hand, if you choose to re-install the software in the new SaaS environment directly, plan to update any host-level required software beforehand, and do your best to minimize configuration changes just before migration.
Regardless of the OneAgent upgrade methodology you select, make note of which of your environment configurations, such as deep-monitoring settings, custom process monitoring rules, and container injection rules should be migrated before OneAgents.
Similarly, some entity-level configurations can only be migrated after OneAgents, for example, custom settings associated with an entity that has not yet been generated in the new SaaS tenant.
Processes should be restarted as soon as possible after the OneAgent migration so that the agent can successfully be injected into the application processes and services appear in the new SaaS tenant.
This is especially important for full-stack OneAgents and infra-only OneAgents where the Application Security module or JMX metrics are enabled.