Building Effective AppDynamics Dashboards

Ready to learn how to display your data in a meaningful and intuitive way? Let our engineers (who do this type of work daily) help speed things up.

Firstly, it is always a good idea to express verbally to a group what the vision or mission of a dashboard needs to be. Without this discussion, it will be impossible to reach consensus on what the dashboard should look like.

Below is what I want my dashboard to look like. This is built in a simple prototyping application that allows for changes to be made rapidly (Photoshop, Affinity Designer, Paint.NET, anything with a layer manager).

Template dashboard starter

We will start with a generic dashboard template that we created to show Application Performance. You can find this template attached to this article in Photoshop (.psd) and Affinity Designer (.afdesign) format.

The template consists of several layers to allow for a rich visual experience. Each section has a background that segregates it from the other sections, as well as have a separate color to contrast with the background and foreground content. Icons are used to help supplement the text descriptions as well as provide an anchor when placing widgets.

What "we" need to do with this template is change the Application Name and add a background image and branding to add the extra touch of a professional looking dashboard.

Background image

Our first task is to find a background image. Most companies have Press Kits meant to provide the public with official branding, images and information that can be used to describe or represent the company. Talk with your marketing team to see where that can be found. 

If a Press Kit does not exist, we can search google for any Vector art that is muted and works well as a background image. If Vector images cannot be found, normal Raster images will suffice but will not scale well. A Vector image is an infinitely scalable image whereas a Raster image will not scale infinitely without skewing.

Fortunately, WWT also provides logo usage guidelines which future dictate how the logos should be used. This removes the guess work that can sometimes be involved with creating visuals. There is no large background image in the Press Kit, so I found one on WWT's website and scraped the image. We set the image to a colored square with some opacity to darken the display and make it less dominant.

Logo branding

With our background image in place, we now are tasked with finding a logo for branding. The Press Kit provides several logos and since we are using white text, this logo seems appropriate. I then added it to the left and resized to fit in the space. Normally I would also put the logo under the opacity mask to make it more muted, but the branding guidelines specifically state to not alter the logo in any way. 

We now have a template dashboard that can be used for any number of applications within WWT and all we have to do is change the name. This is a good time to save the template and name it accordingly.

Base64 encoded image

Now that we have a template, we are ready to add this to the AppDynamics Controller for a specific application. In this example, I will use a fake application that makes WWT trillions of dollars annually called Awesome Money Making App — it's important to know its performance so that if there is an incident, we can resolve and continue making trillions of dollars.

Our first step is to change the name of the application in the template and export the dashboard as a .png or .jpg. Next we need to base64 encode the image in order for it to be uploaded to the Controller. Linux comes built in with a base64 encoder but Windows does not. Follow the instructions below to base64 encode your dashboard image to be uploaded on the controller.

• Windows
  • Install Git; include GitBash if prompted.
    • openssl base64 -in /path/to/template -out /encoded/output.txt
  • OR, if security is not an issue, use an online base64 image encoder.
• Linux
  • openssl base64 -in /path/to/template -out /encoded/output.txt
  • openssl is a library native to Linux that handles encryption/decryption
  • base64 is the type of encrypting we are telling the library to execute
  • -in expects a string that represents the file path to encode
  • -out expects a string that represents the file path to output

We now have a file that is a base64 encoded conversion of our image. This long string of text can be interpreted by browsers as the image we know it to be and allows us to create rich views that would normally bog down the dashboard through widget loading time.

"Uploading" base64 encoded image to AppDynamics Controller

Armed with the above base64 encoding, we can now use this string to "upload" our image to the AppDynamics Controller. Log into your controller and create a dashboard.

Add a new Custom Widget -> Image and use the below instructions to format the 64encoded string into a usable image.

• data:image/png:base64, encodedString
  • The above "png" can be replaced with "jpg" if you exported the dashboard as a jpeg.

Visuals, layout and widgets 

Now we have our background image that allows us to just add metric and health widgets instead of having 100+ label widgets causing poor browser performance. This also is a template to be used across applications so as people not familiar with a business unit are browsing, they know what they are looking at. It is time to add widgets to this board to make it useful, aside from looking pretty.

Application widgets

These widgets will be in the Health Rules & Events category, utilizing the Health Status Widget.

• For these widgets, select the relevant source of data: Servers, Tiers, Nodes, Databases, Business Transactions.
• We will use the Pie visualization with an Inner Radius of 90 percent.
• We normally choose to show the most severe status to ensure any issues are surfaced quickly. However, a ratio graph will show all statuses. Pick that which suits your use case the best.
• For this example, a widget width and height of 100px is perfect.
• Make the background transparent so the widget can be placed over our image.

Add the Widget and repeat for the other icons.

We have the beginnings of a dashboard that will surface any performance issues. Even already, we can see in this contrived example that our Servers are experiencing Critical issues.

Runtime stats

Let's add some graphs that show how many normal calls the application is handling relative to Slow, Very Slow, Stalled and Error calls. Add a new widget and make it a Time Series Graph.

Add a new data source to the widget and fill it out with the below values.

• Sum of Calls per Minute is our metric of choice here, so that we have the total calls made.
• Choose a custom color that will contrast your background.
• Set a custom name to be something descriptive. This is shown when hovering over the graph bar.

