Discussion Feed

The AppDynamics integration with Pivotal Cloud Foundry (PCF) allows you to easily deploy AppDynamics-monitored applications on the PCF platform.   This article walks you through deploying a PHP applicaton with AppDynamics agents installed. It demonstrates the steps to get up and running with PCF and the PHP Buildpack with AppDynamics.    See the AppDynamics Service Broker Tile Release Notes for the latest information on buildpacks.     Before Starting   To follow along with the steps in this article, you will need the following:  An account in a Pivotal Cloud Foundry PaaS installation.  On your development machine, the cf command line interface (see Installing the cf Command Line Interface for more information) siege for generating traffic for the application   Sample Walkthrough   In this walkthrough, we'll push a sample application, Spring Music, to PCF and monitor the application using the AppDynamics Controller.    Prepare the Sample Application   On your development machine, set the target: cf api <api end point> --skip-ssl-validation Log in to Cloud Foundry using your account credentials : cf login -u <username> -p <password> -o <org_name> -s <space name> Clone the PHP Multitier Application. This sample application is provided by AppDynamics for demonstration purposes. We’ll use it to show how monitoring works using AppDynamics PHP Agent. First 'git clone' the app from the PCF multitier php  repository , as follows: Deploy the application with the PHP Buildpack: cf push  <app_name> -b <build pack URL> You can now bind the application with AppDynamics service, as described next.   Bind the application with AppDynamics service   To instrument the PHP application with AppDynamics agent, you need to bind the application with appdynamics service. You can do so using either: AppDynamics Service Broker Tile  Create User Provided Service (CUPS) Binding the application to the AppDynamics service causes the application to be instrumented with the AppDynamics agent. The following sections describe each method.     Using the AppDynamics Service Broker Tile   The following steps are broken into two parts. Your AppDynamics administrator would generally perform the first step, configuring service plans for AppDynamics. On an ongoing basis, developers would use the second part to apply a plan to their applications.   Set up the Service Broker   The AppDynamics Service Broker tile need to be imported into the Ops Manager by your PCF administrator before starting these steps. See https://network.pivotal.io/products/p-appdynamics for more information. After importing the tile, configure service plan for the AppDynamics Service Broker as follows:   Log in to your Pivotal Apps Manager. Double click on the AppDynamics tile to configure a service-plan:   Go to Service Broker Application tab, accessible in the left pane, and click Add to add a new service plan: Configure a new service plan (if the required service plan does not already exist). The plan specifies the connection settings for the Controller instance to be used. When done, click Save . Note : If the license key has a "$" character in it,  add single quotes around the license key and escape the $ character using double slashes. Return to the Installation Dashboard page and notice that there are pending changes (representing the new service plan which we configured).  Click Apply changes. The changes may take a few minutes to be applied.  Once the changes are finished and successfully applied, the service plan will be created which can be seen through the Apps Manager. Apply the service to an application   Typically a developer would perform the following steps to associate a AppDynamics Service Plan to the developer's application. To apply the service:   Log in to the Pivotal Apps Manager Click Marketplace tab mentioned in the left navigation pane. Check for AppDynamics Service on the marketplace and double click on it. Select the Service Plan which you recently configured through the OpsManager. Now click on Select this plan .   Create the instance of this plan. There is a 1:1 relation between the instance name and the application name.    After entering the details, click Add.   The following screen shows that the service instance is successfully bound to the app. The services tab successfully mentions the service instance name.  When finished, restage the application as described in "Restage the Application and Test" below.    Creating User Provided Service Instance (CUPS)   Using CUPS allows for auto-discovery of the AppDynamics agent.   Note: When creating AppDynamics service using a user-provided service, it must have a name that starts with appdynamics.   Create the user provided service instance: cf create-user-provided-service appdynamics-SM-service -p "host-name,port,ssl-enabled,account-name,account-access-key,application-name,tier-name,node-name" Note:  The host-name should be IP address or fully qualified DNS name Bind the service with the app name : cf bind-service <app_name> <service_name>   Now you can restage the application and test, as described next.    Restage the Application and Test   Restage the application:  cf restage <app_name> Generate traffic using siege.  We will use siege to generate traffic such that webtier1 is a client of webtier2 which in turn is a client of google.com. Create a sample file "urls.txt" in any directory and enter the following contents in the urls.txt file   Run siege to generate traffic using the following command: siege --log=/dev/null --concurrent=5 --file=urls.txt --time=90000000s Verify that the load is detected by the Controller. As shown here, webtier1 (has 2 nodes) which is a client of webtier2 (has 2 nodes).  When done, try increasing number of instances of the application using the cf CLI: > cf scale <app_name> -i <number_of_instances> For example, cf scale phpdemo-app -i 2 The PCF infrastructure automatically load balances the traffic between multiple instances. Setting Proxy Properties on PCF   If you are using a Proxy Server, the consumer application should specify the http_proxy or https_proxy as an environment variable for the application running on PCF to communicate with the proxy server. Use this commands for an HTTP proxy: cf set-env <appName> http_proxy http://user@password:myproxy....:8080/   For HTTPS, use: cf set-env <appName> https_proxy https://user@password:myproxy....:8080/   After setting the proxy both for application and for AppDynamics controller, restage the application cf restage <app_name>     ... View more

