Enable Container Visibility
Update the Controller to 4.4.3 or higher if you have not already done so. To enable Kubernetes visibility in your environment, edit the following parameters:
• Controller
• sim.machines.tags.k8s.enabled: The value defaults to true. The global tag’s enabled flag has priority over this.
• sim.machines.tags.k8s.pollingInterval: The value defaults to one minute. The minimum value you can set for the polling interval is 30 seconds.
• Machine Agent
• k8sTagsEnabled: The value defaults to true and is specified in the ServerMonitoring.yml file.
Continue with Using Docker Visibility with Red Hat OpenShift. You can use the example DaemonSet, the sample Docker image for Machine Agent, and the sample Docker start script to quickly set up the Standalone Machine Agent. You can find it here: https://docs.appdynamics.com/appd/21.x/21.3/en/infrastructure-visibility/monitor-containers-with-docker-visibility/use-docker-visibility-with-red-hat-openshift
Register the Container ID as the Host ID
Install an App Server Agent in each container in a Kubernetes pod to collect application metrics. If multiple App Server Agents are running in the same pod (in the RedHat OpenShift platform, for example), you must register the container ID as the unique host ID on both the App Server Agent and the Machine Agent to collect container-specific metrics from the pod. Kubernetes pods can contain multiple containers, and they share the same host ID. The Machine Agent cannot identify different containers running in a pod unless each container ID is registered as the host ID.
To register the container ID as the host ID, follow these steps:
Step 1. Get the container ID from the cgroup:
cat /proc/self/cgroup | awk -F ‘/’ ‘{print $NF}; | head -n 1
Step 2. Register the App Server Agents:
-Dappdynamics.agent.uniqueHostId=$(sed -rn ‘1s#.*/##; 1s/(.{12}).*/\1/p’ /proc/self/cgroup)
Note
For OpenShift, run the following command:
-Dappdynamics.agent.uniqueHostId=$(sed -rn ‘1s#.*/##; 1s/docker-(.{12}).*/\1/p’ /proc/self/cgroup)
Step 3. Register the Machine Agent:
-Dappdynamics.docker.container.containerIdAsHostId.enabled=true
Instrument Applications with Kubernetes
There are several approaches to instrumenting applications deployed with Kubernetes, and which one you choose will depend on your particular requirements and DevOps processes. In order to monitor an application container with AppDynamics, an APM Agent must be included in that container. This can be done in a number of ways:
• Using an appropriate base image that has the APM agent pre-installed
• Loading the agent dynamically as part of the container startup
• Loading the agent and dynamically attaching to a running process (where the language runtime supports it)
The third option is usually applicable only to Java-based applications since the JVM supports Dynamic Attach, which is a standard feature of the AppDynamics Java APM Agent. For the other options, it is common practice to make use of standard Kubernetes features such as Init Containers, ConfigMaps, and Secrets.
Deploy the Machine Agent on Kubernetes
AppDynamics Machine Agent can be deployed in a single container image, without the need for an init container. By default, the Machine Agent is deployed to the cluster as a DaemonSet to distribute each agent instance evenly across all cluster nodes. Where required, the DaemonSet can be configured with node affinity rules or node anti-affinity rules to ensure that it is deployed to a desired set of nodes and not across the entire cluster.
In order to harvest pod metadata, the service account used to deploy the machine agent must have the cluster-reader role in OpenShift. The “cluster-reader” role is also required for the Kubernetes extensions to the machine agent. The following CLI command is an example of assigning the cluster-reader role to the appd service account in OpenShift:
