AppDynamicsObservability & AIOpsCiscoAutomation & Orchestration
Article • • 7 minute read

AppDynamics Business Transactions Playbook

The AppDynamics Business Transaction Playbook helps showcase the main ways we can configure Business Transactions.

In this article

  1. Defined Business Transactions
  2. Rule masking
  3. Find Entry Points
  4. Fetch agent logs remotely
  5. Wrap up

This article covers using the Business Transaction Detection Tools such as Live Preview, Find Entry Points and remote collection of agent logs. The sections below will walk through the discovery of Business Transactions that do not use a common framework and take steps to overcome the dreaded "nothing displayed" scenario in the Application Flow Map. We also demonstrate collecting agent logs remotely for custom Business Transaction instrumentation.

A few prerequisites are needed before we can fully utilize Application Business Transaction data to answer key performance indicator (KPI) questions.

Environment

Application Name: BTPlaybookLab
Tiers: MyClient, MyServer
Nodes: MyClient-1, MyServer-1

 Defined Business Transactions

Having well-defined application Business Transactions is most important when dealing with Metrics and Key Performance Indicators (KPIs). The behavior surrounding Business Transactions must be intuitively or automatically detected and properly scoped for the agents to ingest meaningful data; otherwise the measurements of the metrics and over-capture of BTs can cause information explosion, stress configuration limits and produce inaccurate insights.
Out of the box for each agent type AppDynamics deploys Auto Discovery Rules for most common frameworks.

Configuration > Instrumentation > Transaction Detection.

 Missing Business Transactions or flow map

You may see a situation where expected Business Transaction are not displayed in the Application Flow Map for your Tier. You review Agent logs for hints and consult with the application developer for additional Information. In the application Agent Business Transaction log file – The following call stack points to a possible POJO (Plain Old Java Objects - the method that starts the business transaction) is called but not displayed at the flow map. The last part of this lab will demonstrate how to collect Agent Logs without having access to the Host.

You consult with the application developer and confirm that Class/Method for the Entry Point of the Business Transaction visibility that is needed is as follows:

Class Name: com.appdcs.correlation.payload.MyClient
Method Name: beginTxn

 Live preview

In this module, we'll show how to use the Live Preview feature to discover BTs and overcome the issue of nothing displayed in a flow map. (Note - Live Preview only works for Java Tiers at the time of this writing)

Configuration > Instrumentation > Transaction Detection > Live Preview

Select the node under the tier to begin Live Preview on this node.

Searching for an application-specific class under Tools tab will return class and method level data as shown below.

Set up custom POJO match rules by right-clicking on the method and selecting Add POJO Rule option

Once You click on "Add POJO Rule" You are presented with the following Business Transaction Rule Configuration screen. This is where you can Name the BT, Give it a higher priority, and Select Scope for a more precise definition of the transaction

BT configuration can be validated by selecting Live Preview button before saving configuration, however you also need to create a scope for the MyClient tier if you do not want to use the default.

Class: com.appdcs.correlation.payload.MyClient
Method: beginTxn
Tier Scope: MyClient

 Scopes (optional)

Scopes are useful when you want to apply a Business Transaction rule to a set of Tiers explicitly. We want to try and reduce the amount of instrumentation so the overhead is as minimal as possible. Scopes keep rules from being run on Tiers that we know will never see certain types of traffic.

 Rule masking

Applications naturally have a code execution hierarchy as child functions are invoked. Sometimes our instrumentation is configured to look to far up the hierarchy when we are more concerned with different behavior. When we create a Business Transaction rule and it is not showing up, a valid possibility is the new transaction is being masked by an upstream BT. There are a few ways to handle a masked transaction and each one has its pros and cons.

 Moving entry points downstream

One solution is to remove the masking BT.

  • If the masking BT is custom, change the priority to be lower than the desired rule.
  • If the masking BT is automatic discovered, you will need to disable automatic discovery. See the outline below for this option.

In all of the above cases, a parent transaction indicates the beginning of a flow and moving the beginning downstream can cause certain code calls to no longer be monitored. This is a discussion that needs to determine how far down the stack will yield the greatest return on monitoring.

 Splitting the parent transaction

Another solution is to split the parent transaction on some piece of data either in a method parameter, http header or url segment. This can help create buckets of monitoring.

 Disabling automatic transaction discovery

Automatic Transaction Discovery can cause issues when the agent is assuming the entry points. While it is a good first step, sometimes we do not want to begin at the webserver level. The most common masking comes from servlet or controller level ingestion, ie urls. It can be beneficial to disable automatic discovery and configure important entry points for monitoring.

 Find Entry Points

The find-entry-points feature which tells the agent to write to the logs potential entry points. To access this information, find the agent logs and grep/search the file for this lexical pattern INFO - BT to see the log output for this specific behavior. If you do not have direct access to the logs, continue to Module 4 to see how to request logs remotely. We use this feature when access to developers is limited but we have an idea where an entry point should exist.

 Turn on Find Entry Points

Go to Application > Tier & Nodes > Double-click on a node to go to the Node Flow Map

Under Actions choose Configure App Server Agent

Select the Tier and Use Custom Configuration radio button. Search for the find-entry-points property and change its value to true

 Fetch agent logs remotely

Once find-entry-points is enabled, the agent will start logging extra call stack information. After a few minutes, you can collect agent logs from the Controller UI, or you can always view them from agent installation folder on the host if you have access. Debug logging is not needed for this property. To request these logs go to,

Application > Tier & Nodes > Double-click on the Node to go to the "Node Flow Map"

You may need to expand the double greater symbol to get to the Agents tab. You can request logs from the App Server Agent at the bottom of the page.

Once logs are ready, download them via UI by clicking on floppy disc icon.

A complete call stack will dump to Business Transactions.log file and will look like the image below. It will also take a few minutes to gather the config and log files. Examining the BT log you will find something similar to the following POJO information to help you configure your own BTs.

 Wrap up

The above methods provide some insight into how to configure AppDynamics to measure what is truly important. Starting from square one can feel daunting. WWT can help provide guidance for monitoring strategy and implementation best practices. Reach out to your nearest WWT Account Manager if you would like to speak with our AppDynamics team.

Technologies