This documentation describes the new tagging model for Latest Dynatrace. Some capabilities relevant to this page, such as central configuration, are still rolling out. If you're currently using Dynatrace Classic auto-tagging, see Dynatrace Classic versus Latest Dynatrace to understand how your existing setup maps to the new model.
To enrich OpenTelemetry traces, metrics, and logs with primary Grail fields and tags, follow this enrichment guide and choose the method that fits your setup.
Once enriched, you can use the same metadata for segments, pipeline routing, bucket assignment, Grail permissions, and cost allocation consistently across traces, metrics, and logs.
For general guidance on primary Grail fields and tags, see Primary Grail fields and tags.
Choose the enrichment method that fits your setup. If none of these apply, fall back to OpenPipeline.
If your OpenTelemetry telemetry reaches Dynatrace via OneAgent injection or the Dynatrace Operator, primary Grail fields such as dt.host_group.id, k8s.cluster.name, and k8s.namespace.name are already populated automatically, with no configuration required. If you route your OTLP directly to Dynatrace or via the OTel Collector, see Recommended: Enrich at source with resource attributes.
You can use the OTel Collector to enrich OTLP telemetry with Kubernetes metadata, including primary Grail fields. See Enrich OTLP requests with Kubernetes data.
Add primary Grail tags directly as OpenTelemetry resource attributes so telemetry is enriched before it leaves the process or by using the OTel Collector. Any resource attribute that follows the primary_tags.<key>=<value> convention is recognized as a primary Grail tag. The dt.security_context, dt.cost.costcenter, and dt.cost.product attributes are also recognized as primary Grail tags automatically.
You can apply resource attributes at the:
OTEL_RESOURCE_ATTRIBUTES environment variable. This applies to all signals from that process.export OTEL_RESOURCE_ATTRIBUTES="primary_tags.team=alpha,primary_tags.app=myapp,dt.security_context=confidential,dt.cost.costcenter=12345"
When a resource attribute is set both by the SDK and by a Collector processor, whichever component writes the value last determines what Dynatrace receives. This is typically the Collector, since it processes telemetry after the SDK emits it. Use upsert deliberately if you want the Collector to override values set at the SDK, or insert to only add the attribute when it isn't already present.
Coming soon
A central primary Grail tag configuration for standalone OpenTelemetry resource attributes is planned, but not yet available. Until it ships, use resource attributes at the SDK or Collector level, or OpenPipeline.
This is a separate path from Kubernetes-side central configuration, which is already available: if your OpenTelemetry data originates from Kubernetes workloads, you can promote namespace labels and annotations to primary Grail tags today. For more information, see Enrich Kubernetes telemetry with primary Grail fields and tags.
If none of these options apply, derive or assign primary tags at ingest with OpenPipeline and the processing stage. You can derive a primary Grail tag from any primary Grail field, resource attribute, or other incoming field. This is useful when the value needs to be computed or combined from multiple sources. Tags enriched this way need to follow the primary_tags.<key>=<value> convention to be recognized.
For security context specifically, dedicated "Set security context" processors are available for spans, logs, and metrics.
Use this as a fallback for environments where source-side or Collector-side enrichment isn't possible. At-source enrichment is always preferred: it makes primary fields and tags available before pipeline routing, so data can be routed to the correct pipeline and bucket from the start. Enrichment applied in OpenPipeline happens after ingest and after routing decisions for that event have been made.
When the same key is set at multiple points, the most recently written value wins as telemetry moves through the pipeline.
OTEL_RESOURCE_ATTRIBUTES, set at the source)The following table shows which enrichment methods apply to each OpenTelemetry signal type.
| Signal | Resource attributes (SDK or Collector) | OpenPipeline |
|---|---|---|
Traces (spans) | ||
Metrics | ||
Logs | ||
Service metrics (derived from spans) 1 | — |
Dynatrace automatically propagates the dt.security_context value, along with other primary Grail fields and tags carried on the resource, from spans to the corresponding service metrics.
Primary Grail fields and tags appear as top-level fields and can be queried with DQL:
fetch spans| filter primary_tags.team == "alpha" AND primary_tags.app == "myapp"
fetch bizevents| filter dt.cost.costcenter == "12345"| summarize sum(value), by: {dt.cost.product}
fetch logs| filter dt.security_context == "confidential"
primary_tags.<key>=<value> naming convention. Resource attributes that don't follow this convention remain regular attributes and are available on the emitting signal but aren't automatically propagated across signal types or to Davis events and problems.