Summary

This purpose of this post is to demonstrate how to enable analytics monitoring for the applications running on IBM Cloud Code Engine by leveraging Cisco AppDynamics and its Analytics Transactions feature.

Importance of Analytics monitoring for applications             

Analytics monitoring is becoming a key instrument in IT strategy and design; understanding users’ behaviour is essential for applications optimisation. Businesses users, in domain such as finance, marketing and sales, access real-time data that give insights like the entire users’ journey within the applications. This help to enhance applications’ value, reduce overall costs and maximize chances for improvement.

Introduction to Code Engine

IBM Cloud Code Engine is a fully managed serverless platform that runs enterprise-grade workloads, including web apps, micro-services, event-driven functions, or batch jobs. All these workloads can seamlessly work together because they are all hosted within the same Kubernetes infrastructure.

The benefit of Code Engine is that sizing, deployment, scaling and networking are fully managed by IBM Cloud. This allows clients to focus on the development of the application code itself and not on the underlying infrastructure.

Introduction to AppDynamics

AppDynamics is a full-stack application performance management (APM) company, owned by Cisco. The SaaS solution provides end-to-end visibility into the performance of applications written in popular programming languages such as Java, .NET, Node.js, PHP, Python and C/C++.

AppDynamics needs the applications to be instrumented by adding an application agent (app agent) into the runtime process of the application. The app agents automatically discover the most common application contexts and collect application data and metrics to build flow maps that visually represent the components of your application to help you understand how data flows among the application components (for example, an application server and a database server).

Analytics is an add-on of AppDynamics SaaS. With Analytics, business users can correlate application performance data with key business metrics like revenue that are tied to transactions.

Analytics can detect business transactions (for example like logins, shopping cart additions and deletions) from the services that deliver user-initiated requests. It also can identify and resolve performance issues before the users notice by doing anomaly detection with automated alerts.

Data sources for Analytics can be Transactions or Logs.

Transaction Analytics data is collected by the app agents without modifying the application code.

Logs Analytics can search and analyse log data, both on instrumented and non-instrumented applications, just as transaction data.

This post will show how to instrument an application running on IBM Cloud Code Engine to provide transaction analytics data to the AppDynamics Analytics.

Components of the Solution

General Deployment Example

The following Graphics is from AppDynamics https://docs.appdynamics.com/appd/24.x/latest/en/analytics/deploy-analytics-with-the-analytics-agent/analytics-agent-components#id-.AnalyticsAgentComponentsv24.3-DeployingAnalyticsAgentstoMultipleNodes

And shows a deployment example on multiple hosts.

Here you can see the three main components

App Agent / App Server Agent

The agent detects calls to a service entry point at the tier and follows the execution path for the call through the call stack. It sends data about usage metrics, code exceptions, exit calls to backend systems

Analytics agent for Transactions

The Analytics Agent collects data from one or more app server agents and sends it to the Events Service. It acts as a proxy between the app server agent and the Events Service.

You can install the agent in two ways.

• Download and install either the Machine Agent or the Analytics Agent (standalone binary) on each machine.
• Use a shared Analytics Agent instance.

In our case we used the shared Analytics Agent option.

AppDynamics Events Service

The AppDynamics Events Service is the data storage facility for unstructured data generated by Application Analytics, Database Visibility, and End User Monitoring deployments either on-prem on SaaS. We worked on SaaS.

Deployed Architecture

Bringing these components to Code Engine results in the following architecture:

The configuration of the application, in order to send analytics data to the Analytics Agent, will include the hostname and port of it, so the communication happens over the network.

  - name: APPDYNAMICS_ANALYTICS_HOST

    value: analytics-proxy

  - name: APPDYNAMICS_ANALYTICS_PORT

    value: "9090"  

Procedure

In the procedure we will provide a high-level description of the steps to integration AppDynamics Analytics Transaction Only Agent with IBM Cloud Code Engine Applications.

Step 1: Install AppDynamics App Agent on the existing Node.js Code Engine application to be monitored

Follow these steps:

• Update your Dockerfile of your application to install the AppDynamics App Agent on your application. For this example, the Dockerfile used to build the image uk.icr.io/qy-ns/node-appd is:

FROM node:16-slim

...

RUN npm install appdynamics@next

COPY server.js .

EXPOSE 8080

CMD [ "node", "server.js" ]

• Update the source code of your application by adding the configuration of the App Agent. In our case we insert the following call at the first line of the main module server.js file, before any other require statements: 

