This post was originally published on this site

In parallel to the continuous stream of new improvements related to Dynatrace monitoring capabilities, we’re also continuously improving our internal mechanisms. Our goal is to make Dynatrace as easy to use and as compliant with industry standards as possible. This is why the Dynatrace Software Intelligence Platform is recognized as a market leader not only for monitoring coverage, but also, very importantly, for providing the shortest time-to-value.

This blog post highlights a group of improvements that were released with OneAgent version 1.199.

Recent improvements in OneAgent runtime-data handling

Customizable location of large runtime files

Operating Systems are not always set up in the same way. Storage mount points in a system might be larger or smaller, local or remote, with high or low latency, and various speeds. Until now, all OneAgent runtime files were stored in a fixed, hard-coded location. Sometimes these locations landed on mount points which, due to capacity, availability, or access constraints, weren’t well suited for large runtime storage.

Starting with OneAgent version 1.199, the runtime folder is configurable and consequently you can retain your storage mount point setup as-is. See details below

Improved code module injection resiliency

We’ve redesigned how binary files for some Dynatrace modules are stored on hard disk. As a consequence, the automatic updates as well as the automatic deep-code monitoring injection processes are even more stable.

While Dynatrace OneAgent has been the best solution on the market for some time already, when it comes to the automation of monitoring instrumentation and hands-free update processes, we’ve now put even more distance between ourselves and competing solutions. See details below

Smaller OneAgent installer size

Storage and network transfer of files is a measurable cost. At Dynatrace, we pride ourselves on providing a low-impact solution for monitored environments. By reducing the installer size without compromising on functionality, we’ve effectively, once again, delivered on our low-impact promise. See details below

New default installation path of OneAgent on Windows

Another consequence of the recent discontinuation of support for 32-bit operating systems is the new default location of OneAgent for Windows. See details below

Customizable location of large runtime files

While in operation, Dynatrace OneAgent produces a number of large runtime files, namely crash reports, memory dumps, and support alerts (internal OneAgent support mechanisms that assist in the detection and analysis of customer support cases).

In OneAgent version 1.199, we changed the default location of runtime files to the industry standard location (/var in the case of Unix systems and %PROGRAMDATA% in the case of Windows systems), though the installation location can easily be customized via an install parameter.

To better illustrate the benefits of the solution, let’s consider the following scenario. OneAgent is deployed on a Linux host where some of the standard folders are mapped from network drives while some are provisioned as local drives with limited storage. For example:

  • All subfolders of the /opt directory are mounted as local, low latency, high-throughput drives, with relatively low storage capacity.
  • All /var subfolders are mounted as local, low latency, high-throughput drives of larger storage capacity.
  • There is an additional /mnt/storage network drive mount that is available for high latency, large storage purposes.

In such a scenario, your deployment should likely have all OneAgent binaries stored in the /opt folder and all runtime data stored in the /var folder (or, alternatively, in the /mnt/storage folder if you expect this folder to grow to a substantial size due to numerous memory dumps caused by unstable service crashes). In this way you can satisfy the latency and throughput limitations of the network drives but also benefit from the local /var storage without storing non-runtime data there.

In previous OneAgent releases, all the runtime files mentioned above were stored in the /opt folder. This made it impossible to change the path via the install parameter. In other words, even if you customized the installation by providing the INSTALL_PATH parameter, the runtime data location was still hard-coded for storage in the /opt subfolders.

Starting with OneAgent version 1.199, you can independently control the location of binary files using the INSTALL_PATH parameter. You can also control the location of runtime files using the newly introduced DATA_STORAGE parameter.

In real-world deployments, the breakdown of binary files and runtime data between /opt and /var, as described in this example, is widely considered to be good practice and an industry standard. These are also the defaults that are used in absence of the INSTALL_PATH and DATA_STORAGE installation parameters.

Note: In OneAgent versions 1.199+, the location of the log files is still in the /opt subfolders. We’re working to have these log files stored by default in the /var subfolders, in accordance with industry standards. Stay tuned for upcoming news about these changes.

Improved code module injection resiliency

In addition to these runtime files, OneAgent also produces a number of file artifacts during the update process, specifically in cases of injectable technology modules. The latest release includes a redesign of the way that these files are created. All injectable module files are now stored in versioned folders. This mechanism allows for a more reliable update process, especially in cases where the filesystems where the OneAgent is deployed are non-standard (some implementations of NFS were discovered to be rather unpredictable) and might impose file lockdown in cases where it’s actively used. In the past, such filesystems prevented the update process from being successful.

With the current solution, all code modules are versioned. This effectively increases the update process resiliency for injectable modules, but it also makes it easier to diagnose potential support problems in cases where an injected technology was not restarted shortly following the update process and so the instrumentation is based on an outdated OneAgent module.

In addition to the above benefits, all versioned folders are automatically cleaned up, leaving several older versions of OneAgent injectable modules on the disc. For more details on this mechanism, please see this Dynatrace Answers thread.

Smaller OneAgent installer size

As a result of recent changes to supported Operating Systems versions, and most importantly the decision to drop support for all 32-bit operating systems, which was announced several months ago, the size of the OneAgent installer is now significantly smaller:

  • The Linux version of OneAgent has been reduced in size by over 20%.
  • the Windows version of OneAgent has been reduced in size by over 15%.

What does this mean in practice? As a result of the smaller installer size, our customers can now save on download time and storage space. This means faster updates and lower total cost of ownership. All of this without any reduction in OneAgent functionality (in fact, we’re expanding the capabilities of OneAgent with each new release).

As OneAgent grows in capabilities and power, we’ll keep a watchful eye on its size. Further optimizations are likely to happen in the future.

New default installation path of OneAgent for Windows

Starting with OneAgent version 1.199+, the legacy folder C:Program Files (x86) is no longer used, and the installer instead defaults to C:Program Files. Note that using this installer parameter you can customize the location of the deployment folder as needed.

Upon update from older versions of OneAgent to version 1.199, the existing files will remain in C:Program Files (x86) to provide backwards compatibility with potential scripting that your organization might have built on the target hosts. Also, all the installations performed in the custom path (via the INSTALL_PATH parameter) will remain unaffected. In order for the existing OneAgent to be migrated to C:Program Files, it needs to be updated with an installation/update parameter that points to the new location.

Feedback or questions?

We hope that these new enhancements, while small, will make it easier for you to deploy and manage your OneAgents, especially in large and security-focused environments. If you have questions or comments, please reach out to us via Dynatrace Answers, Dynatrace ONE product-specialist chat in the Dynatrace web UI, or via your Dynatrace Account Manager.

This syndicated content is provided by Dynatrace and was originally posted at https://www.dynatrace.com/news/blog/faster-time-to-value-with-enhanced-handling-of-oneagent-runtime-data/