Set up PSA in Azure AKS

Set up the Web Monitoring PSA and API Monitoring PSA in Azure AKS as follows. If you want to set up PSA in an existing Kubernetes cluster, skip the Create the Kubernetes Cluster section.

Deploy Manually Deploy Using the Automation Script
  1. Create the Kubernetes Cluster.
  2. Pull the Docker image
  3. Tag and push images to the Registry
  4. Deploy PSA Manually
  5. Monitor the Kubernetes cluster
  1. Create the Kubernetes Cluster
  2. Deploy PSA Using the Automation Script
  3. Monitor the Kubernetes cluster
Warning: This document contains links to Azure CLI documentation. Splunk AppDynamics makes no representation as to the accuracy of Azure CLI documentation because Azure CLI controls its own documentation.
Note: You can deploy PSA on an existing Kubernetes cluster in public or private clouds. The automation scripts do not support Kubernetes cluster creation.
Note:
  • If you use the automated script, you must manually set up the Kubernetes cluster and nodes and log in to container registries before deploying PSA.
  • If you use a separate registry, specify the registry in the automated script before deploying PSA:

    1. Open the install_psa file and go to the push_images_to_docker_registry() function.

    2. Under that function, after ${DOCKER_REGISTRY_URL}/, specify the registry names of sum-chrome-agent, sum-api-monitoring-agent, and sum-heimdall.

    3. Under the generate_psa_k8s_deployment() function, update the repository names on the YAML values.

  • You must build the images on the host with the same OS type of Kubernetes cluster nodes.

Create the Kubernetes Cluster

To create a Kubernetes cluster in Azure AKS:

  1. Install and authenticate Azure CLI.
  2. To create a resource group, enter
    CODE 
    RESOURCE_GROUP=heimdall-onprem
az group create --name $RESOURCE_GROUP --location eastus
  3. To create a container registry, enter:
    CODE 
    ACR_NAME=heimdallonprem
az acr create --resource-group $RESOURCE_GROUP --name $ACR_NAME --sku Basic
  4. To create a cluster, enter:
    CODE 
    CLUSTER_NAME=heimdall-onprem
az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --enable-managed-identity \
    --kubernetes-version 1.x.x \
    --node-count 4 \
    --node-vm-size Standard_D8s_v3 \
    --generate-ssh-keys \
    --attach-acr $ACR_NAME
    Note: Replace the kubernetes-version in the above code with one of the supported versions. See Supported Kubernetes versions.
    Note: The node-vm-size and node-count in the above code are selected according to the recommended configuration type. You can specify a configuration of your choice with a different type and number of nodes. See node-vm-size.
    Note: You must be the owner or administrator of the Azure subscription to run the --attach-acr command.

Access the Cluster

To access the Kubernetes cluster, follow theseinstructionsto install kubectl, a utility to interact with the cluster.

To verify that the cluster is running, enter:

CODE 
kubectl get nodes

(Optional) Configure Proxy Server

When you configure a proxy server, it applies to all the domains. Configure a proxy server by specifying the proxy server address on the values.yaml file. See Key-Value Pairs Configuration.

To bypass any domains from the proxy server, perform the following steps:

Note: Configuring the bypass list is supported only on Web Monitoring PSA.
  1. Open the values.yaml file.
  2. Add the domain URLs in the bypassList field under browserMonitoringAgent:
    CODE 
    browserMonitoringAgent:
enabled: true
server: "<proxy server address>"
bypassList: "<specify the domain URLs that you want to bypass separated by semicolon>"
    For example, bypassList: "*abc.com;*xyz1.com;*xyz2.com" Domain URLs that you specify in bypassList are not redirected to the proxy server. You can add any number of domains in the bypassList. All other unspecified domain URLs are redirected to the proxy server.

Configure Proxy Server at a Job Level

You can configure a proxy server and a bypass list for a particular job. Any proxy server URL and bypass list configured at the agent level gets overridden by the proxy server URL and bypass list configured at the job level. Perform the following steps to configure a proxy server at the job level:
  1. Create or edit a Synthetic job.
  2. Select the Run a script option.
  3. Add the following details in the beginning the script:
    CODE 
    '''yml
jobLevelProxyConfig:
  proxyServer: "<proxy-server-address>"
  bypassProxyList: "<list of URLs that you want to bypass, separated by semi-colon>"
'''
    Example:
    CODE 
    '''yml
jobLevelProxyConfig：
  proxyServer: "http://tinyproxy: tinyproxy.svc.cluster.local:8888"
  bypassProxyList: "*abc.com;*xyz1.com;*xyz2.com"
'''

