We are running Dynatrace Managed 1.344 on OpenShift and are currently looking for the best way to handle Process Group detection for pods created by the Red Hat Custom Metrics Autoscaler using ScaledJob.
Current behavior
For a regular workload, the generated pod name is stable enough for Dynatrace workload detection, for example:
example-application-
The related containers/processes are grouped into the same Process Group as expected.
With a ScaledJob, however, the Custom Metrics Autoscaler creates separate Kubernetes Jobs with generated names such as:
example-application-a1b2c
example-application-x7y8z
example-application-k9m3n
Each Job creates its own pod. Dynatrace then creates a separate Process Group for each of these instances instead of grouping them under one logical application.
Our current setup:
- OpenShift
- Red Hat Custom Metrics Autoscaler / KEDA
- ScaledJob
- Dynatrace Managed 1.344
- Cloud application and workload detection enabled
- No additional Process Group detection rules
From our understanding, this is related to the Kubernetes workload / base pod name being different for every generated Job.
Question
How are you handling Process Group detection for ScaledJob workloads?
Are you using:
- DT_RELEASE_PRODUCT as a stable grouping identifier
- custom Kubernetes workload detection rules
- labels/annotations propagated to the generated Job/Pod
- unified Process Grouping Rules
- or another approach?
Ideally, we would like all Jobs and Pods created by the same ScaledJob to be represented by one logical Process Group, while still keeping other Kubernetes workloads unaffected.
