Guidelines for an AppDynamics data integration KM

Version 3

    Summary of Integration:

    This is a BMC Communities provided and supported integration set of guidelines. The purpose of this document is to show how to build an AppDynamics data integration into BMC TrueSight Infrastructure Manager using a Knowledge Module (KM) that uses AppDynamics controller's REST API  to discover monitored applications and collect the relevant data. Using the REST API allows to this KM to work with both AppDynamics' On Premise and SaaS environments. The idea is to provide you with key elements that can then help you build you own km.

    The value of this integration would be the following:

    • Performance management - provide visibility into AppDynamics collected data from TrueSight
    • Analytics - AppDynamics data can be baselined by TSIM and information used for the Probable Cause Analysis helping to reduce the MTTR while investigating and looking for root causes


    The KM uses CURL to make web services call and passes the data back to the KM for parsing the output:



    How to get AppDynamics performance data via REST API


    From within the AppDynamics metrics browser you can easily access the url for the API for a particular metric by right clicking on it as shown here:


    Authentication & Access

    Once you have the API endpoint needed for the metrics you want you can easily access it via curl on the command line. Our REST API uses HTTP basic authentication.

    If you have installed the Controller on a single-tenant platform, your default account is:

    Username: username@customer1


    If you are using the SaaS Controller, your username is your AppDynamics user name in your AppDynamics account; username: username@accountname


    How To Retrieve Configured Applications


    In order to retrieve the applications configured in AppDynamics you can call the "applications" REST api. It would return the list of applications providing application ID, description and name.




    the "output=JSON" option is the one that let's you get the output in JSON format.

    Otherwise the default format would be xml


    example using CURL:


    curl --user username@example:password here ''


    The JSON output would look like this



      "description": "AppDyn app",

      "id": 9,

      "name": "AppDynamics"



      "description": "WebStore app",

      "id": 4,

      "name": "Webstore"




    Example for retrieving tiers in application 2:

    curl --user user1@customer1:secret 'http://controllerhost/controller/rest/applications/2/tiers'


    Based on this information, while writing a KM the key phases would look like this:


    The PSL Discovery phase

    cmdline="curl --user AppdBPPM@customer1:password";



    #The above line builds the rest call that retrieves the list of Applications configured in AppDynamics. For this use case we’ve been assuming only one type of applications (meaning that all applications provide the sametype of information) but for a full implementation the various cases should be handled within this cycle.


    applications_list=execute("OS",cmdline." \"".applist_url."\"");


    # above we invoke the rest call built before and assign the applications list in the outcome to the applications_list variable


    clean_app_list=trim(trim(grep("name\":",applications_list),"\"name\":\ ")," ",TRIM_ALL);


    #Above the output is cleaned of all the undesired text


    foreach appdynapp (clean_app_list) {





    # In the above block the discovery process creates an instance for each discovered application


    Usually the discovery process takes care also of destroying the instances that are no longer needed



    The PSL Collector parameter that collects the response time metrics for each of the applications discovered.


    # Author: Gianpaolo Pagano Mariano

    # Content: PSL Parameter that retrieves the Averag Response Time of a business transaction in AppDynamics


    cmdline="curl --user AppdBPPM@customer1:password";



    # An instance of the parameter lives within each of the application instances created. With the above call we get the name of the application this parameter refers to.




    #The above line prepares the call that retrieves the performance parameters via JSON rest API. Again, during our exercise we focused on feasibility. For a full implementation it is needed a case handling based on the type of application, according to the discovery phase.


    values_list=execute("OS",cmdline." \"".metric_url."\"");

    #The above line executes the JSON API call and saves the output in values_list


    clean_avg=trim(trim(grep("value\":",values_list),"\"value\": "),", ",TRIM_ALL);


    clean_min=trim(trim(grep("min\":",values_list),"\"min\": "),", ",TRIM_ALL);


    clean_max=trim(trim(grep("max\":",values_list),"\"max\": "),", ",TRIM_ALL);


    clean_current=trim(trim(grep("current\":",values_list),"\"current\": "),", ",TRIM_ALL);


    #For each of the 4 lines above we isolate and clean the desired response time value in the complete list we previously collected.







    #Once we have isolated and cleaned the values we can assign the to the consumer parameters in charge of graphing and holding the data.

    In the attachment section you can find a sample KM that follows the guidelines described here.