pageUrl = "https://help.splunk.com/en"
driver.get(pageUrl)
assert "Splunk" in driver.title, "Title should contain Splunk"

Pull the Docker Image

Pull the pre-built docker images for sum-chrome-agent, sum-api-monitoring-agent, and sum-heimdall from DockerHub. The pre-built images include the dependent libraries, so you can use these images even when you do not have access to the Internet.

Run the following commands to pull the agent images:
CODE 
docker pull appdynamics/heimdall-psa

docker pull appdynamics/chrome-agent-psa

docker pull appdynamics/api-monitoring-agent-psa

Alternatively, you can also download the .tar file from the Splunk AppDynamics Download Center. This file includes pre-built docker images for sum-chrome-agent, sum-api-monitoring-agent, sum-heimdall, ignite, and the dependent libraries. So, you can use these images when you do not have access to the Internet and DockerHub.

Unzip the .tar file and load the images using the following commands:
  • sum-chrome-agent:
    CODE 
    docker load < ${webAgentTag}
  • sum-api-monitoring-agent:
    CODE 
    docker load < ${apiAgentTag}
  • sum-heimdall:
    CODE 
    docker load < ${heimdallTag}
  • ignite:
    CODE 
    docker load < ${igniteTag}
For example:
CODE 
# Load all Docker images
docker load -i heimdall-25.7.3098.tar
docker load -i api-monitoring-agent-1.0-415.tar
docker load -i chrome-agent-1.0-1067.tar
docker load -i ignite-2.16.0-jdk11.tar
Verify that all the images are loaded:
CODE 
docker images | grep -E "(heimdall|api-monitoring|chrome-agent|ignite)"
When the images are loaded successfully, an output similar to the following is displayed:
CODE 
```
829771730735.dkr.ecr.us-west-2.amazonaws.com/sum/heimdall                   25.7.3098    abc123def456   2 hours ago     500MB
829771730735.dkr.ecr.us-west-2.amazonaws.com/sum/api-monitoring-agent       1.0-415      def456ghi789   2 hours ago     300MB
829771730735.dkr.ecr.us-west-2.amazonaws.com/sum/chrome-agent               1.0-1067     ghi789jkl012   2 hours ago     800MB
apacheignite/ignite                                                         2.16.0       jkl012mno345   2 hours ago     400MB
```

(Optional) Add Custom Python Libraries

Note: This section is applicable only for Web Monitoring PSA.

In addition to the standard set of libraries, you can add the custom Python libraries to the agent for the scripted measurements. To add the custom Python libraries, build an image using the downloaded base image.

  1. Create a Dockerfile and then create RUN directives to run python pip. For example, to install the library algorithms you can create a Dockerfile:
    CODE 
    # Use the sum-chrome-agent image you just loaded as the base image
FROM appdynamics/chrome-agent-psa:<agent-tag>

USER root
RUN apk add py3-pip
USER appdynamics
  
# Install algorithm for python3 on top of that
RUN python3 -m pip install algorithms==0.1.4 --break-system-packages
    Note: You can create any number of RUN directives to install the required libraries.
  2. To build the new image, enter:
    CODE 
    docker build -t sum-chrome-agent:<agent-tag> - < Dockerfile
    The newly built agent image contains the required libraries.

Tag and Push Images to the Registry

You must tag and push the images to a registry for cluster to access it. You have to use the ACR_NAME environment variable while creating the cluster.

To tag the images, enter:

Web Monitoring PSA:

CODE 
ACR_LOGIN_SERVER=$ACR_NAME.azurecr.io
docker tag appdynamics/heimdall-psa:<heimdall-tag> $ACR_LOGIN_SERVER/sum-heimdall:<heimdall-tag>
docker tag appdynamics/chrome-agent-psa:<agent-tag> $ACR_LOGIN_SERVER/sum-chrome-agent:<agent-tag>

API Monitoring PSA:

CODE 
ACR_LOGIN_SERVER=$ACR_NAME.azurecr.io
docker tag appdynamics/heimdall-psa:<heimdall-tag> $ACR_LOGIN_SERVER/sum-heimdall:<heimdall-tag>
docker tag appdynamics/api-monitoring-agent-psa:<agent-tag> $ACR_LOGIN_SERVER/sum-api-monitoring-agent:<agent-tag>

