AppDynamics Verification

Updated 6 hours ago by Michael Cretzman

AppDynamics enables you to monitor and manage your entire application-delivery ecosystem, from the mobile app or browser client request through your network, backend databases and application servers and more.

In Harness, you can add an AppDynamics verification step to your workflow and AppDynamics will be used by Harness to verify the performance and quality of your deployments. Harness machine-learning Continuous Verification algorithms analyze verification results to detect errors and anomalies, helping you refine your deployments.

Microservices Environment using AppDynamics

Harness Verification and Impact Analysis

Intended Audience

  • DevOps

Before You Begin

Add AppDynamics to Verification Providers

AppDynamics Permissions: The AppDynamics account you use to connect Harness to AppDynamics must have the following permission:

View, Edit and Delete permissions for new applications can be set as part of the default permissions for a custom role

For more information, see General Permissions from AppDynamics.

To add AppDynamics as a verification provider, do the following:

  1. Click Setup.
  2. Click Connectors.
  3. Click Verification Providers.
  4. Click Add Verification Provider, and select AppDynamics.

    The Add AppDynamics Verification Provider dialog appears.

The Add AppDynamics Verification Provider dialog has the following fields.



Account Name

Enter the name of AppDynamics account you want to use.

Controller URL

Enter the URL of the AppDynamic controller in the format:


For example,

Username and Password

Enter the credentials to authenticate with the server.

Display Name

Enter a display name for the provider. If you are going to use multiple providers of the same type, ensure you give each provider a different name.

Usage Scope

If you want to restrict the use of a provider to specific applications and environments, do the following:

In Usage Scope, click the drop-down under Applications, and click the name of the application.

In Environments, click the name of the environment.

AppDynamics Environment Variables

To monitor Java applications in the Controller, you need to install the AppDynamics Java Agent on each server that hosts applications to be monitored. The Java Agent requires that certain environment variables be set.

For a Docker Image artifact, you can include the Java Agent in the Docker Image you deploy and set these environment variables in the artifact. You can do this using a controller-info.xml file, such as this one located on Github.

You can also set these variables in the Harness Service that is using the Docker Image. Here is an example of a Harness Service containing the environment variables as Config Variables.

For a list of the required environment variables, see Use Environment Variables for Java Agent Settings from AppDynamics. You might also include the JAVA_OPTS variable to add the Java Agent path to JAVA_OPTS.

The Config Variables in the Harness Service can be overwritten by the Harness Environment Service Overrides.

Do not hardcode the node name (APPDYNAMICS_AGENT_NODE_NAME) in any environment variables as that will prevent deployment features such as Canary and Blue/Green strategies and rollback.

Verify with AppDynamics

The following procedure adds an AppDynamics verification step to a workflow.

In order to obtain the names of the host(s) or container(s) where your service is deployed, the verification provider should be added to your workflow after you have run at least one successful deployment.

To verify your deployment with AppDynamics, do the following:

  1. Ensure that you have added AppDynamics as a verification provider, as described above.
  2. In your workflow, under Verify Service, click Add Verification, and then click AppDynamics. The AppDynamics dialog appears.

The AppDynamics workflow dialog has the following fields.



AppDynamics Server

Select the server you added when you set up your AppDynamics Verification Provider.

Application Name

The dropdown is populated with the applications available on the server you selected. Select an application from the list.

In AppDynamics, the applications are listed in the Applications tab:

Tier Name

The dropdown is populated with tiers from the application you selected. Pick the tier from which you want usage metrics, code exceptions, error conditions, and exit calls.

In AppDynamics, the tiers are displayed in the Tiers & Nodes page:

Expression for Host/Container name

The expression entered here should resolve to a host/container name in your deployment environment. By default, the expression is ${host.hostName}. If you begin typing the expression into the field, the field provides expression assistance.

To find the node names in AppDynamics, do the following:

  1. Click Applications.
  2. Click the name of your application.
  3. Click Application Dashboard, and then click Dashboard.
  4. Change you display to Application Flow Map.
  5. Click a node in your Application Flow Map to display its details.
  6. In the details, click the Nodes tab.

    The node name here is the name that the expression should resolve to.

When you are setting up the workflow for the first time, Harness will not be able to help you create an expression because there has not been a host/container deployed yet.

For this reason, you should add the Verify Step after you have done one successful deployment.

Include dependent tiers

Click this option and a dropdown appears where you can select dependent tiers on which Harness will perform predictive analysis.

The following settings are common to all verification provider dialogs in workflows.



Analysis Time duration

Set the duration for the verification step. If a verification step exceeds the value, the workflow Failure Strategy is triggered. For example, if the Failure Strategy is Ignore, then the verification state is marked Failed but the workflow execution continues.

Baseline for Risk Analysis

