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 · Accepted solution]

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

[Michael_M]

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

[sujit_k_singh]

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