To push the images, enter:

Web Monitoring PSA:

CODE 
az acr login --name $ACR_NAME
docker push $ACR_LOGIN_SERVER/sum-heimdall:<heimdall-tag>
docker push $ACR_LOGIN_SERVER/sum-chrome-agent:<agent-tag>

API Monitoring PSA:

CODE 
az acr login --name $ACR_NAME
docker push $ACR_LOGIN_SERVER/sum-heimdall:<heimdall-tag>
docker push $ACR_LOGIN_SERVER/sum-api-monitoring-agent:<agent-tag>

Deploy PSA Manually

Note: Ensure that you follow the applicable sequence of steps when installing Web Monitoring PSA and API Monitoring PSA, respectively; some steps are common for both procedures.

The application is deployed to the cluster after the images are in the Registry. You use the Helm chart to deploy and create all Kubernetes resources in the required order.

  1. Install Helm following the instructions here.
    1. Create a new namespace to run Apache Ignite pods.
      Warning: Ensure that you first run the Apache Ignite commands and then run the Heimdall commands.
      To create a new namespace for ignite, enter:
      CODE 
      kubectl create namespace measurement
      Before you deploy Apache Ignite, you must set some configuration options. To view the configuration options, navigate to the previously downloaded ignite-psa.tgz file and enter:
      CODE 
      helm show values ignite-psa.tgz > values-ignite.yaml
      Note: If you want to enable persistence, set persistence > enabled. This is an optional configuration.
  2. To deploy the Helm chart using the above-mentioned configuration, navigate to the previously downloaded ignite-psa.tgz file and enter:
    CODE 
    helm install synth ignite-psa.tgz --values values-ignite.yaml --namespace measurement
    All the Kubernetes resources are created in the cluster, and you can use Apache Ignite. After a few seconds, Apache Ignite initializes and is visible in the Controller.
  3. To verify if the pods are running, enter:
    CODE 
    kubectl get pods --namespace measurement
    Proceed to the next steps only after the Apache Ignite pods run successfully. Using a single command, you can deploy the Helm chart, which contains the deployment details. To deploy the agent, use the Helm chart sum-psa-heimdall.tgz in the zip file that you downloaded previously. Before you deploy the Private Synthetic Agent, you must set some configuration options. To view the configuration options, navigate to the previously downloaded sum-psa-heimdall.tgz file and enter:
    CODE 
    helm show values sum-psa-heimdall.tgz > values.yaml

    These are the configuration key-value pairs that you need to edit in the values.yaml file:

    Web Monitoring PSA:
    Configuration Key Value
    heimdall > repository $ACR_LOGIN_SERVER/sum-heimdall
    heimdall > tag <heimdall-tag>
    heimdall > pullPolicy Always
    chromeAgent > repository $ACR_LOGIN_SERVER/sum-chrome-agent
    chromeAgent > tag <agent-tag>
    shepherd > url Shepherd URL
    shepherd > credentials credentials
    shepherd > location agent location
    measurementPodMetadata (Optional) Change the values of enableCustomTolerations, enableCustomAffinity, and enableCustomLabels to true to enable toleration, affinity, and labels:
    PYTHON 
    measurementPodMetadata:
  enableCustomTolerations: false  # Enable use of custom tolerations from this config
  enableCustomAffinity: false     # Enable use of custom affinity rules from this config
  enableCustomLabels: false      # Enable use of custom labels from this config
  automountServiceAccountToken: false # Automatically mount service account token in pods
  labels: # Custom labels to apply to the Pod metadata
    team: "qa"             # Example: assign pod to QA team
    priority: "high"       # Example: set custom priority level
    app.kubernetes.io/managed-by: "scheduler-service"  # Standard label
  tolerations:
    - key: "dedicated"                      # Tolerate nodes tainted with key=dedicated
      operator: "Equal"                     # Match taint value exactly
      value: "measurement"                  # Accept taint with value=measurement
      effect: "NoSchedule"                  # Allow scheduling on such tainted nodes
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: "kubernetes.io/hostname"  # Node must have this hostname
                operator: "In"                 # Match exact value
                values:
                  - "node-1"                   # Only allow node named node-1
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 80                           # Strong preference weight
          preference:
            matchExpressions:
              - key: "topology.kubernetes.io/zone"  # Prefer node in this zone
                operator: "In"
                values:
                  - "us-central1-a"
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: "app"                     # Co-locate with pod having app=frontend
                operator: "In"
                values:
                  - "frontend"
          topologyKey: "kubernetes.io/hostname"  # Must be on the same node
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 50                            # Medium preference
          podAffinityTerm:
            labelSelector:
              matchExpressions:
                - key: "app"                   # Prefer proximity to app=logger pods
                  operator: "In"
                  values:
                    - "logger"
            topologyKey: "topology.kubernetes.io/zone"  # Prefer same zone
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: "app"                     # Do NOT schedule with app=backend pods
                operator: "In"
                values:
                  - "backend"
          topologyKey: "kubernetes.io/hostname"  # Must not be on same node
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 30                            # Low preference to avoid
          podAffinityTerm:
            labelSelector:
              matchExpressions:
                - key: "env"                   # Prefer to avoid pods in env=production
                  operator: "In"
                  values:
                    - "production"
            topologyKey: "topology.kubernetes.io/region"  # Prefer different region
    createChromePodServiceAccount Specify true to create a service account for the Web Monitoring pod.
    API Monitoring PSA:
    Configuration Key Value
    heimdall > repository $ACR_LOGIN_SERVER/sum-heimdall
    heimdall > tag <heimdall-tag>
    heimdall > pullPolicy Always
    apiMonitoringAgent > repository $ACR_LOGIN_SERVER/sum-api-monitoring-agent
    apiMonitoringAgent > tag <agent-tag>
    shepherd > url Shepherd URL
    shepherd > credentials credentials
    shepherd > location agent location
    measurementPodMetadata (Optional) Change the values of enableCustomTolerations, enableCustomAffinity, and enableCustomLabels to true to enable toleration, affinity, and labels:
    PYTHON 
    measurementPodMetadata:
  enableCustomTolerations: false  # Enable use of custom tolerations from this config
  enableCustomAffinity: false     # Enable use of custom affinity rules from this config
  enableCustomLabels: false      # Enable use of custom labels from this config
  automountServiceAccountToken: false # Automatically mount service account token in pods
  labels: # Custom labels to apply to the Pod metadata
    team: "qa"             # Example: assign pod to QA team
    priority: "high"       # Example: set custom priority level
    app.kubernetes.io/managed-by: "scheduler-service"  # Standard label
  tolerations:
    - key: "dedicated"                      # Tolerate nodes tainted with key=dedicated
      operator: "Equal"                     # Match taint value exactly
      value: "measurement"                  # Accept taint with value=measurement
      effect: "NoSchedule"                  # Allow scheduling on such tainted nodes
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: "kubernetes.io/hostname"  # Node must have this hostname
                operator: "In"                 # Match exact value
                values:
                  - "node-1"                   # Only allow node named node-1
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 80                           # Strong preference weight
          preference:
            matchExpressions:
              - key: "topology.kubernetes.io/zone"  # Prefer node in this zone
                operator: "In"
                values:
                  - "us-central1-a"
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: "app"                     # Co-locate with pod having app=frontend
                operator: "In"
                values:
                  - "frontend"
          topologyKey: "kubernetes.io/hostname"  # Must be on the same node
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 50                            # Medium preference
          podAffinityTerm:
            labelSelector:
              matchExpressions:
                - key: "app"                   # Prefer proximity to app=logger pods
                  operator: "In"
                  values:
                    - "logger"
            topologyKey: "topology.kubernetes.io/zone"  # Prefer same zone
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: "app"                     # Do NOT schedule with app=backend pods
                operator: "In"
                values:
                  - "backend"
          topologyKey: "kubernetes.io/hostname"  # Must not be on same node
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 30                            # Low preference to avoid
          podAffinityTerm:
            labelSelector:
              matchExpressions:
                - key: "env"                   # Prefer to avoid pods in env=production
                  operator: "In"
                  values:
                    - "production"
            topologyKey: "topology.kubernetes.io/region"  # Prefer different region
    createApiPodServiceAccount Specify true to create a service account for the API Monitoring pod.

    You can leave the rest of the values set to their defaults or configure them based on your requirements. See Configure Web Monitoring PSA and API Monitoring PSA for details on shepherd URL, credentials, location, and optional key-value pairs.

    Note:

    If the Kubernetes cluster is locked down, and you cannot make cluster-wide configuration, you can make pod-level changes.

    For example, if you want to change the pod-level DNS server setting to use your internal nameservers for DNS name resolution, specify the following details in the values.yaml file:

    Configuration Key Value
    agentDNSConfig:
    enabled: true
    dnsConfig:
    nameservers: ["4.4.4.4"]
    searches: ["svc.cluster.local", "cluster.local"]
  4. To deploy the Helm chart using the above-mentioned configuration, navigate to the previously downloaded sum-psa-heimdall.tgz file and enter:
    CODE 
    helm install heimdall-onprem sum-psa-heimdall.tgz --values values.yaml --namespace measurement
    All the Kubernetes resources are created in the cluster, and you can use Heimdall. After a few seconds, Heimdall initializes and is visible in the Controller.
  5. To verify if the pods are running, enter:
    CODE 
    kubectl get pods --namespace measurement
    To make any changes to the values.yaml after the initial deployment, navigate to the previously downloaded sum-psa-heimdall.tgz file and enter:
    CODE 
    helm upgrade heimdall-onprem sum-psa-heimdall.tgz --values values.yaml --namespace measurement
    Note:

    To remove the deployment:

    CODE 
    helm uninstall heimdall-onprem --namespace measurement

    This is not recommended unless it is required.