Add another data source, but this one will be a custom metric. Custom metrics allow us to take multiple metrics and do some math on them to give us interesting results.

Take for instance the custom metric below. There are four variables representing each part of Errors, Slow, Very Slow and Stalled calls. In the expression area below we can use the names to add all the values together. This allows us to show all of our normal calls against all of our abnormal calls. 

Note: For the sake of this article, my data sources are contrived to make it look "good." In a perfect application, the abnormal custom metric would return a 0 value resulting in only the first data source to show. This is a good thing because it means 100 percent application uptime.

The final graph specific details are as follows:

• Stack the graphs. This makes intersections of the graph "darker" as the colors are mixing.
• Hide Axis value. We are looking for trends, not specifics. Knowing our total calls is 100 vs. 200 is not as important as knowing total calls are 50 percent abnormal.
• Show all series Tooltips. This makes hovering over the graph display the custom name we set up earlier.
• Disable legend. This gives us quite a bit of space we can use to increase the size of the graph. With only two data sources, Normal and Abnormal, we do not need a legend.

Save this widget and duplicate it for the Response Time Distribution section. Edit the newly duplicated widget and remove the custom metric data source. Replace the Calls per Minute with the below configuration for Average Response Time.

Save it and position the widgets on the dashboard so they are aligned properly.

Optional details

Since this dashboard is a standard template, we leave room for each application team to add some customized information that can be tailored at will. This allows a static spot for extra things and keeps requests down for too many custom changes. Some items that can go here are:

• Integration or Service Level Agreement statuses.
• Application success metrics such as revenue per hour or leads converted per hour.
• Any specific missions or goals an application is trying to target.
• Hooks into ServiceNow, ThousandEyes, Slack, etc.

For this article purpose, we will add some images to simulate integrations. This uses the native iFrame widget.

Events

Nearing the end of our journey, we are at the Events section. The Events Widget with the Timeline setting allows us to see a chronological feed of events AppDynamics is ingesting. This is helpful when undergoing a real-time incident and can lead to spotting the problem quickly. Add a Health Rules & Events - Event List Widget.

Select the proper data source and set the background to transparent. You can configure which events are displayed in this list. For the purpose of this article, I selected all events.

Save the widget and position it nicely on the dashboard. We are now ready to add the last item, Critical Flows.

Critical flows

Our last but arguably most important task for this dashboard is adding the Critical Flows. These flows represent critical flows, pathways, use cases, user journeys and whatever other name encapsulates the idea of critical application behavior in a logical flow. 

These are included because if there is any impact shown on the other widgets we must be able to quickly deduce if the critical flows are impacted. We will not touch on creating the critical Business Transactions that make up the flow, but there are a few other pieces of content that touch on this topic.

This article will assume we spoke with the stakeholders of Awesome Money Making App and created the below critical flows:

• Home Page -> Search -> Add To Cart -> Checkout
  • A data collector added on the Checkout Business Transaction has the capability to read the contents of the method invocation, which gives us the ability to sum the total carts across a given time range. Doing this will allow us to quantify how much "normal" operation yields as well as the cost of an incident.
• Login -> Track Order
  • The status checking of an order brings end users peace of mind which is helpful for a business. Knowing if a specific user is having issues verifying their order is the difference between re-actively getting an angry call verses proactively reaching out and verifying concerns.

We add a label for each Business Transaction on our template accompanied by the hollow arrow icon included in the template to make a linear display of progress through the critical flow. With a few circles as placeholders, we can duplicate the arrow as needed and align to suit our needs.

Hide or delete the placeholder circles. I normally hide them because more often than not, I make changes and they are useful to ensure uniform sizes. 

After the circles are no longer visible, save the dashboard into a .png or .jpeg and re-64encode the file. Since we did not change any other labels, we can modify the existing background image on the controller without any conflicts.

Lastly, we add Health Rules & Event - Health Status Widget for each Business Transaction in the critical flow. These can be styled to match your needs. Below is what I used.

Once finished, your Critical Flow will be completely visualized and you can easily tell if a part of the flow is the cause of an issue. In the below example, we can see that Search and Track Order are impacted but the others are not, so it would be safe to start investigating root cause in the search and track order functionality. We also fixed the type in the background image and re-uploaded the correct image.

The dashboard is finished! Now we can "share" to make it public (no login required to view) or keep it private by opting not to share (only logged-in accounts with permissions can view). I shared the above dashboard, so it can be viewed by the public. A good idea for these types of dashboards is to have them on a TV screen in a highly public area so that any yellow or red colors will catch someone's eye.

Next steps

By now you see what it takes to make a professional looking dashboard — it is not as simple as adding a few widgets to the page. Creating compelling visual stories takes thought and effort enabled through meaningful conversations about several topics such as:

• What is an application's purpose and why is a team paid to support it?
• How is the application supporting the mission of the business?
• How can we measure and quantify the above support?
• What constitutes the application being healthy? How many 9s (99.999999%) in uptime do we consider good?

These questions help guide the conversation to actionable results and serve as a guideline for creating a monitoring strategy. Reach out to your WWT Account Manager if you would like us to help facilitate these discussions with you or contact us directly to begin the conversation today.