Select Previous Analysis to have this verification use the previous analysis for a baseline comparison. If your workflow is a Canary workflow type, you can select Canary Analysis to have this verification compare old versions of nodes to new versions of nodes in real-time.

Execute with previous steps

Check this checkbox to run this verification step in parallel with the previous steps in Verify Service.

Failure Criteria

Specify the sensitivity of the failure criteria. When the criteria is met, the workflow Failure Strategy is triggered.

Include instances from previous phases

If you are using this verification step in a multi-phase deployment, select this checkbox to include instances used in previous phases when collecting data. Do not apply this setting to the first phase in a multi-phase deployment.

Wait interval before execution

Set how long the deployment process should wait before executing the verification step.

Verification Results

Once you have executed the workflow, Harness performs the verification you configured and displays the results in the Deployments page. Verification is executed in real-time, quantifying the exact business impact of every production deployment.

To see an overview of the verification UI elements, see Continuous Verification Tools.

Using AppDynamics, Harness Continuous Verification performs service impact verification across all microservices deployed within your application environment. When you deploy a new microservice container as part of the workflow, Harness identifies and verifies all microservice dependencies to determine the overall impact.

Verification Example

Let’s imagine you are monitoring a simple microservices environment using AppDynamics that has 4 microservices: Inventory, Checkout, Payment, and Record Processing.

Once you have deployed and verified a new version of the Payment microservice using Harness and AppDynamics, Harness might report a business transaction risk by highlighting the verification step in the workflow.

When you click on the verification provider step, you are provided with details about the risk.

In this report, you can see that the deployment caused a performance regression for the Payment service after the new version was deployed. The scope of the Harness verification and impact analysis is limited to where the new artifacts were deployed.

Application Performance Monitoring (APM) Service Maps

AppDynamics automatically maps application service dependencies by tracing user requests (business transactions) across the various application services and components (tiers). The data is stored and modeled as application and transaction flow maps.

Using REST, Harness can query the flow maps to learn of all upstream and downstream service dependencies, and then verify dependencies related to a specific microservices deployment.

Here is an example of the Harness verification and impact analysis where the payment performance regression has an upstream impact to the checkout microservice but no downstream impact to the record-processing service:

By querying the AppDynamics service model, Harness continuous verification discovers all microservices dependencies related to the Payment microservice. Harness unsupervised machine learning observes and evaluates both upstream and downstream by analyzing all time-series metrics for impacted microservices.

As a result of this analysis, you can modify the workflow Rollback Steps to automatically roll back these deployments when these specific AppDynamics verifications fail, thus avoiding downtime and a bad end user experience.

AppDynamics 24/7 Service Guard Setup

Harness Workflow verification steps provide verification of Harness deployments and the running microservice for the first 15-30 minutes. Harness 24/7 Service Guard provides detection of your microservices from then on, catching problems that surface minutes or hours following deployment.

You can add your AppDynamics monitoring to Harness 24/7 Service Guard in your Harness Application Environment.

To set up 24/7 Service Guard for AppDynamics, do the following:

  1. Ensure that you have added AppDynamics as a Harness Verification Provider, as described above.
  2. In your Harness Application, click Environments.
  3. In Environments, click the Environment for your running microservice. Typically, the Environment Type is Production.
  4. In the Environment page, locate 24/7 Service Guard.
  5. In 24/7 Service Guard, click Add Service Verification, and then click AppDynamics.

    The AppDynamics dialog appears.

  6. Fill out the dialog. The dialog has the following fields.
For 24/7 Service Guard, the queries you define to collect logs are specific to the application or service you want monitored. Verification is application/service level. This is unlike Workflows, where verification is performed at the host/node/pod level.



Display Name

The name that will identify this service on the Continuous Verification dashboard. Use a name that indicates the environment and monitoring tool, such as AppDynamics.


The Harness Service to monitor with 24/7 Service Guard.

AppDynamics Server

Select the AppDynamics Verification Provider to use.

Application Name

The Application Name used by the monitoring tool.

AppDynamics, the applications are listed in the Applications tab:

Tier Name

The dropdown is populated with tiers from the application you selected. Pick the tier from which you want usage metrics, code exceptions, error conditions, and exit calls. In AppDynamics, the tiers are displayed in the Tiers & Nodes page:

Failure Criteria

Specify the sensitivity to determine what events are identified as anomalies.

Enable 24/7 Service Guard

Enable this setting to turn on 24/7 Service Guard. If you simply want to set up 24/7 Service Guard, but not enable it, leave this setting disabled.

When you are finished, the dialog will look something like this:

  1. Click TEST. Harness verifies the settings you entered.
  2. Click SUBMIT. The AppDynamics 24/7 Service Guard to configured.

To see the running 24/7 Service Guard analysis, click Continuous Verification.

The 24/7 Service Guard dashboard displays the production verification results.

For information on using the dashboard, see Using 24/7 Service Guard.

How did we do?