Best practices for enriching primary Grail fields and tags

Latest Dynatrace
Best practices
2-min read

Enriching primary Grail fields and tags correctly makes it easier to filter, route, and govern your observability data. The approaches on this page are ordered from zero-configuration defaults to ingest-time derivation. Start at the top and move to the next only if the previous approach doesn't meet your needs. Each approach adds configuration effort, so apply only as much as your use case requires. For domain-specific guidance, see OneAgent and Kubernetes.

Check built-in Dynatrace coverage

Enrich at deployment

Configure centrally

Use OpenPipeline for ingest-time enrichment

Check built-in Dynatrace coverage

Many primary Grail fields are automatically populated: the Kubernetes cluster and namespace, host group, and cloud account require no configuration. If these cover your filtering and access needs, no further setup is required.

Enrich at deployment

Dynatrace reads the tags already set on your hosts, containers, and cloud resources. You configure which existing tags to promote, without having to change individual deployments. Tags enriched at the source are available before pipeline routing, so they can be used for bucket assignment and permissions from the earliest processing stage.

For OneAgent deployments, see OneAgent.
For Kubernetes deployments, see Kubernetes.
For OpenTelemetry deployments managed with Bindplane, add the Dynatrace Enrichment Processor to each Bindplane pipeline or configuration to set primary_tags.*, dt.security_context, dt.cost.costcenter, and dt.cost.product before data reaches Dynatrace.

Configure centrally

Promote existing cloud tags, Kubernetes labels, or host properties to primary Grail tags through central enrichment rules, without modifying individual deployments.

Promote standard tags from Kubernetes environments to primary Grail tags.
Promote cloud provider tags (AWS, Azure, Google Cloud) to primary Grail tags.
Promote host and process properties to primary Grail tags.
Write a custom literal value as a primary Grail tag or field.

Use OpenPipeline for ingest-time enrichment

Use OpenPipeline for enrichment only when earlier-stage enrichment isn't sufficient. You can enrich at ingest time in two places in OpenPipeline:

Before routing: primary Grail tag rules. OpenPipeline primary Grail tag rules derive or assign primary Grail tags from existing signal fields before pipeline routing. Because the tags exist at routing time, you can use them for dynamic pipeline selection and bucket assignment. For custom access boundaries, derive dt.security_context from the relevant primary tags or fields. Use these rules to promote existing record fields to primary_tags.*, for example when provider field names differ across record types, such as cloud and Kubernetes tag fields.
Within a custom pipeline: processors. When the source data needs transformation or a combination of multiple fields before it can become a primary Grail tag, add a processor to your custom pipeline. Routing selects the custom pipeline before its processors run, so tags derived by processors in that selected pipeline can't influence that route. Pipeline groups can run base-pipeline processors before the member-pipeline placeholder.

Use OpenPipeline as a fallback when earlier-stage enrichment isn't possible, or the central tag configuration doesn't cover your use case.

Best practices for enriching primary Grail fields and tags

Latest Dynatrace

Best practices

2-min read

Enrich at deployment

For OneAgent deployments, see OneAgent.
For Kubernetes deployments, see Kubernetes.
For OpenTelemetry deployments managed with Bindplane, add the Dynatrace Enrichment Processor to each Bindplane pipeline or configuration to set primary_tags.*, dt.security_context, dt.cost.costcenter, and dt.cost.product before data reaches Dynatrace.

Configure centrally

Promote existing cloud tags, Kubernetes labels, or host properties to primary Grail tags through central enrichment rules, without modifying individual deployments.

Promote standard tags from Kubernetes environments to primary Grail tags.
Promote cloud provider tags (AWS, Azure, Google Cloud) to primary Grail tags.
Promote host and process properties to primary Grail tags.
Write a custom literal value as a primary Grail tag or field.

Use OpenPipeline for ingest-time enrichment

Use OpenPipeline for enrichment only when earlier-stage enrichment isn't sufficient. You can enrich at ingest time in two places in OpenPipeline:

Before routing: primary Grail tag rules. OpenPipeline primary Grail tag rules derive or assign primary Grail tags from existing signal fields before pipeline routing. Because the tags exist at routing time, you can use them for dynamic pipeline selection and bucket assignment. For custom access boundaries, derive dt.security_context from the relevant primary tags or fields. Use these rules to promote existing record fields to primary_tags.*, for example when provider field names differ across record types, such as cloud and Kubernetes tag fields.
Within a custom pipeline: processors. When the source data needs transformation or a combination of multiple fields before it can become a primary Grail tag, add a processor to your custom pipeline. Routing selects the custom pipeline before its processors run, so tags derived by processors in that selected pipeline can't influence that route. Pipeline groups can run base-pipeline processors before the member-pipeline placeholder.

Use OpenPipeline as a fallback when earlier-stage enrichment isn't possible, or the central tag configuration doesn't cover your use case.

Best practices for enriching primary Grail fields and tags

Check built-in Dynatrace coverage

Enrich at deployment

Configure centrally

Use OpenPipeline for ingest-time enrichment

Related topics

Best practices for enriching primary Grail fields and tags

Check built-in Dynatrace coverage

Enrich at deployment

Configure centrally

Use OpenPipeline for ingest-time enrichment

Related topics