3 - Verify Deployments with AppDynamics

Updated 1 week ago by Michael Cretzman

Harness can analyze AppDynamics data and analysis to verify, rollback, and improve deployments. To apply this analysis to your deployments, you set up AppDynamics as a verification step in a Harness Workflow.

This section covers how to set up AppDynamics in a Harness Workflow, and provides a summary of Harness verification results.

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 Workflow deployment.

Deployment Verification Setup

To add an AppDynamics verification step to your Workflow, do the following:

  1. Ensure that you have added AppDynamics as a Harness Verification Provider, as described Verification Provider Setup.
  2. In your Workflow, under Verify Service, click Add Verification, and then click AppDynamics. The AppDynamics dialog appears.

Fill out the dialog. The dialog has the following fields.

Field

Description

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.

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.

Predictive Analysis is used for dependent tiers because when you are deploying a service there is no change in the nodes for other services that are dependent on the current service/tier.

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

Field

Description

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.

See CV Strategies, Tuning, and Best Practices.

Baseline for Risk Analysis

See CV Strategies, Tuning, and Best Practices.

Execute with previous steps

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

Algorithm Sensitivity

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

See CV Strategies, Tuning, and Best Practices.

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.

  1. Click TEST. Harness verifies the settings you entered.
  2. Click SUBMIT. The AppDynamics verification step is configured.

Verification Results

Once you have executed the Workflow, Harness performs the verification you configured and displays the results in the Deployments and Continuous Verification pages. 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 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.

Next Steps

How did we do?