The AppDynamics integration with Pivotal Cloud Foundry (PCF) allows you to easily deploy AppDynamics-monitored applications on the PCF platform.   This article walks you through deploying a Java applicaton with AppDynamics agents installed. It demonstrates the steps to get up and running with PCF and the Java Buildpack with AppDynamics. It consists of these sections:    Before Starting Walkthrough of Using AppDynamics with PCF Setting Proxy Properties on PCF Troubleshooting See the AppDynamics Service Broker Tile Release Notes for the latest information on buildpacks.     Before Starting   To follow along with the steps in this article, you will need the following:  An account in a Pivotal Cloud Foundry PaaS installation.  On your development machine, the cf command line interface available here. gradle for building the application. siege for generating traffic for the application.   Walkthrough of Using AppDynamics with PCF   In this walkthrough, we'll push a sample application, Spring Music, to PCF and monitor the application using the AppDynamics Controller.    Prepare the Sample Application   On your development machine, set the target: cf api <api end point> --skip-ssl-validation   Log in to Cloud Foundry using your account credentials : cf login -u <username> -p <password> -o <org_name> -s <space name> Clone the Spring Music demo application and build the application The sample Spring Music app is provided by Pivotal as a demonstration. We’ll use it to show how monitoring works. First 'git clone' the app from the Spring Music Github repository. Build the application using gradle Deploy the application: cf push  <app_name> -b <build pack URL>  --no-start Now bind the application with the AppDynamics service, as described next.    Bind the application with AppDynamics service   To instrument the application with AppDynamics agent, you need to bind the application with appdynamics service. You can do so using either: AppDynamics Service Broker Tile  Create User Provided Service (CUPS) Binding the application to the AppDynamics service causes the application to be instrumented with the AppDynamics app agent. The following sections describe each method.    Using the AppDynamics Service Broker Tile   The following steps are broken into two parts. Your AppDynamics administrator would generally perform the first step, configuring service plans for AppDynamics. On an ongoing basis, developers would use the second part to apply a plan to their applications.    Set up the Service Broker Tile   The AppDynamics Service Broker tile need to be imported into the Ops Manager by your PCF administrator before starting these steps. See https://network.pivotal.io/products/p-appdynamics for more information. After importing the tile, configure service plan for the AppDynamics Service Broker as follows:   Log in to Pivotal Apps Manager. Double click on the AppDynamics tile to configure a service-plan   Go to Service Broker Application tab, accessible in the left pane, and click Add to add a new service plan: Configure a new service plan (if the required service plan does not exist). The plan specifies the connection settings for the Controller instance to be used. When done, click Save . Note : If the license key has a "$" character in it,  put single quotes around the license key and escape the $ character using double slashes. Return to the Installation Dashboard page and notice that there are pending changes (representing the new service plan which we configured).   Click Apply changes. The changes may take a few minutes to be applied.  Once the changes are finished and successfully applied, the service plan will be created which can be seen through the Apps Manager. Apply the service to an application   Typically a developer would perform the following steps to associate a AppDynamics Service Plan to the developer's application. To apply the service:   Log in to the Pivotal Apps Manager Click Marketplace tab mentioned in the left navigation pane. Check for AppDynamics Service on the marketplace and double click on it.   Select the Service Plan which you recently configured through the OpsManager. Now click on Select this plan .   Create the instance of this plan. There is a 1:1 relation between the instance name and the application name.    When finished entering service plan details, click Add. The following screen shows that the service instance is successfully bound to the app. The services tab successfully mentions the service instance name.    When finished, restage the application as described in "Restage the Application and Test" below.    Creating User Provided Service Instance (CUPS)   Using CUPS provides for auto-discovery of the AppDynamics agent.   Note: When creating AppDynamics service using a user-provided service, it must have a name that starts with appdynamics.   Create the user provided service instance: cf create-user-provided-service appdynamics-SM-service -p "host-name,port,ssl-enabled,account-name,account-access-key,application-name,tier-name,node-name" Note: The host-name should be an IP address or fully qualified DNS name.    Bind the service with the app name:   cf bind-service <app_name> <service_name>                 Now you can restage the application and test, as described next.    Restage the Application and Test   Restage the application:  cf restage <app_name> Note: You should see the AppDynamics agent getting installed, as underlined in the following screenshot:    Check the state of the app to check whether the app is successfully deployed on PCF:   Generate traffic using siege: Create a sample file "urls.txt" in any directory and paste the URL link of the application  Run siege to generate traffic using the below command siege --log=/dev/null --concurrent=5 --file=urls.txt --time=90000000s  Verify that the load is detected by the Controller:   When done, try increasing number of instances of the application using the cf cli.   cf scale <app_name> -i <number_of_instances> For example: cf scale spring-music -i 2  The PCF infrastructure automatically load balances the traffic between multiple instances.   Setting Proxy Properties on PCF   If your PCF application connects through a proxy, you'll need to take a few extra steps to enable the agent to communicate with the AppDynamics Controller:   If the PCF instance is not already configured to communicate via the proxy, set the http_proxy or https_proxy settings as environment variable, as follows:  For an HTTP proxy, use:  cf set-env <app_name> http_proxy  http://user@password:myproxy ....:8080 For an HTTPS proxy, use: cf set-env <app _n ame> https_proxy https://user@password:myproxy....:8080/ For more information, see http://docs.cloudfoundry.org/cf-cli/http-proxy.html.  Set the agent proxy settings as environment variables as follows: cf set-env <app_name> JAVA_OPTS " -Dappdynamics.http.proxyHost=<host_ip> -Dappdynamics.http.proxyPort=<port_number>" Restage the application: cf restage <app_name>     Troubleshooting   When finished setting up, metrics from the monitored PCF application should appear in the Metric Browser in the Controller UI. If they do not, it's possible a timeout error has occurred in the metric registration process. To troubleshoot, try deleting the application in the Controller UI and allowing the application to reregister.     Another possible root cause is that the metric is not associated with a unit of measure in the Java Mission Control ( JMC ) for the machine, which is a requirement.  Notice, "In Units Of" says no units in the following screenshot:      In this case, associate the metric with the desired unit of measure in JMC:    ... View more

