Easily migrate your OneAgent from one tenant or server to another

We're happy to announce a bunch of new operations that are exposed and officially supported by the oneagentctl CLI tool.

Deployment of OneAgent is really easy. You just run the installer—no parameter configurations required—and OneAgent takes care of the rest. OneAgent knows where to connect for further runtime configuration and where to send data because the installer itself is pre-configured to connect to the exact tenant and server that it’s downloaded from. Dynatrace strives for complete automation of all the things that can be automated, and this is a great example of this philosophy in action.

But what if your environment grows and you decide to distribute data between two Dynatrace servers? An example of such a split is maintaining separate staging and production environments. And what if you need to migrate OneAgent from one server to another? To let you easily reconfigure OneAgent on-the-spot, we released a GA version of a CLI (command line interface) tool called oneagentctl a couple of months ago

We’re happy to announce a bunch of new operations that are exposed and officially supported by the oneagentctl CLI tool.

Migrate your OneAgent, reconfigure its connections, and more

With the following new operations, you can easily and safely reconfigure your OneAgent, edit its connections, and check the current connection settings.

“Getters” allow for read operations

--get-tenant – When invoked with this parameter, oneagentctl returns the current Dynatrace environment ID. You received this ID with your activation email. By default, this setting is already set to the correct value. If your organization sells Dynatrace-based services, use this option to set your customers’ IDs (available from the pool of IDs that you purchase from Dynatrace).

--get-tenant-token – When invoked with this parameter, oneagentctl returns the current internal token that is used for authentication when OneAgent connects to the Dynatrace cluster to send data. You can also retrieve the tenant token from the following REST endpoint. In return, you get a JSON object that includes the >TENANT_TOKEN.

https://<ENVIRONMENTID>.live.dynatrace.com/api/v1/deployment/installer/agent/connectioninfo?Api-Token=<PAAS_TOKEN>

Be sure to replace <ENVIRONMENTID> and <PAAS_TOKEN> with the proper values.

--get-server – When invoked with this parameter, oneagentctl returns the address of the Dynatrace Server. Depending on the settings, this can either be a fully qualified server name or an IP address followed by a colon and the port number, for example http://100.20.10.1:8443.

--get-proxy – When invoked with this parameter, oneagentctl returns the address of the proxy server. Depending on the settings, this can either be a fully qualified server name or an IP address followed by a colon and the port number in the IPv4 or IPv6 address pool. This parameter returns an empty string if the proxy isn’t set.

“Setters” allow for reconfiguration

--set-tenant <environment-ID> – This is a counterpart operator to --get-tenant. It allows for the environment ID to be configured. Always use in combination with --set-tenant-token.

--set-tenant-token <tenant-token> – This is a counterpart operator to --get-tenant-token. It allows for the tenant token to be configured. Always use in combination with --set-tenant.

--set-server <server-address> – This is a counterpart operator to --get-server. It allows for the server address to be changed.

--set-proxy <server-proxy> – This is a counterpart operator to --get-proxy. It allows for a proxy to be configured, if needed.

Note that all the get operations can be performed while OneAgent is running, but the set operations require that OneAgent be stopped before use and restarted afterwards before the changes go into effect. oneagentctl alerts you to the stop-set-start sequence if used incorrectly. Operations can be combined into a single CLI invocation.

Additional features

In the OneAgent 1.185 version of oneagentutil, we also provide the following additional “getters” and “setters”:

--get-app-log-content-access and --set-app-log-content-access – These operators allow for reading and setting of log content access. This setting is equivalent to the APP_LOG_CONTENT_ACCESS parameter, which is passed during OneAgent installation (see Linux parameters).

--get-system-logs-access-enabled and --set-system-logs-access-enabled – These options allow for reading and setting of system log access. This setting is equivalent to the DISABLE_SYSTEM_LOGS_ACCESS parameter, which is passed during the OneAgent installation (see Linux parameters).

--get-watchdog-portrange and --set-watchdog-portrange – These operations read and change the range of open ports that the OneAgent Watchdog keeps open. By default, the Watchdog tries to open ports in the range of 50000:50100. If however there is the possibility of an open port conflict with any other application, and this application doesn’t have a graceful mechanism for handling such cases, you may want to move the range to another location. It’s recommended that the range span across 100 ports, just as the default. OneAgent will gracefully detect and omit any open ports in this range. See more about OneAgent troubleshooting

Wait, there’s more (coming)!

The 1.185 version of oneagentctl described in this article is available to all Dynatrace customers who have OneAgent version 1.185 and above. But we’re not done yet. The next version is already on its way. It will bring even more useful operations for reading and setting OneAgent configuration. So stay tuned for future updates on this topic!

See the current list of all oneagentctl operators

Feedback?

As always, we welcome your feedback and comments. Please share your thoughts via Dynatrace Community, your Dynatrace Account Manager, or from within the Dynatrace web UI—just start a chat with a Dynatrace ONE representative. We look forward to hearing from you.