topic Re: Process Group detection for OpenShift ScaledJobs created by Red Hat Custom Metrics Autoscaler in Open Q&A

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

Michael_M — Tue, 15 Sep 2026 07:35:17 GMT

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.

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

sujit_k_singh — Wed, 16 Sep 2026 05:29:03 GMT

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

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

Michael_M — Wed, 16 Sep 2026 12:50:28 GMT

Hi Sujit,

thanks for your reply.

For the Process Group detection rule I currently use the rules under "Cloud application and workload detection" in Managed. Did you mean with "Process Group detection rule" the "Process grouping rules"?
Regards
Michael

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

sujit_k_singh — Wed, 16 Sep 2026 22:32:49 GMT

Hi Michael,

As you are currently using Cloud application and workload detection, but it controls how Dynatrace names and maps Kubernetes workloads, it determines what gets detected as a workload and how it's labeled. This is why ScaledJob instances get separate Process Groups by default each generated Job name is treated as a distinct workload.

Yes, I was referring to "Process grouping rules". This is where you can define custom rules to override the default grouping logic and consolidate processes into one logical Process Group regardless of their Kubernetes workload name.

Thanks,

Sujit