AppDynamics Extension Buildpack (MultiBuildpack Approach)

Starting with version v4.6.x of AppDynamics Application Performance Monitoring for Pivotal Platform tile we will be shipping an AppDynamics extension buildpack appdbuildpack that can be used in tandem with standard build packs using Cloud Foundry’s multiple buildpack workflow. The buildpack serves as a single point for AppDynamics APM support.

Prerequisites

1. Cloud Foundry Command Line Interface (cf CLI) v6.38 or later is required to use multiple buildpacks. See Installing the cf CLI.

Workflow

1. Install or Upgrade AppDynamics Application Performance Monitoring for Pivotal Platform tile version v4.6.x or later. No additional configuration is needed!

2. Once the AppDynamics APM for Pivotal Platform tile is installed, a buildpack with the name appdbuildpack appears in your list of cf environment buildpacks:

   $ cf buildpacks
   Getting buildpacks...
   
   
   buildpack                position   enabled   locked   filename                                             stack
   meta_buildpack           1          true      false    meta_buildpack-v1.1.0.zip
   ...
   appdbuildpack            25         true      false    AppDynamics_buildpack-v4.6.10.zip
   

3. Edit the following sections of your application’s manifest.yml

   1. Include the appdbuildpack extension buildpack in the buildpacks section.

     buildpacks:
       - appdbuildpack
       - <language specific buildpack>
   

   1. In the env section, set the APPD_AGENT environment variable corresponding to the language of the application.

     env:
       APPD_AGENT: dotnet
   

   1. Bind the application to the AppDynamics service instance, by including it in services section.

     services:
      - appd
   

4. To push your application use the use the cf CLI command, cf push.

   $ cf push
   

APPD_AGENT values

Note: NodeJS multi-buildpack needs one more environment variable.

    env:
      APPD_BUILDPACK: true

Advanced Features

The AppDynamics extension buildpack supports configurable environment variables. This allows you to customize how you fetch agent binaries and override agent configuration.

Overriding Agent Binary Downloads

By default appdbuildpack tries to fetch the corresponding AppDynamics agent from standard language-specific repositories, for example: NuGet for .NET, PyPI for Python, npm for node.js etc.

To override this behavior, you can set the environment variable APPD_AGENT_HTTP_URL to a custom http url where the binaries are hosted. appdbuildpack then downloads the agent bits from that url and installs the agent.

  env:
    APPD_AGENT: dotnet
    APPD_AGENT_HTTP_URL: http://custom-http.server.com/dotnet/4_5_7_0/AppDynamics-DotNetCore-linux-x64-4.5.7.0.zip

Extending Agent Configuration

By default appdbuildpack creates the basic configuration needed by the AppDynamics agent to instrument the application. This includes the application AppDynamics name, tier, node and controller information.

appdbuildpack facilitates adding additional configuration to the agents or overriding the existing default configuration. To acheive this, set the APPD_CONF_HTTP_URL environment variable to a custom http url where advanced agent configuration files are hosted. The extension buildpack downloads the relevant files related to the AppDynamics agent and extends the agent configuration.

  env:
    APPD_AGENT: dotnet
    APPD_CONF_HTTP_URL: http://custom-http.server.com/dotnet/conf/v1

Notes:

1. APPD_CONF_HTTP_URL must point to the location of the folder, not the file location. In the above example, advanced configuration files of AppDynamics DotNet Agent (e.g: AppDynamicsAgentLog.config) are hosted under conf/v1 folder.

2. appdbuildpack will only fetch the files with relevant names that are applicable to the agent. In the example above, because it is a dotnet agent, only the files AppDynamicsAgentLog.config and AppDynamicsConfig.json are downloaded, if located at http://custom-http.server.com/dotnet/conf/v1. All other files are ignored.

3. Refer to the AppDynamics documentation for the names and formats of the advanced configuration files applicable to each of the AppDynamics agents.

4. For NodeJS agent instead of specifying the file path, environment variables can be set in manifest.yml. More information can be found at https://docs.pivotal.io/partners/appdynamics/using.html#node_workflow.

Sample manifest.yml

---
applications:
- name: cf-net-linux
  random-route: true
  memory: 1G
  buildpacks:
    - appdbuildpack
    - dotnet_core_buildpack
  env:
    APPD_AGENT: dotnetcore
    APPD_AGENT_HTTP_URL: http://cf-app.com/dotnetcore/1/AppDynamics-DotNetCore-linux-x64-4.5.7.0.zip
    APPD_CONF_HTTP_URL: http://custom-http.server.com/dotnet/conf/v1
    DOTNET_CLI_TELEMETRY_OPTOUT: 1
    DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
  services:
    - appd

Advantages to Using this Approach

1. Clear separation of responsibilities between appdbuildpack and the standard system buildpacks. appdbuildpack is now solely responsible for anything related to AppDynamics intrumentation.

2. Any new features related to AppDynamics will be shipped through appdbuildpack. This significantly reduces the new feature turnaround time compared to shipping AppDynamics bits through standard buildpacks.

3. A single unified workflow to instrument a variety of applications, regardless of the language or framework of the application. Any new feature added to appdbuildpack, if applicable, is available across all langauge agents since appdbuildpack is the sole source of AppDynamics instrumentation logic.

Sample Application

As always, you can find sample applications demonstrating the multibuildpack approach in our GitHub space. https://github.com/AppDynamics/cloudfoundry-apps