ICEfaces  is an  open source   Software development kit  that extends  JavaServer Faces  (JSF) by employing  Ajax .   It is used to construct  rich Internet applications  (RIA) using the  Java  programming language. With ICEfaces, the coding for interaction and Ajax on the client side is programmed in Java, rather than in JavaScript , or with  plug-ins .   To create a Business Transaction match rule in AppDynamics that effectively matches ICEfaces entry points, follow these steps:   In the Transaction Detection UI tab in the Controller UI (Configuration > Instrumentation > Transaction Detection), create a new custom match rule. Choose Servlet as the entry point type for the rule. For the Transaction Match Criteria, match by URI containing the word faces . In the Split Trasactions Using Payload tab, split by POJO Method Call. Split based on the second parameter  (at index=1) of the  com.sun.faces.application.ViewHandlerImpl.renderView() method, getViewId(). For example: ... View more

In some instances, you may need to perform additional configuration to properly instrument Microsoft SharePoint sites with the AppDynamics .NET Agent.   New in 4.1.3 ,  if you are running Microsoft SharePoint with .NET Framework 4.5.2 or 4.6 and later, the .NET Agent automatically instruments SharePoint without configuration changes to SharePoint.   Symptom If you suspect you are having issues instrumenting SharePoint sites with the .NET Agent, check the agent log (AgentLog.txt) for entries as follows:   2015-05-13 17:38:18.9799 13436 w3wp 2 26 Error ConfigurationChannel Exception: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)Exception: System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401) at System.Net.HttpWebRequest.GetRequestStream() at AppDynamics.Shared.Communication.qe.ju(Byte[] , String ) at com.appdynamics.ee.rest.controller.request.av.kkw() See "Log Files" on .NET Agent Directory Structure.   Solutions Choose the solution below that best fits your environment.   Modify the SharePoint application web.config   Check the value of the legacyCasModel attribute of the trust element in the SharePoint web.config: <trust level="Full" originUrl="" legacyCasModel="true" /> If legacyCasModel  is set to "true," then change it to "false". Save the web.config file Restart IIS. Confirm your application continues to work normally. If, for any reason, setting legacyCasModel to "false" is not possible, use the option below to modify the registry.   Modify the Global Registry Microsoft has provided the following workaround for this issue.   Back up the .NET agent Logs directory (for example, %ProgramData%\AppDynamics\ DotNetAgent\Logs) and remove its contents, but be sure to retain the Logs directory itself.  Configure the following registry settings: Under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework Create new DWORD "LoaderOptimization" with value 1 Under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\ Create new DWORD "LoaderOptimization" with value 1 This configuration disables loader optimization assemblies that cause this issue. Restart the Appdynamics.Agent.Coordinator service. Restart IIS.     ... View more