Isolate Hosts with Dynatrace Host Groups and Rules (2026)

Host groups are a surprisingly blunt instrument for what feels like fine-grained control.

Let’s see Dynatrace in action. Imagine you’ve got a Kubernetes cluster and you want to isolate monitoring for your critical frontend-prod deployment.

apiVersion: dynatrace.com/v1beta1
kind: OneAgent
metadata:
  name: dynakube
  namespace: dynatrace
spec:
  # ... other OneAgent config ...
  hostInjection:
    enabled: true
    # This is where the magic happens for host groups
    oneAgent.openshift.io/group: frontend-prod

When the OneAgent operator sees this annotation on a Pod, it injects the OneAgent into the host running that Pod, and crucially, it assigns that host to the frontend-prod host group within Dynatrace.

The problem Dynatrace host groups solve is contextualization. Without them, you’re staring at a flat list of hundreds of hosts, all spewing metrics. How do you know which ones belong to your frontend-prod service? Host groups let you slice and dice your infrastructure based on logical groupings, making it vastly easier to spot anomalies or performance bottlenecks specific to a particular application or environment.

Internally, Dynatrace uses these host groups to:

Apply specific alerting profiles: You might want aggressive alerts for frontend-prod hosts, but more relaxed alerts for development environments.
Scope custom dashboards: Create a dashboard that only shows metrics for frontend-prod hosts.
Define maintenance windows: Schedule downtime for just the frontend-prod infrastructure without affecting others.
Filter global views: Quickly navigate to the section of Dynatrace that matters most to you.

The oneAgent.openshift.io/group annotation is a common way to achieve this in Kubernetes, but it’s not the only one. You can also use:

Tags: Dynatrace can ingest tags from cloud providers (AWS, Azure, GCP) or Kubernetes labels and automatically create host groups from them. If your Kubernetes nodes have a label like app=frontend-prod, Dynatrace can be configured to create a host group named frontend-prod from that label.
OneAgent configuration files: For non-containerized environments, you can manually edit the ruxitagent.conf file on the host and set the TENANT_CUSTOM_PROPERTIES or HOST_GROUP directives. For example, in ruxitagent.conf:
```
TENANT_CUSTOM_PROPERTIES=hostgroup=frontend-prod
```
After modifying the file, you’d restart the OneAgent service for the changes to take effect.
Dynatrace API: For programmatic management, you can use the Dynatrace Cluster API to create and assign hosts to host groups. This is useful for dynamic environments or complex automation workflows.

The most surprising thing about host groups is how they interact with Dynatrace’s AI, Davis. Davis doesn’t just analyze metrics in isolation; it leverages host group memberships to understand the relationship between different components. When a performance degradation is detected on a frontend-prod host, Davis can correlate it with other hosts in the same frontend-prod group, even if they are running different processes or on different underlying infrastructure, to pinpoint the root cause more effectively. It treats the group as a single logical entity for analysis.

The exact mechanism for how Dynatrace maps external identifiers (like Kubernetes labels or cloud tags) to host groups is configurable. You can define rules within Dynatrace to specify which tags or labels should automatically create or populate host groups, and you can even set up priorities if a host has multiple potential group assignments.

Understanding how to leverage host groups is key to unlocking Dynatrace’s power for granular infrastructure management and intelligent root-cause analysis.

The next concept you’ll likely encounter is how to define custom alerting rules that leverage these host group memberships.