Deploy PSA in AKS Using the Automation Script

Download the PSA installation zip file from the Splunk AppDynamics Download Center or from the beta upload tool. This file contains Docker files for sum-chrome-agent, sum-api-monitoring-agent, sum-heimdall, Helm charts, and automation scripts. To build an image for sum-chrome-agent, sum-api-monitoring-agent, and sum-heimdall, ensure that Docker is installed. You can download and install Docker from here if it is not installed.

Perform the following steps to install PSA:

  1. Unzip the PSA installation zip file.
  2. Run the following command to install PSA in AKS:
    CODE 
    ./install_psa -e kubernetes -l -v -u <Shepherd-URL> -a <EUM-account> -k <EUM-key> -c <location-code> -d <location-description> -t <location-name> -s <location-state> -o <location-country> -i <location-latitude> -g <location-longitude> -p <PSA-tag> -r <heimdall-replica-count> -z <agent-type> -m <chrome-agent_min/max-memory> -n <API-agent_min/max-memory> -x <chrome-agent_min/max-CPU> -y <API-agent_min/max-CPU> -b <heimdall_min/max-memory> -f <heimdall_min/max-CPU> -q <ignite-persistence> -w <heimdall_proxy_server>~<api_monitoring_proxy_server>~<web_monitoring_proxy_server> -B <"bypassURL1;bypassURL2;bypassURL3"> -C true -A <serviceaccount-name> -U <userID> -G <groupID> -N <run_as_a_non-root_user> -F <file_system_groupID> -O <override_the_security_context>
    A sample installation command looks like this:
    CODE 
    ./install_psa -e kubernetes -u <Shepherd-URL> -a <EUM-account> -k <EUM-key> -c DEL -d Delhi -t Delhi -s DEL -o India -i 28.70 -g 77.10 -p 23.5 -r 1 -z all -m 100Mi/500Mi -n 100Mi/100Mi -x 0.5/1.5 -y 0.1/0.1 -b 2Gi/2Gi -f 2/2 -q true -w 127.0.0.1:8887~127.0.0.1:8888~127.0.0.1:8889 -B "*abc.com;*xyz1.com;*xyz2.com" -C true -A serviceaccount-name -U 9001 -G 9001 -N true -F 9001 -O true
    The install_psa script can also read parameters from a configuration file, which makes it easier to manage complex installations. Use the following command if you want to install PSA using a .txt configuration file:
    CODE 
    ./install_psa --config <path-to-config-file.txt>
    Note:
    The installation package contains a sample configuration file named config.sample.txt. You can copy this file and edit the values. Any parameter values specified through command line flags will override the values specified in the text file:
    CODE 
    ./install_psa --config production.txt -e kubernetes -r 5 -v
