The deployment-scope model described in Plan your tagging strategy provides a natural way to organize Dynatrace configuration along host groups, Kubernetes clusters, namespaces, and cloud accounts. As your environment grows, scope owners often need finer-grained control within their area of responsibility. Dynatrace provides data-driven configuration with DQL matchers that operates on the primary Grail fields and tags already present on your telemetry.
Fine-grained control is provided by DQL matchers that operate directly on data at query time or ingest time. This applies to:
dt.security_context.Because these capabilities operate on data, they support any level of granularity that your enrichment provides.
If your telemetry carries a primary_tags.app tag, you can create a pipeline, bucket, permission, or segment that matches on that tag, regardless of whether the data comes from a host group, a Kubernetes namespace, or an API endpoint.
In Dynatrace Classic, configuration was commonly defined at the host, process group instance, or service level. Entity-level scopes come with significant drawbacks:
Dynatrace now supports filter conditions on scoped configurations. These conditions are restricted to:
These attributes are available at agent startup, at the edge, and in data-driven processing such as service detection.
A scope owner—for example, a Kubernetes cluster owner, or a host group owner—can configure behavior at scale while still targeting subsets of applications with a single configuration entry.
Using primary Grail fields and tags as the basis for all matchers offers several advantages over entity-level configuration:
For Kubernetes scopes, you can also use selected Kubernetes labels as filter conditions, provided the agent, edge components, and service detection all have access to them. This is useful for Kubernetes-native teams that already use labels to organize workloads.
The supported scopes for Kubernetes-aware configurations include:
Within these scopes, filter conditions can reference primary Grail fields, primary Grail tags, and Kubernetes labels to target specific workloads.