require("appdynamics").profile({

  controllerHostName: 'myaccount.saas.appdynamics.com',

  controllerPort: 443,

  // If SSL, be sure to enable the next line

  controllerSslEnabled: true, // Set to true if controllerPort is SSL

  accountName: 'myaccount',

  accountAccessKey: '******', //required

  applicationName: 'node-app',

  tierName: 'web',

  nodeName: 'process'

  });

• Rebuild the image and push it to your container registry. In our case:

podman build -f Dockerfile -t uk.icr.io/qy-ns/node-appd .

podman push uk.icr.io/qy-ns/node-appd

• In the Code Engine Web UI, click on Redeploy to redeploy with the new image to the Code Engine Application (see figure1 above).
• Once you verified your application started successfully after redeployment, you can verify it is monitored by the App Agent in the AppDynamics Web Console. In our case, after logging to the console:

• • Click on the Applications tab. node-app should appear in the application list.

• • -          Select node-app, the default Metrics for the application are shown below.

Step 2: Deploy an AppDynamics Analytics Agent as a separate Code Engine application

You can use the public Docker image at this link.

In our case, we deploy the latest AppDynamics machine-agent-analytics image as a Code Engine Application named analytics:

Step 3: Configure and start the Analytics Agent in Code Engine

1. AppDynamics Analytics Agent environment variables need to be defined in the application before the agent can be started. This is the list:

APPDYNAMICS_AGENT_ACCOUNT_ACCESS_KEY

EVENT_ENDPOINT

APPDYNAMICS_AGENT_ACCOUNT_NAME

APPDYNAMICS_AGENT_GLOBAL_ACCOUNT_NAME

APPDYNAMICS_CONTROLLER_HOST_NAME

APPDYNAMICS_CONTROLLER_PORT

APPDYNAMICS_CONTROLLER_SSL_ENABLED

In our case, this is the Environment variable tab of the application analytics:

2. By default, the AppDynamics Analytics Agent uses port 9090 to expose its APIs. However, this port is reserved by Code Engine (see reserved ports here).

Because of this, in the Image start options tab, you need to specify a different port number of the Agent. In our case, we used port 9095:

3. To start the Analytics Agent from the machine-agent-analytics container image, a set of commands must be added to the Arguments field in the Image start options tab. The commands perform the following tasks:

• Update the Analytics agent ports as default ones (9090 and 9091) are re-served by Code Engine and can’t be used.
• Set the Analytics Agent logging options.
• Update the Analytics agent properties file in the container image with the environment variables defined in the Code Engine Application analytics.
• Start the Analytics Agent.

• These are the arguments in our case.

Here are the commands in text:

sed -i.bak s/9090/9095/g monitors/analytics-agent/conf/analytics-agent.properties;sed -i.bak2 s/9091/9096/g monitors/analytics-agent/conf/analytics-agent.properties;sed -i.bak3 s/ad.dw.log.level=INFO/ad.dw.log.level=INFO/g monitors/analytics-agent/conf/analytics-agent.properties;sed -i.bak4 s/ad.dw.console.log.level=OFF/ad.dw.console.log.level=INFO/g monitors/analytics-agent/conf/analytics-agent.properties;sed -i.bak s,'eval exec "$JAVA_CMD"','eval exec "$JAVA_CMD" --add-opens java.base/java.lang=ALL-UNNAMED',g monitors/analytics-agent/bin/analytics-agent.sh;$MACHINE_AGENT_HOME/updateAnalyticsAgent.sh $MACHINE_AGENT_HOME;./monitors/analytics-agent/bin/analytics-agent.sh start

4. As soon as the Analytics Agent Code Engine application started, verify its status in AppDynamics Web Console.

This example shows a healthy agent:

5. Define two new variables in the source code of Node.js application to be monitored. The hostname and port of the Analytics Agent. See the example below.

require("appdynamics").profile({

  controllerHostName: 'myaccount.saas.appdynamics.com',

  controllerPort: 443,

  // If SSL, be sure to enable the next line

  controllerSslEnabled: true, // Set to true if controllerPort is SSL

  accountName: 'myaccount',

  accountAccessKey: '******', //required

  applicationName: 'node-app',

  tierName: 'web',

  nodeName: 'process',

  analytics: {

    host: ‘a5.1i3xxlcwicez.svc.cluster.local’,

    port: 80 }

  });

If the Analytics agent is shared by multiple applications in multiple projects, then you should use the private domain.

The port is 80 (it’s possible to configure SSL and use port 443 which is not covered here).

6. Create some test events from the node-appd application. For example

• Open the application URL from a browser. Log into the application with a wrong password.
• In the AppDynamics Analytics tab, you can run a query using the Cisco AppDynamics Query Language (ADQL) to perform a new search which should display the generated events. See the example below.