The following table describes the usage of the flags in the command. Asterisk (*) on the description denotes mandatory parameters.
Flag Configuration Key Description
-a EUM_ACCOUNT

*EUM Account

For example, Ati-23-2-saas-nov2
-A SERVICE_ACCOUNT Specify the service account of the sum-chrome-agent and sum-api-monitoring-agent pod.
-b

First value: HEIMDALL_MIN_MEMORY

Second value: HEIMDALL_MAX_MEMORY

*Minimum/Maximum memory in Mi/Gi for sum-heimdall
-B BYPASS_LIST

Specify the domain URLs that you want to bypass from the proxy server.

For example, "*abc.com;*xyz1.com;*xyz2.com"
-c LOCATION_CODE

*Location Code

For example, DEL NY
-C CHROME_PERFORMANCE_LOGS Specify true to enable performance logs on the Chrome browser. The default value is false.
-d LOCATION_DESCRIPTION

*Location Description

For example, 'Delhi, 100001'
-e ENVIRONMENT

*Environment

For example, Docker, Minikube, or Kubernetes.
-f

First value: HEIMDALL_MIN_CPU

Second value: HEIMDALL_MAX_CPU

*Minimum/Maximum CPU for sum-heimdall
-F FS_GROUP Specify the file system group ID of the sum-chrome-agent or sum-api-monitoring-agent container.
-g LOCATION_LONGITUDE

