Dynatrace’s automatic process group detection is usually pretty good, but sometimes you need to tell it exactly what you’re looking at.
Let’s say you’ve got a bunch of Java applications running, and Dynatrace is lumping them all into one generic "Java Virtual Machine" process group. You want to distinguish between your frontend API, your backend workers, and your scheduled jobs. This is where customizing process group detection and naming comes in.
Here’s a sample Java application startup script. Notice the specific command-line arguments:
/usr/lib/jvm/java-11-openjdk-amd64/bin/java \
-Xmx1024m \
-Dspring.application.name=my-frontend-api \
-Dserver.port=8080 \
-jar /opt/apps/my-frontend-api.jar
And here’s another one for a worker process:
/usr/lib/jvm/java-11-openjdk-amd64/bin/java \
-Xmx2048m \
-Dspring.application.name=my-worker-process \
-Dworker.queue.name=high-priority-tasks \
-jar /opt/apps/my-worker-process.jar
Dynatrace will see both as "Java Virtual Machine." We need to change that.
You’ll do this in the Dynatrace UI. Navigate to Settings > Process automation > Process group detection. Here you can create new rules.
Let’s create a rule for our frontend API. You’ll want to select Process group detection rules and then click Add rule.
For the Rule name, something descriptive like Frontend API Detection is good.
Under Conditions, you’ll specify how Dynatrace identifies these processes. For our Java example, we’ll use Command line arguments.
- Condition type:
Command line arguments - Operator:
contains - Value:
-Dspring.application.name=my-frontend-api
This condition tells Dynatrace: "If a process’s command line includes this specific system property, consider it for this rule."
Now, for Process group naming:
- Name template:
Frontend API - {{.ProcessGroup.CommandLineArguments.contains('-Dspring.application.name=')}}
This template uses a Go template syntax. When Dynatrace finds a process matching the condition, it will extract the value of spring.application.name from the command line and use it as the process group name. The {{.ProcessGroup.CommandLineArguments.contains('-Dspring.application.name=')}} part is a bit of a shortcut here; Dynatrace is smart enough to parse the property value when you use it in the naming template like this. A more robust way to extract the value would be to use a regular expression in a custom property and then reference that property, but for simple cases, this often works.
Let’s refine that naming template. A more precise way to extract the value and use it would involve a custom property. First, go to Settings > Monitored technologies > Java > Custom properties.
Click Add custom property.
-
Name:
SpringAppName -
Value:
{{.ProcessGroup.CommandLineArguments.matches('(?i).*?-Dspring\.application\.name=([^ ]+).*') | group 1}}
This regular expression (?i).*?-Dspring\.application\.name=([^ ]+).* looks for -Dspring.application.name= (case-insensitive) and captures whatever follows it until the next space. The | group 1 tells Dynatrace to extract the first captured group.
Now, back to your Process group detection rule (Frontend API Detection):
- Name template:
Frontend API - {{.ProcessGroup.CustomProperties.SpringAppName}}
This will result in a process group named "Frontend API - my-frontend-api".
You’d create a similar rule for your worker process, perhaps named Worker Process Detection, with the condition -Dspring.application.name=my-worker-process and a naming template like Worker Process - {{.ProcessGroup.CustomProperties.SpringAppName}}.
Why does this work? Dynatrace’s OneAgent monitors processes at a very low level. It inspects command lines, environment variables, and loaded libraries. When you define these rules, you’re essentially providing Dynatrace with specific fingerprints to identify and categorize these processes. The naming template then uses the extracted information to create meaningful, human-readable names for your process groups, making it much easier to navigate and understand your application topology.
The most surprising true thing about process group detection is that you can use a single condition to trigger multiple actions, including setting custom properties, defining detection rules, and even influencing topology analysis beyond just naming.
The next concept you’ll want to explore is how to use these custom properties to create custom metrics and alerts, allowing you to monitor specific aspects of your newly defined process groups.