Try it free

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.

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

Derive or assign primary Grail tags from existing signal fields at ingest-processing time using OpenPipeline primary Grail tag rules. Use OpenPipeline for enrichment only when earlier-stage enrichment isn't sufficient. OpenPipeline runs after pipeline routing, so tags derived here can't influence which pipeline a record enters.

Use it only:

  • To promote existing record fields to primary_tags.* when provider field names differ across record types—for example, to map cloud and Kubernetes tag fields or when each cloud provider uses a different field name for the same tag.
  • When the source data needs transformation or combination of multiple fields before it can become a primary Grail tag.
  • As a fallback when earlier-stage enrichment isn't possible, or the central tag configuration doesn't cover your use case.

Related topics

  • Organize your data with primary Grail fields and tags
  • Primary Grail fields and tags
  • Differences between classic auto-tagging and primary Grail tags
  • Enrich Kubernetes telemetry with primary Grail fields and tags
  • Enrich OneAgent telemetry with primary Grail fields and tags
  • Plan your tagging strategy
  • Scope Dynatrace configuration with DQL matchers
  • Configure security context
  • Configure cost allocation
Related tags
Dynatrace Platform