Dynatrace provides integrated Log management and analytics for your Kubernetes environments by either running the OneAgent Log module or integrating with log collectors such as Fluent Bit, Dynatrace OpenTelemetry Collector, Logstash, or Fluentd.
Dynatrace provides a flexible approach to Kubernetes observability where you can pick and choose the level of observability you need for your Kubernetes clusters. The Dynatrace Operator manages all the components needed to get the data into Dynatrace for you. This also applies to collecting logs from Kubernetes containers. Depending on the selected observability option, the Dynatrace Operator configures and manages the Log module to work in conjunction with or without a OneAgent on the node.
Log monitoring value
Kubernetes platform monitoring (optional: + Application observability)
Kubernetes platform monitoring + Full-Stack observability
Auto discovery of container logs
Control ingest via annotations and labels
Log enrichment with Kubernetes metadata
Log enrichment with process context
Report logs to different Dynatrace environments
Dynatrace Operator for managing the rollout and lifecycle
For pods with Application observability enabled
Before installing Dynatrace on your Kubernetes cluster, ensure that you meet the following requirements:
kubectl
CLI is connected to the Kubernetes cluster that you want to monitor.kubectl
or oc
commands.See supported Kubernetes/OpenShift platform versions and distributions.
The OneAgent Log Module is not yet supported on GKE Autopilot clusters.
The OneAgent Log module reads logs from containerd and cri-o containers. Other container runtimes aren't supported.
Kubernetes and OpenShift (with future support for GKE Autopilot) are automatically detected during the installation. The necessary manifests are applied as required. Follow the steps below:
Install Dynatrace Operator
helm install dynatrace-operator oci://public.ecr.aws/dynatrace/dynatrace-operator \--set "csidriver.enabled=false"--create-namespace \--namespace dynatrace \--atomic
Edit the values.yaml
sample from GitHub, and then run the install command, passing the YAML file as an argument:
helm install dynatrace-operator oci://public.ecr.aws/dynatrace/dynatrace-operator \--create-namespace \--namespace dynatrace \--atomic \-f values.yaml
Create secret for access tokens
Create a secret named dynakube
for the Dynatrace Operator token and data ingest token obtained in Tokens and permissions required.
kubectl -n dynatrace create secret generic dynakube --from-literal="apiToken=<OPERATOR_TOKEN>" --from-literal="dataIngestToken=<DATA_INGEST_TOKEN>"
Create your DynaKube custom resource YAML file.
You can review the available parameters or how-to guides, and adapt the DynaKube custom resource according to your requirements.
apiVersion: dynatrace.com/v1beta3kind: DynaKubemetadata:name: dynakubenamespace: dynatrace# annotations:# feature.dynatrace.com/oneagent-privileged: "true" # Required on Openshiftspec:# Link to api reference for further information: https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/reference/dynakube-parametersapiUrl: https://ENVIRONMENTID.live.dynatrace.com/apimetadataEnrichment:enabled: truelogMonitoring: {}activeGate:capabilities:- kubernetes-monitoringresources:requests:cpu: 500mmemory: 512Milimits:cpu: 1000mmemory: 1.5Gitemplates:logMonitoring:imageRef:repository: public.ecr.aws/dynatrace/dynatrace-logmoduletag: <tag>tolerations:- effect: NoSchedulekey: node-role.kubernetes.io/masteroperator: Exists- effect: NoSchedulekey: node-role.kubernetes.io/control-planeoperator: Exists
To retrieve the <tag>
version for the logMonitoring
template:
1.311.70.20250416-094918
.Apply the DynaKube custom resource
Run the command below to apply the DynaKube custom resource, making sure to replace <your-DynaKube-CR>
with your actual DynaKube custom resource file name. A validation webhook will provide helpful error messages if there's a problem.
kubectl apply -f <your-DynaKube-CR>.yaml
optional Verify deployment
Verify that your DynaKube is running and all pods in your Dynatrace namespace are running and ready.
> kubectl get dynakube -n dynatraceNAME APIURL STATUS AGEdynakube https://<ENVIRONMENTID>.live.dynatrace.com/api Running 45s
In a default DynaKube configuration, you should see the following pods:
> kubectl get pods -n dynatraceNAME READY STATUS RESTARTS AGEdynakube-activegate-0 1/1 Running 0 55sdynakube-logmonitoring-grrnd 1/1 Running 0 55sdynakube-logmonitoring-ptjgk 1/1 Running 0 55sdynakube-logmonitoring-rtc2p 1/1 Running 0 55sdynatrace-oneagent-csi-driver-2twgv 4/4 Running 0 5mdynatrace-oneagent-csi-driver-jbwdv 4/4 Running 0 5mdynatrace-oneagent-csi-driver-t68tt 4/4 Running 0 5mdynatrace-operator-74dbb44b57-g58mn 1/1 Running 0 5mdynatrace-webhook-59b69958d6-82wlr 1/1 Running 0 5mdynatrace-webhook-59b69958d6-d9vqd 1/1 Running 0 5m
As the OneAgent Log module is deployed as DaemonSet you should have a Log monitoring pod on each node.
Kubernetes Log monitoring requires Dynatrace Platform Subscription (DPS) and is licensed by the ingested gibibyte (GiB) volume.
You can configure log ingestion rules in Dynatrace to control which logs should be collected from your Kubernetes environment. The rules leverage Kubernetes metadata and other common log entry attributes to determine which logs are to be ingested. The standard log processing features from OneAgent, including sensitive data masking, timestamp configuration, log boundary definition, and automatic enrichment of log records, are also available for Kubernetes logs.
See Stream Kubernetes logs with OneAgent Log Module for a detailed description, use cases, and REST API examples.