Dynatrace automatically derives tags from your Kubernetes/OpenShift labels. This enables you to automatically organize and filter all your monitored Kubernetes/OpenShift application components.
It's recommended that you define additional metadata at the deployed system. For Kubernetes-based applications, you can simply use Kubernetes annotations. Dynatrace automatically detects and retrieves all Kubernetes and OpenShift annotations for pods that are monitored with a OneAgent code module. This enables you to use automated tagging rules, based on existing or custom metadata, to define your filter sets for charts, alerting, and more. These tags and rules can be changed and adapted any time and will apply almost immediately without any change to the monitored environment or applications.
Automatic detection of Kubernetes properties and annotations
- Kubernetes base pod name: User-provided name of the pod the container belongs to.
- Kubernetes container: Name of the container that runs the process.
- Kubernetes full pod name: Full name of the pod the container belongs to.
- Kubernetes namespace: Namespace to which the containerized process is assigned.
- Kubernetes pod UID: Unique ID of the related pod.
Leverage Kubernetes labels in Dynatrace
Kubernetes-based tags are searchable via Dynatrace search. This allows you to easily find and inspect the monitoring results of related processes running in your Kubernetes or OpenShift environment. You can also leverage Kubernetes tags to set up fine-grained alerting profiles. Kubernetes tags also integrate perfectly with Dynatrace filters.
Import your labels and annotations
Dynatrace automatically detects all labels attached to pods at application deployment time. All you have to do is grant sufficient privileges to the pods that allow for reading of the metadata from the Kubernetes REST API endpoint. In this way, the OneAgent code modules can read these labels directly from the pod.
Note: Only code modules can be tagged in OpenShift pods.
Grant viewer role to service accounts
In OpenShift, every pod is associated with a service account that's used to authenticate the pod's requests to the Kubernetes API. If not otherwise specified, the pod uses the
default service account of its OpenShift project.
Each OpenShift project has its own set of service accounts and thus also its own project-scoped
default service account. The labels of every pod, whose service account has view permissions, will be imported to Dynatrace automatically.
The following steps show you how to add view privileges to the
default service account in the
project1 project. You need to repeat these steps for all service accounts and projects you want to enable for Dynatrace.
Create the following
Role, it will allow a service account to view the necessary metadata about your namespace
project1 via the Kubernetes REST API:
# dynatrace-oneagent-metadata-viewer.yaml kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: project1 name: dynatrace-oneagent-metadata-viewer rules: - apiGroups: [""] resources: ["pods"] verbs: ["get"]
oc -n project1 create -f dynatrace-oneagent-metadata-viewer.yaml
Role to the
default service account for the
Role to take effect:
oc -n project1 policy add-role-to-user dynatrace-oneagent-metadata-viewer --role-namespace="project1" -z default
Alternatively, OpenShift also allows you to bind the
Role to all service accounts in a project.
oc -n project1 policy add-role-to-group dynatrace-oneagent-metadata-viewer --role-namespace="project1" system:serviceaccounts:project1
Your OpenShift labels will be automatically attached as Kubernetes tags to all monitored OpenShift processes in your Dynatrace environment (see example below).