Location Longitude

For example, 77.10
-G RUN_AS_GROUP Specify the group ID that the sum-chrome-agent or sum-api-monitoring-agent container should run as.
-i LOCATION_LATITUDE

Location Latitude

For example, 28.70
-k EUM_KEY

*EUM Key

For example, 2d35df4f-92f0-41a8-8709-db54eff7e56c
-l LOAD_IMAGES Load images to the Minkube environment
-m

First value: CHROME_MIN_MEMORY

Second value: CHROME_MAX_MEMORY

*Minimum/Maximum memory in Mi/Gi for sum-chrome-agent
-n

First value: API_MIN_MEMORY

Second value: API_MAX_MEMORY

*Minimum/Maximum memory in Mi/Gi for sum-api-monitoring-agent
-N RUN_AS_NON_ROOT Specify if the sum-chrome-agent or sum-api-monitoring-agent container should run as a non-root user. The default value is true.
-o LOCATION_COUNTRY

*Location Country

For example, India, United States
-O OVERRIDE_SECURITY_CONTEXT_FOR_WEB_API_MON Specify true to override the security context for Web and API monitoring. The default value is false.
-p TAG

*PSA release tag

For example, 23.12
-q IGNITE_PERSISTENCE Specify true or false to enable or disable Ignite Persistence.
-r HEIMDALL_REPLICA *Heimdall replica count
-s LOCATION_STATE

*Location State

For example, CA
-t LOCATION_CITY

*Location City

For example, Delhi
-u EUM_URL

*Shepherd URL

For example, https://sum-shadow-master-shepherd.saas.appd-test.com/

For the list of Shepherd URLs, See Shepherd URL.
-U RUN_AS_USER Specify the user ID that the sum-chrome-agent or sum-api-monitoring-agent container should run as.
-v VERBOSE Debug mode
-w

First value: HEIMDALL_PROXY

Second value: API_MON_PROXY

Third value: WEB_MON_PROXY

Specify the proxy servers for Heimdall, API, and Web monitoring, separated by a tilde(~).

If you do not need to set up any proxy server, you can leave it blank.
-x

First value: CHROME_MIN_CPU

Second value: CHROME_MAX_CPU

*Minimum/Maximum CPU for sum-chrome-agent
-y

First value: API_MIN_CPU

Second value: API_MAX_CPU

*Minimum/Maximum CPU for sum-api-monitoring-agent
-z AGENT_TYPE

*Agent type

For example, web, api, or all

Monitor the Kubernetes Cluster

The Helm chart sum-psa-monitoring.tgz in the zip you downloaded installs the monitoring stack. This Helm chart installs kube-prometheus-stack along with a custom Grafana dashboard to monitor the Private Simple Synthetic Agent.
Note: Monitoring the deployment is optional; however, we highly recommend that you monitor the cluster to check its health periodically.

Install the Monitoring Stack

  1. To create a separate monitoring namespace, enter:
    CODE 
    kubectl create namespace monitoring
    To review configuration options, enter:
    CODE 
    helm show values sum-psa-monitoring.tgz > values-monitoring.yaml
    This generates a values-monitoring .yaml file that contains all the configuration options. To modify and pass the generated values-monitoring .yaml file while installing the Helm chart, enter:
    CODE 
    helm install psa-monitoring sum-psa-monitoring.tgz --values values-monitoring.yaml --namespace monitoring
  2. After the monitoring stack is installed, you can Launch Grafana (which runs inside the cluster) to view the dashboard. To access Grafana from outside of the cluster, you can configure port forwarding or set up Ingress. To configure port forward to access it locally, enter:
    CODE 
    kubectl port-forward svc/psa-monitoring-grafana 3000:80 --namespace monitoring
  3. Launch localhost:3000 from the browser and log in using the default credentials with username as admin and password as prom-operator. A dashboard named Private Simple Synthetic Agent displays and provides details about the Kubernetes cluster, Apache Ignite, Heimdall, and running measurements.

