AppDynamics BiQ Walkthrough

This outline reviews a few prerequisites that are needed before we can fully utilize analytics data for answering business questions in AppDynamics. We'll help provide a simple step-by-step process to encourage using the AppDynamics analytics tools for creating useful widgets.

Practicing the basics helps strengthen the foundations of complex analytics insights and relationships between business behaviors. Once reviewing the prerequisites, you can log into your own controller to experiment.

Environment assumptions

We have an instrumented application with the following:

• Java Agents
• NodeJs Agents
• GoLang Agents
• Machine Agent
• SIM Enabled
• Docker Monitoring Enabled
• Analytics On
  (This is using the legacy analytics configuration where the machine agents acts as a proxy for sending analytics from the Java Agent. Currently, the Java Agent now has the capability of sending its analytics metrics without the needs for a machine agent.)

Business Transactions

Having defined Business Transactions is most important requirement when dealing with analytics. The behavior surrounding analytics data must be scoped and understood, otherwise the measurements of the metrics become skewed and offer inaccurate insights.

You may find yourself in a situation of Business Transaction explosion, where scores or hundreds of transactions are being discovered that follow similar lexical patterns. Below we have almost 100 transactions with /login/ as a prefix.

By configuring the instrumentation for Business Transactions, we can create a rule to group the log on behavior into one monitored Business Transaction: Login.

Add a Custom Business Transaction.

Configure the name so anyone can understand. Configure the search to match the pattern.

Wait for the Configuration Rules to update on the Agent and observe the grouped Business Transactions.

Simple dashboard

Create a dashboard

Navigate to the Dashboards and Reports tab in your AppDynamics Controller and create a new dashboard.

Create widgets for the following metrics.

1. Total application calls as a single value.
2. Average response time for all Business Transactions as a time series (graph).
3. Health of all the servers as a health status.

Explore the other widgets, styles and metrics to see what type of information you can radiate. Take note of the several styling options available. The limited styling forces the use of other tools like Photoshop to make truly impressive dashboards.

AppDynamics Query Language (ADQL)

The basics

ADQL is a semantic (syntax only) derivative of SQL and shares the same high level concepts aside from a few nuances. The smallest interesting query you can write is select * from transactions. This query will return all Business Transaction analytics data. Let us deconstruct the query.

• select: This begins the query by identifying what the query will be selecting.
• *: This is a common wildcard meant to return everything and should only be used when searching for specific data.
• from: Indicates what data set or table to pull data from.
• transactions: The data set to pull from. There are several sources of data, and if you switch to basic mode you can see a drop down of options.

By default, ADQL groups explicitly selected columns without the need for the keyword GROUP BY when using an aggregate keyword like Sum or AVG. (For someone familiar with SQL this is an important distinction.)

Take for example:

SELECT segments.userData.'Customer Class' AS "Customer Class", count(segments.userData.'Customer Class') FROM transactions WHERE application = "AD-Air-Travel" and transactionName in ("/web-api/flights/bookFlight", "/web-api/flights/checkout")

We select the Customer Class data point which can be one of several values — null, Platinum, Gold, Silver, Diamond — and use the count aggregate function to count the total number of Customer Class. Since we used the count function, the search engine will automatically group the results into the possible Customer Class values. Here is the result in list form.

Here is the data in bar graph form. Take note that the null value is not shown here.

Mastering ADQL takes some time and practice. The practical use for analytics is to help answer business questions.

Analytics data mining

Conversion Funnel

The single most important thing for a Conversion Funnel is well-defined, non-branching Business Transaction flow. The funnel is meant to showcase the continuation or dropout of user application usage. Branching is not possible within a single Conversion Funnel.

AD Air Travel Flow

The AD Air Travel application allows fake users to search, research and book flights in a standard online web application. The general user flow is as follows:

• User logs into the application.
• User searches for a flight.
• User chooses a seat.
• User books the flight.
• User checks out the flight.

We have Business Transactions that match these milestones, and we will use them to create a conversion funnel to see how well users convert between these stages.

Starting out

Navigate to either your own dashboard so we can create a new conversion funnel.

We filter the transaction criteria by the Application desired. The total counts are determined by the distinct count of sessionId in order to ensure the counts are accurate. Finally, we added steps to the funnel to visualize the percent of BTs moving through the known flow.

Additional practice

Now that we have an understanding of AppDynamics Analytics and ADQL, try your hand at creating queries and widgets to answer some of the questions below that relate to your use case.

• What is the total sale price of a product?
• How many of each category of item is sold?
• What are the total sums of the categories above?
• What is the highest searched product?

Talk to us about your experience in the comment section below, and reach out with any questions or for further discussion.