OneAgent & Security Gateway release notes v1.147

OneAgent

Java

  • Improved performance of Cassandra monitoring for Java applications (reduced data sent to Dynatrace SaaS/Managed and less resource usage on Dynatrace Managed clusters)

General improvements and fixes

  • It’s now possible to deploy OneAgent via Docker containers on Google Container Optimized OS (Google COS). This functionality is currently available in an Early Access Program (EAP). This is an important step towards smooth deployment and monitoring of Enterprise Cloud solutions, specifically Google Kubernetes. Read more about this EAP.
  • We’ve added monitoring support and detection of Google App Engine flexible (custom) environments (beta release). Read more about support for Google App Engine.
  • We’ve added the ability to define additional process-group metadata for Cloud Foundry applications. To define such metadata, you can leverage one or more Cloud Foundry service instances that have the name dynatrace as a substring. For example, cf cups dynatrace-metadata -p "meta-data:owner".
  • Redis monitoring is now also supported for Cloud Foundry.
  • Installation of OneAgent on RedHat Enterprise Linux (RHEL) 7.5 and Ubuntu 18.04 LTS has been tested and works properly.
  • We’ve improved the resiliency of OneAgent installation in cases where non-root mode deployment is used (read more about this mode) by adding a check mechanism for file capabilities.
  • For processes running on Linux, we’ve enhanced OneAgent so that it now properly detects exec. Typically when processes on Linux invoke other processes, they use fork and exec in combination. We’ve recently observedexec without fork appearing in the context of some container technologies. As of OneAgent v1.147, we’ve added support for the detection and monitoring of this type of process. This change is completely transparent to users.
  • OneAgent now collects additional metadata related to BOSH deployments within Cloud Foundry environments. Stay tuned for more detailed CloudFoundry reporting, coming soon.
  • We’ve implemented significant performance improvements for cases where OneAgent queries Docker APIs. These improvements significantly speed up the polling process.
  • We’ve also implemented a solution for monitoring multiple network bridges on Docker containers on Linux. Until now, we’d expected only one Docker bridge interface. Previously, in cases where a host had more than one bridge network, and connections inside or between bridge networks, only those connections inside the first identified bridge network were marked as “interdocker connections.”
  • We’ve improved how OneAgent identifies Azure VMs, by querying the Azure Instance Metadata service. We also now report on Azure’s vmId and subscriptionId.
  • We’ve continued improving the MSI-file based approach to OneAgent installation.
  • We’ve also added a number of smaller updates related to how AIX metrics are calculated. Read more about our public beta for AIX full-stack OneAgent.
  • OneAgent can now correctly pass process commands, even following command re-naming within Redis snapshots on the Pivotal Cloud Foundry Platform.
  • OneAgent now collects the OS level EXE_NAME attribute of detected and monitored processes. As a consequence, it’s now possible to additionally configure process group names using the EXE_NAME attribute (in addition to, or in place of, EXE_PATH). For full details, see our custom, automated process-group naming blog post.
  • OneAgent now recognizes and monitors Docker containers running in default host PID namespaces.

Security Gateway

  • Security Gateway is now installed with more secure folder access permissions for configuration, log, and temp folders. We use the sticky bit feature of the Operating System to limit unwanted access.
  • The Security Gateway team has also implemented a number of minor behind-the-scenes improvements related to Azure monitoring.

Important bug fixes

With this release of OneAgent and Security Gateway, we’ve resolved the following issues:

  • APM-129438 – OneAgent crashes in some instances of non-root deployment mode (read more about non-root mode).
  • APM-130598 – In non-root mode, a OneAgent module didn’t fall back to root mode following checks that the minimum operating system version wasn’t installed.
  • APM-131170 – The OneAgent auto-update mechanism didn’t work on systems with ambient capabilities and SysV init in case of non-root deployment mode.
  • APM-130133 – Path to 32-bit libraries wasn’t properly detected on SLES 11 SP4.
  • APM-128073 – RabbitMQ cluster was incorrectly detected as type Erlang.
  • APM-129963 – Crash reports were kept for only one day, which is not enough time for analysis. Crash reports are now kept for 3 days.
  • APM-124692 – Security Gateway installer was limited to the creation of only 1,024 file descriptors that have error messages in the log files.

Upcoming beta releases

Stay tuned for two upcoming beta releases:

  • OpenStack infrastructure monitoring
  • Docker for Windows (Windows Server Container) monitoring and injection

Our development teams have been working on these beta releases over the past several sprints. We’re now in the final phase of testing. We’re very excited to be able to share these improvements with you very soon.

Bartek is Senior Technical Product Manager at Dynatrace. He's worked on APM and ALM products for over 17 years. His background is in software development, but he's also passionate about user experience, process optimization, and delivering value to customers. Outside of work, Bartek enjoys travel, photography, jogging, and is CEO of a retro gaming and computing society that organizes public events and exhibitions. Proud father of three daughters.

Looking for answers?

Start a new discussion or ask for help in our Q&A forum.

Go to forum