Further improved handling and reliability of OneAgent deployments

Dynatrace OneAgent deployment and life-cycle management are already widely considered to be industry benchmarks for reliability and efficiency. OneAgents can be deployed via a single command execution or a double-click. Deployment performs the whole rollout, instrumentation, configuration, connection, and automatic detection of monitored entities in your environment. The same default deployment approach applies to all future updates, too—the experience can best be described as “fully SaaSified.” Meaning, you don’t need to worry about OneAgent updates because they’re performed automatically, safely, and promptly as soon as new versions are available (no manual effort required).

However, the great feedback we’ve received so far hasn’t stopped us from improving OneAgent deployment even further. Readers of this blog surely appreciate the earlier enhancements we announced related to enterprise-scale life-cycle management of OneAgents via REST API, easier configurability of OneAgent settings, and the recent improvements to OneAgent security. Note that most of the changes we’ve introduced so far and those that are detailed below are all designed to be invisible to you, taking place entirely automatically in the background.

In this article we’ll share highlights about two increments that are likely to fall into the “barely noticeable” category. However these improvements are of critical importance for those who have been exposed to the problems that these improvements are designed to solve.

• Easier rollout thanks to log storage best practices

We’re now allowing for even easier OneAgent rollout by freeing up the /opt mount point from any runtime data that’s produced by OneAgents.

• Advanced customization of OneAgent deployments made easy

For customers who need to have their deployment customized beyond the defaults, we’ve introduced Advanced mode, which enables you to deploy OneAgents easily, without having to remember the syntax of installation parameters.

Easier rollout thanks to log storage best practices

In an earlier article we explained the recent improvements in OneAgent handling of large runtime data as well as related file-location customization capabilities. We’re happy to announce that we’ve made another small, but very important improvement in this area.

Starting with OneAgent version 1.203, we’ve changed the location of the OneAgent logs (the actual log files that OneAgent produces for its own diagnostic purposes, not the third party log files that OneAgent is capable of monitoring) to now use the /var/log/dynatrace/oneagent directory. In OneAgent versions 1.202 and earlier, the logs of OneAgent modules were stored in the /opt/dynatrace/oneagent/log directory, which didn’t really adhere to best practices and standards. The /opt directory is typically used for deployment of additional software running on the Unix system. As such, it’s quite often a network-shared mount point that multiple hosts use to store third party software and libraries. Keeping the runtime data in the /opt directory made it cumbersome to maintain.

Now that the logs are saved to a standard /var/log location, and considering the changes that we made to the default location of other runtime data (mentioned in an earlier article), the /opt mount point is now free from any runtime data produced by OneAgents.

What does this mean for existing installations?

The migration of the logs storage directory will happen automatically upon the update to OneAgent version 1.203; so there is really nothing you need to do. Upon migration, existing logs are moved to the new location and a symlink pointing to the new location is created in /opt/dynatrace/oneagent/log. Also, the creation of Dynatrace support packages now effectively uses the new log location transparently.

Please note that the OneAgent update process may require that the injected OneAgent modules (for Java, .Net, Apache, etc.) have their monitored services restarted in order for the new version of each module to kick in and effectively change its log directory destination. For this reason you may see logs continue to be written to the /opt directory until all such modules are restarted following the update to OneAgent version 1.203.

As a consequence of this change, OneAgent now needs to be able to write to the /var/log directory. Therefore a traverse access to that directory must be provided for all the users in the system, including, but not limited to the user under which the OneAgent is installed, as well as for the users who own all the deep-code-monitored processes (Java, .Net, Apache, etc.), because the OneAgent modules injected there are effectively owned by the respective users.

Also, for containerized full-stack OneAgent deployments that use volume-based storage, the OneAgent container image needs to be updated (pulled) to version 1.45.1000+ before the update to OneAgent version 1.203+. Otherwise OneAgent will create log directories on the host as there will be no /var/log mount created by the image.

Please note that all OneAgent logs are auto-rotated. If your /var directory runs short on capacity, OneAgent will simply shorten the time span of information stored in the logs. This may affect our ability to perform support-case analysis of past events, but your environment will remain stable.

Important note: We’ve received feedback from several of our largest customers requesting that the location of the log storage directory be configurable, similar to other runtime storage directories. Thank you! We plan to deliver this enhancement soon. Please stay tuned for more updates on this topic.

Advanced customization of OneAgent deployments made easy

One Dynatrace design principle that we take very seriously, is “zero config and smart defaults.” What this specifically means for OneAgent deployment is that you can use the default deployment settings. OneAgent will not only know where to connect, it will also automatically start detecting and monitoring OS and running processes, and it will immediately send the measurements to Dynatrace Cluster, all with no manual effort.

But what if you need to have your deployment customized beyond the defaults? Dynatrace documentation lists several additional parameters that the installation process accepts (the link points to Linux customization, but other OSs are supported in a similar way). It’s great to have such parameters, but it’s not so great to have to remember them or check the documentation every time you need them. This is why we introduced two modes of deployment for OneAgent, both of which are displayed on the “Deploy Dynatrace” setup pages.

Default mode – Zero config and smart defaults

The default mode is largely unchanged from what you’re already familiar with. Just download the installer, check the signature (optional step), run the installer, and you’re done. It couldn’t be simpler, really.

Here is how it looks in the case of Linux deployment (while the two screenshots shared here are taken from OneAgent deployment for Linux x86, the process is very similar for Windows and AIX, as well as for other Linux hardware platforms).

Advanced mode – Don’t worry about remembering the syntax of installation parameters

Advanced mode lets you configure the most popular installation settings visually in the web UI. The install process not only takes care of the installation parameter names and the syntax, it also suggests some of the values. You can also easily choose an existing network zone or host group.

To enter advanced mode, expand the section that’s hidden under step 3 (see below). This section contains the UI that guides you through the process of defining additional optional settings which may be important depending on the type of deployment you’re performing.

Here’s how it looks:

Please note that by defining the additional settings, you’re actually changing the invocation parameters of the installer script. This way you can set the parameters easily but also learn how to use them in practice without the potentially tedious process of studying the related documentation. Learning about the usage patterns of these settings will help you later if you decide to automate the deployment process (which Dynatrace can also assist you with, as explained in our recent article about Ansible-based deployment).

Did you forget to change these settings prior to installation? No problem. You can do it later using the OneAgent CLI (command-line interface) called oneagentctl.

What do you think?

As always, we welcome your feedback and comments. Please share your thoughts via Dynatrace Community, directly within the product through Dynatrace ONE chat, or with your Dynatrace Account Manager.