Process Group detection for OpenShift ScaledJobs created by Red Hat Custom Metrics Autoscaler

[Michael_M]

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.

[sujit_k_singh]

Hi @Michael_M 

Yes — the recommended approach is to use DT_RELEASE_PRODUCT as a stable grouping identifier. Set it to a fixed value in your ScaledJob pod template so all Jobs and Pods share the same value regardless of their generated names. Then create a Process Group detection rule in Process group detection using DT_RELEASE_PRODUCT as the group identifier with the standalone rule option enabled. This overrides the default Kubernetes workload name-based grouping and consolidates all ScaledJob instances into one logical Process Group without affecting other workloads.

One important thing here is after creating or modifying Process Group detection rules, the changes apply to newly created pods only, existing running pods/jobs won't be regrouped until they are recreated. Since ScaledJobs are ephemeral by nature, this is less of a concern than with long-running deployments.

Thanks,

Sujit