OpenShift Ecosystem: Monitoring OpenShift Apps with Dynatrace (Part 2)

In our previous article, we explored how highly dynamic, distributed microservices environments demand a more sophisticated approach to monitoring and how we’ve designed Dynatrace to leverage artificial intelligence in addressing these requirements. We also explained how to roll out Dynatrace OneAgent to your OpenShift cluster nodes using Ansible.

In this article, we’ll explore various alternatives to monitoring your OpenShift applications when installing Dynatrace OneAgent on your cluster nodes isn’t an option. This situation arises when using managed cloud offerings, such as OpenShift Dedicated or the OpenShift Online Developer Preview.

How to install Dynatrace OneAgent for PaaS

Dynatrace OneAgent for PaaS enables you to selectively monitor the components of your applications — and the relationships between those components — by integrating OneAgent for PaaS directly into each containerized application process. And while the alternatives presented here address different use cases, each approach is made possible via a convenient configuration and installation of Dynatrace OneAgent for PaaS.

Configuration and Installation

export DT_TENANT={my-tenant}
export DT_API_TOKEN={my-api-token}
curl | sh

Be sure to replace DT_TENANT and DT_API_TOKEN with your environment’s actual values. You’ll find your environment ID and API token on the PaaS Integration page (see below).
Dynatrace PaaS Integration page screenshot
The following optional settings can better prepare OneAgent for injection into your OpenShift applications. By defining settings for your specific monitoring requirements, you can decrease the download size of the OneAgent for PaaS installer.

Name Defaults Description
DT_AGENT_PREFIX_DIR /var/lib The installation prefix location (which will contain OneAgent in the dynatrace/oneagent subdirectory).
DT_AGENT_BITNESS 64 Can be one of {“all”, “32”, “64”}.
DT_AGENT_FOR all Can be any of {“all“ | “java“ | “apache“ | “dotnet“ | “iis“ | “nginx“ | “nodejs“ | “php“| “websphere“} in a comma-separated list.


Once you’ve configured the OneAgent for PaaS installer, the next step is to load OneAgent with the processes you want to have monitored by Dynatrace. Let’s assume you want to instrument a Java application with OneAgent available at /var/lib/dynatrace/oneagent. To do this, all you need to do is prepend either or, depending on whether your application runs in a 32-bit or 64-bit process, to your application startup command.

/var/lib/dynatrace/oneagent/ java $JAVA_OPTS -jar myapp.jar

Now that was easy, wasn’t it?

How this fits into your OpenShift workflows

Now, let’s take a look at how all this integrates into your OpenShift workflows.

Option 1: Reconfigure your deployment

With such a lightweight integration process, you can easily chain commands and invoke them in a shell inside your containers. Here’s what command chaining looks like using the previous example:

(curl | sh) && 
/var/lib/dynatrace/oneagent/ java $JAVA_OPTS -jar myapp.jar

When you create your OpenShift applications using oc new-app you’re creating a deployment configuration (essentially a replication controller that provides useful deployment capabilities) that triggers a new deployment whenever application settings change. Using oc patch, you can merge Dynatrace into a live application and let the deployment configuration handle the required application restart.

oc patch dc/{my-dc-name} -p '
       - name: {my-container-name}
         - /bin/sh
         - "-c"
         - "(curl | sh) && /var/lib/dynatrace/oneagent/ java $JAVA_OPTS -jar myapp.jar"
         - name: DT_TENANT
           value: {my-tenant}
         - name: DT_API_TOKEN
           value: {my-api-token}

If deployment configurations aren’t practical for your specific use case, don’t despair. OpenShift offers many other ways of working with configurations, such as oc edit, oc get and oc replace.

Option 2: Source-to-Image (S2I)

s2i is a nifty utility used for creating Docker images from application sources. If this is what you’re using to have your Docker images built and eventually moved into production, then why not include Dynatrace OneAgent for PaaS in these images right from the start?

Without your input, S2I doesn’t know how to build and run your applications inside containers. Upon execution, S2I looks for a set of scripts (most notably assemble and run) in your source code repository. As you may have already guessed, integrating with S2I is a no-brainer.


# build the application

# install Dynatrace
export DT_TENANT={my-tenant}
export DT_API_TOKEN={my-api-token}
curl | sh


# run the application
/var/lib/dynatrace/oneagent/ java $JAVA_OPTS -jar myapp.jar

If you’re new to S2I and are curious about its capabilities, please have a look at this great Source-to-Image Deep Dive provided by Ben Parees.

Option 3: Dockerfile

If deployment configurations aren’t your thing, and you’ve had no time to experiment with S2I, don’t worry. Good old Dockerfiles aren’t going away anytime soon. Here’s a solution that will work for you:


FROM java:latest

ADD myapp.jar .

# install Dynatrace
ENV DT_TENANT "{my-tenant}"
ENV DT_API_TOKEN "{my-api-token}"
RUN curl | sh

# run the application
CMD ["sh", "-c", "/var/lib/dynatrace/oneagent/ java $JAVA_OPTS -jar myapp.jar"]


In this series of articles we’ve demonstrated how to monitor your OpenShift clusters and the applications running on them using Dynatrace OneAgent. Setup is easy, no matter if you’re using OpenShift in a private, public, shared, or dedicated environment.

Interested in giving Dynatrace a try? Sign up for the Dynatrace free trial!

Are there other options you’d like to see discussed here? Have questions, suggestions or feedback? Reach out to Martin Etmajer, Dynatrace Technology Lead for OpenShift. He’ll be happy to answer your questions and share further insights.

OpenShift Dedicated, OpenShift Ecosystem, OpenShift Online
, ,
Comments are closed.