DYOC: Agentless RUM, OpenKit, Metric ingest, and Business Analytics

This year I wrote two open-source apps for Dynatrace users. As they gained in popularity, now hundreds of users each, so did the pace of new feature requests. So too did the risk of introducing bugs with all the rapid change. Wouldn’t it be great if I had an industry-leading software intelligence platform to monitor these apps, pinpoint root causes of slow performance or errors, and gain insights about my users’ experience? At Dynatrace we live and breathe the concept of “Drink Your Own Champagne” (DYOC), so of course, I want to use Dynatrace to monitor my apps. But these are not your traditional apps; there’s nowhere to install OneAgent. How can I gain all the great insights of Dynatrace without the magic of OneAgent? Agentless RUM, OpenKit, and Metric ingest to the rescue!

App architecture

First, let’s explore the architecture of these apps:

BizOpsConfigurator

BizOpsConfigurator allows Dynatrace users to deploy over 50 bespoke dashboard packs. Users choose from pre-built dashboard templates, pick a few options (populated from the Dynatrace API), and quickly deploy highly customized and linked dashboards in under a minute. It’s structured as a single page app (SPA) and hosted on GitHub Pages. There are no hosts, no backend, no database – just HTML, CSS, and JavaScript. The app pulls all of the data from GitHub and Dynatrace APIs.

Dashboard Powerups

Dashboard Powerups allows Dynatrace users to try out over 20 experimental dashboard visualizations. Think of things like heatmaps, Sankey charts, etc. The app is structured as a Chrome Extension. Again, no backend, etc. – just JavaScript and CSS.

Chrome Extensions run JavaScript in a separate context, essentially in an “isolated world”. This means that JS running in the Extension context can’t see or change JS variables running in the webpage context and vice versa. In the webpage context, Dynatrace dashboards already have Real User Monitoring (RUM), as part of self-health monitoring. But, this doesn’t cover the JavaScript portions running in the Extension’s context. This also, unfortunately, alerts our product developers instead of me if the app causes an error on the dashboard.

Agentless RUM

We all love the magic of OneAgent, but yes, you can definitely monitor web applications with Dynatrace, even in places OneAgent can’t go. Agentless RUM allows you to monitor your front-end apps by simply pasting a JavaScript tag into your code. Side note: it’s called “agentless,” because no OneAgent is running on the server that hosts the HTML, CSS, and JavaScript files

With that simple copy-paste, I now have all the performance, errors, and user experience data for BizOpsConfigurator!

OpenKit

For Dashboard Powerups we cannot use Agentless RUM as we did above for two reasons:

1) RUM is already injected into the webpage context

2) we need to monitor both contexts as one app.

Ok, so we can’t use OneAgent or Agentless RUM…now what? OpenKit provides an easy manual alternative to handle any other one-off scenario you might run into. In fact, Dynatrace customers use OpenKit to monitor many digital touchpoints like ATMs, kiosks, and IoT devices. With the SDK you wrap your application code to report Sessions and Actions. For Powerups, an Action is reported each time a dashboard is PoweredUp and is part of a Session.

To capture important monitoring data from both the webpage and extension contexts, OpenKit should be inserted into the extension context in a background script. Message passing should be used to get the monitoring data from the webpage context to the extension. Window.postMessage is used to pass a message from the webpage to the extension and chrome.runtime.sendMessage is used within the extension.

Additionally, you can report an error caught from a try/catch block as either an error or a crash.

Now we have performance and errors all covered:

Business Analytics

Now that I have visibility into performance and errors, I’m able to cope with the rate of change and proactively address issues; but let’s not stop there! Now that we know there are hundreds of happy users for each application, we want to know even more:

  • Who are these users? How can I segment them?
  • What are they using the app for?
  • What insights can we gain from usage metrics that we can feed-back to our product management teams?

Digital Business Analytics can help answer those questions.

BizOpsConfigurator

For BizOpsConfigurator, we can simply capture additional business context using User Session and User Action Properties, all with no code changes. I configured some using CSS selectors and others using JavaScript variables, but there are various other options as well, including predefined Property Packs. Once I have Properties configured, I can see the additional business context on each session and can query sessions based on it in USQL and Multi-Dimensional Analysis.

After slicing and dicing the data using those tools, I now understand how I want to look at the data for long term trending and dashboarding. Doing so is as simple as a click on the Create Metric button and then Pin to Dashboard.

Dashboard Powerups

For Dashboard Powerups, I could also use User Session and Action Properties, but I needed even more flexibility on the dimensions of my data. So here I chose the Metric Ingest API (/api/v2/metrics/ingest). I simply needed to create the metric payload with a comma-separated list of dimensions:

I also included the special dt.entity dimension to ensure the metric is attached to the Smartscape topology and analyzed by Davis, as described in this blog post. After creating the payload, a simple XHR can POST the data to the API endpoint. Caution, while you should always be careful with API tokens, extra care should be taken when using a token in a user-facing application. Be sure to minimize the token scope and as always, ensure it is not publicly exposed in public code repositories.

Once the data is reported, Explorer can be used to visualize the data and pin to the dashboard.

So, what did we find out?

From the BizOpsConfigurator analytics, we were able to draw conclusions about which dashboard packs to focus on next. We were also able to give recommendations to our product management team on where an out-of-the-box workflow might provide value. Similarly, for the Powerups data, we could draw conclusions about which visualizations customers thought were useful. Interestingly, there were significant differences between customer and internal (e.g. Sales Engineers) usage.

Ready to get started?

Ready to gain visibility, ramp-up performance, conquer errors, and up-level business insights into all your applications? Contact your Dynatrace Sales Engineer for a demo or POC of DEM and Business Analytics. New to Dynatrace? Try our free trial!

Stay updated