Uninstall PSA

To uninstall PSA, run the following command:

CODE 
./uninstall_psa -e kubernetes -p

Upgrade PSA in Azure AKS

Pull the Docker Image

Pull the pre-built docker images for sum-chrome-agent, sum-api-monitoring-agent, and sum-heimdall from DockerHub. The pre-built images include the dependent libraries, so you can use these images even when you do not have access to the Internet.

Run the following commands to pull the agent images:

CODE 
docker pull appdynamics/heimdall-psa
docker pull appdynamics/chrome-agent-psa
docker pull appdynamics/api-monitoring-agent-psa

Add Custom Python Libraries

This is an optional step. In addition to the available standard set of libraries, you can add custom Python libraries to the agent to use in scripted measurements. You build a new image based on the image you loaded as the base image.

  1. Create a Dockerfile and then create RUN directives to run pythonpip. For example, to install the library algorithms you can create a Dockerfile:

    CODE 
    # Use the sum-chrome-agent image you just loaded as the base image
FROM appdynamics/chrome-agent-psa:<agent-tag>
USER root
RUN apk add py3-pip
USER appdynamics
# Install algorithm for python3 on top of that
RUN python3 -m pip install algorithms==0.1.4 --break-system-packages
    Note: You can create any number of RUN directives to install the required libraries.

  2. To build the new image, run the following commands:

    Web Monitoring PSA:

    CODE 
    docker build -t sum-chrome-agent:<agent-tag> - < Dockerfile

    API Monitoring PSA:

    CODE 
    docker build -f Dockerfile-PSA -t sum-api-monitoring-agent:<agent-tag> .

    You must build the images on the host with the same OS type of Kubernetes cluster nodes. For example, if you are pushing the image to AWS, then run the following command:

    CODE 
    docker buildx build -f Dockerfile-PSA --platform=linux/amd64 -t sum-api-monitoring-agent:<api-tag> .

    The newly built agent image contains the required libraries.

Tag and Push Images to the Registry

Note: Managed Kubernetes services, such as EKS or AKS, provide container registries where you can push your image. No other configuration is needed. Kubernetes cluster within EKS or AKS will have the access to these images.

You must tag and push the images to a registry for the cluster to access them. You have to use the ACR_NAME environment variable while creating the cluster.

To tag the images, enter:

CODE 
ACR_LOGIN_SERVER=$ACR_NAME.azurecr.io
docker tag sum-heimdall:<heimdall-tag> $ACR_LOGIN_SERVER/sum-heimdall:<heimdall-tag>
docker tag sum-chrome-agent:<agent-tag> $ACR_LOGIN_SERVER/sum-chrome-agent:<agent-tag>
docker tag sum-api-monitoring-agent:<agent-tag> $ACR_LOGIN_SERVER/sum-api-monitoring-agent:<agent-tag>

To push the images, enter:

CODE 
az acr login --name $ACR_NAME
docker push $ACR_LOGIN_SERVER/sum-heimdall:<heimdall-tag>
docker push $ACR_LOGIN_SERVER/sum-chrome-agent:<agent-tag>
docker push $ACR_LOGIN_SERVER/sum-api-monitoring-agent:<agent-tag>

Update the Helm Chart

Follow these steps and update the configuration key-value pairs in the values.yaml file:

Upgrade the PSA

Note: From PSA 23.12 onwards, you must deploy Ignite and Heimdall in a single namespace named measurement.

  1. Navigate to the new Linux distribution folder and run the following command:

    CODE 
    helm install synth ignite-psa.tgz --values values-ignite.yaml --namespace measurement

  2. Wait until the status of Ignite pods changes to running. Then, run the following command:

    CODE 
    helm upgrade heimdall-onprem sum-psa-heimdall.tgz --values values.yaml --namespace measurement

  3. After the status of the new Heimdall and Ignite pods changes to running, uninstall the old Ignite namespace:

    CODE 
    helm uninstall synth -n ignite