Docker Visibility extends its support to OpenShift Version 3. With this support, you can collect performance data from OpenShift clusters by using the Machine Agent. You install the agent as a DaemonSet on each host in the OpenShift cluster. The DaemonSet monitors each host on the OpenShift cluster and the corresponding containers that have an AppDynamics App Agent running. The process is similar to that for monitoring Kubernetes cluster.
Using Docker Visibility to monitor OpenShift containers is no longer the preferred option and will eventually be deprecated. Use the Cluster Agent instead as described in Monitoring Kubernetes with the Cluster Agent. The Cluster Agent supports OpenShift container visibility, as well as visibility into cluster health and capacity.
The topic provides instructions on how to set up the Machine Agent running as a DaemonSet on an OpenShift cluster. The process includes the following:
- Creating the
- Creating a service account for running the Machine Agent
- Building a Docker image of the Machine Agent
- Deploying the Machine Agent
Before You Start
- This functionality requires a Server Visibility license.
- AppDynamics recommends that you use Docker CE/EE v17.03 or Docker Engine v1.13 with this product. Some data might be missing if you are using previous versions of Docker.
- Make sure you have an OpenShift user account with
cluster-adminrole, such as
admin. This user is responsible for configuring the Machine Agent.
- Install the OpenShift command-line tool,
Setting Java Options
The metaspace max is set to 100mb by default in OpenShift. If your application operates within a small margin of its existing memory resource allocation, you may choose to increase the allocation for the application. AppDynamics recommends allocating additional Metaspace Size space to accommodate the machine agent. Configure the environment variable GC_MAX_METASPACE_SIZE to set the MaxMetaspaceSize parameter. This can be done directly in the deployment, through a config map.
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:
Get the container ID from the
Register the app server agents:
Register the Machine Agent:
Create Project and Service Account
In OpenShift terminology, a project is a mechanism to isolate a group of users and their resources. An administrator can provide individual users or groups with permissions to create projects or manage specific projects. To isolate the Machine Agent from other projects, you can create a project for it.
To do so, create the
Create a service account,
ma, with necessary privileges for the Machine Agent to obtain metrics:
Check whether the current project is machine-agent:
Create a service account.
Service accounts provide a secure way to control OpenShift API access without sharing a regular user’s credentials.
Assign the privileged security context constraints (SCC) to the service account.
SCC determines the permissions and abilities of pods. See Security Permissions for the Service Account for the detailed list of permissions for the service account.
Add cluster-reader to the service account.
Security Permissions for the Service Account
Service account requires the following security permissions to provide maximum isolation to the project under which the Machine Agent is running:
|The cluster-reader role|
This cluster-reader role allows the Machine Agent to read tags from the OpenShift cluster.
|The privileged SCC|
The privileged SCC allows the Machine Agent to be run as the root user.
|Run as privileged container|
Running as the privileged container allows the Machine Agent to perform operations such as:
This privilege is configured in the DaemonSet YAML file as follows:
securityContext: privileged: true
Creating Docker Image of the Machine Agent
Copy the following files to a directory on a machine that can build the Docker image:
Machine Agent Bundle - 64-bit Linux (zip)
Download this bundle and rename it to
See the sample Docker file below.
See the sample script below.
Build the image by using your desired method and make it available in your image registry.
Deploy Machine Agent as DaemonSet
- Modify the sample DaemonSet to point to your Controller. The major sections are highlighted below:
Select the worker node:
Change the following Controller information in the sample DaemonSet:
Specify the Docker image:
Enable the Machine Agent to run as the privileged user:
If you have a different service account name, replace it with the existing one:
- Create DaemonSet below:
Check whether the current project is machine-agent:
Create the machine-agent DaemonSet:
The Machine Agent appears in the UI.
If the Machine agent does not appear in the UI, check the status as follows:
Check the machine-agent DaemonSet.
Check the machine-agent pod.
The pod name is
Check logs whether the last line is "Started AppDynamics Machine Agent Successfully".
Modify the sample DaemonSet to suit your deployment scenario.
You can either use this example Dockerfile or the one given in OpenShift Visibility Manifests.
Sample start-appdynamics Script
You can deploy the Machine Agent with tighter security. Determine the level of security for the project and leverage the following permissions to secure the Machine Agent.
Run the Machine Agent Without cluster-reader Role
Without the cluster-reader role, the Machine Agent cannot read information, such as Pod and ReplicaSet, from the OpenShift cluster. However, it can collect other metrics except for the tags for the app server agent container.
Run the Machine Agent Without Privileged Container Mode
To turn off this privilege, remove the section below from the DaemonSet YAML file.
Without the Privileged Container mode, the Machine Agent cannot read files, such as
/hostroot/proc/<pid>/etc, and therefore it cannot collect metrics such as:
Turning off this privilege has no effect on collecting the app agent container metrics.