Try it free

Enrich Google Cloud telemetry with primary Grail fields and tags

  • Latest Dynatrace
  • How-to guide
  • 8-min read
  • Published Jul 23, 2026

Dynatrace version 1.348+

This documentation describes the new tagging model for Latest Dynatrace. Some capabilities 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.

Primary Grail fields and tags are the basis for segments, pipeline routing, bucket assignment, Grail permissions, and cost allocation, applied consistently across logs, metrics, spans, events, and Smartscape entities.

This page covers enriching telemetry from Google Cloud Platform monitoring.

Google Cloud has two kinds of metadata: labels (key-value pairs on resources) and tags (key-value pairs referenced by tag IDs, such as payroll/app). Both can be promoted to primary Grail fields and tags.

Enrichment guidance

Dynatrace automatically populates the following primary Grail fields on all telemetry from your Google Cloud connection, with no additional configuration:

  • gcp.project.id (permission-relevant)
  • gcp.region

If filtering, routing, and access control at the project or region level cover your use case, there's nothing else to do. For all other cases, Dynatrace offers the following options to make your Google Cloud labels and tags available as primary Grail fields and tags.

  • Option 1: Recommended Promote Google Cloud labels and tags with central configuration. Covers most use cases.
  • Option 2: OpenPipeline for ingest-time enrichment. Fall back to this when the previous option doesn't fit.

The following options are alternatives, not sequential steps.

1. Promote Google Cloud labels and tags with central configuration

Dynatrace version 1.348+

Central configuration for cloud tags is expected to be available in September 2026. Until it ships, use Google Cloud connection settings to enrich your Google Cloud services data.

If your Google Cloud resources already carry labels or tags that represent the context you want, such as team ownership, environment, cost center, or a security boundary, promote them with central configuration builtin:ingest.enrichment.config. No changes to your Google Cloud resources are required. This option has two parts, A and B.

A. Select your Google Cloud labels and tags for enrichment in central configuration

Create rules to select existing Google Cloud labels or tags (source) and map them to primary fields (target) like dt.security_context, dt.cost.costcenter, and dt.cost.product.

You can also make the existing labels and tags available on all telemetry by choosing Kubernetes or cloud tag as target. This forwards them onto telemetry as the standard fields gcp.labels.<key> and gcp.tags.<tag-id>. Promote them to primary_tags.* tags in part B.

To create a rule:

  1. Go to central configuration builtin:ingest.enrichment.config and select New rule.
  2. For Rule type, select GCP label for a Google Cloud label, or GCP tag for a Google Cloud tag.
  3. Under Source, enter the key you want to map.
    • For a GCP label, enter the label key, for example, team.
    • For a GCP tag, enter the tag ID, for example, payroll/app.
  4. Under Target, select how you want to use the label or tag.
    • For a primary field, select Security context, Cost center, or Cost product.
    • To forward the label or tag for later promotion to a primary tag, select Kubernetes or cloud tag.
  5. Review the Resulting mapping preview. It shows how the label or tag is mapped on all telemetry, for example, gcp.labels.team -> dt.security_context when you select Security context as the target.
  6. Select Create.

Google Cloud labels are forwarded to telemetry as gcp.labels.<key>, and Google Cloud tags as gcp.tags.<tag-id>. For example, the tag ID payroll/app becomes gcp.tags.payroll.app. Values are stored as originally set.

Note: In the central configuration you can also add a Custom rule which enables you to enrich a static string literal on all telemetry. The static literal can be used as Security context, Cost center, or Cost product, or directly as a Primary tag.

B. Promote forwarded cloud labels and tags to primary tags in OpenPipeline

Forwarded Google Cloud labels and tags arrive in OpenPipeline as gcp.labels.<key> and gcp.tags.<tag-id>, which are not yet primary tags. To make them primary_tags.* tags that you can use uniformly across Dynatrace, review your OpenPipeline primary Grail tag rules.

Define the target primary_tags.<key> once and list the source fields to read from, in order. The first source with a non-null value is used to set the target.

Google Cloud metadata lands under different field names on telemetry data, for example, gcp.labels.team, and on Smartscape nodes, for example, `tags:gcp`[team]. This is why we recommend defining two source entries for the Google Cloud label:

  • gcp.labels.team: covers telemetry like logs, metrics, spans, and events.
  • `tags:gcp`[team]: covers Google Cloud Smartscape nodes. Dynatrace version 1.343+

Listing both under the same primary_tags.team target covers all data types with one rule. You can also add the equivalent fields from other cloud providers to the same rule, so a single primary_tags.team definition works across AWS, Azure, Google Cloud, and Kubernetes.

For the full setup, see Set primary Grail tag rules in OpenPipeline.

2. OpenPipeline for ingest-time enrichment

As a last resort, use the general OpenPipeline processing feature set to influence how ingested signals (metrics, logs, spans, events, and Smartscape nodes) are enriched. Among other things, you can add a primary_tags.* field to records with a processing step. Use this only when the other options don't cover your use case.

Scopes and precedence

Central configuration rules can be defined at different deployment scopes in Dynatrace settings:

  • AWS account: The rules apply only to telemetry from that account.
  • Azure subscription: The rules apply only to telemetry from that subscription.
  • GCP project: The rules apply only to telemetry from that project.
  • Kubernetes cluster: The rules apply only to telemetry from that Kubernetes cluster.
  • Host group: The rules apply only to telemetry from that host group.
  • Environment: The rules apply to all telemetry.

Environment-wide rules are appended after the project-specific ones. Rules are evaluated in order, and the first rule for a given target wins. For example, if three rules set dt.security_context, the first match is used.

The cloud scopes AWS account, Azure subscription, and GCP project will only be available for Cloud Platform monitoring connections. Other Dynatrace components, such as OneAgent, Dynatrace Operator, and ActiveGate, don't use those.

Host group scope is used with OneAgent (Host/process property rules and Custom rule type).

Kubernetes cluster scope is used by Dynatrace Operator and ActiveGate (Kubernetes and Custom rule types).

Migrate to central enrichment settings

For now, you can configure label and tag enrichment either on the Google Cloud connection or through central enrichment configuration. Connection-based enrichment will be phased out in the future.

Connections with connection-based enrichment have a Tag and label enrichment setting with a Use new unified enrichment settings toggle:

  • On: the connection uses the centrally managed tag enrichment rules from central configuration.
  • Off: you configure label and tag enrichment individually for this connection.

The first time you turn on the toggle, your existing connection-based label and tag enrichment is migrated to central configuration in the background. This one-time migration happens automatically, with no separate migration step.

Select Ingest enrichment configuration to open the central enrichment configuration.

For connection settings details, see Google Cloud connection settings.

Query enriched data in Grail

Primary Grail fields and tags appear as top-level fields and can be queried with DQL.

Filter logs by project and team
fetch logs
| filter gcp.project.id == "dynatrace-gcp-extension" AND primary_tags.team == "payments"
Cost allocation aggregation
fetch bizevents
| filter dt.cost.costcenter == "it_services"
| summarize sum(value), by: {dt.cost.product}
Security context filtering
fetch logs
| filter dt.security_context == "confidential"
| filter gcp.region == "europe-west3"

Limitations

  • Changes in central enrichment configuration builtin:ingest.enrichment.config or OpenPipeline primary Grail tag rules builtin:openpipeline.primary-grail-tag can take up to 10 minutes to propagate.
  • A newly enriched primary tag key can take up to 24 hours to appear in the filter dropdowns of Dynatrace apps. This is temporary. The data is correctly enriched and can be queried and filtered with DQL.
  • Dynatrace Classic is not supported.

Related topics

  • Primary Grail fields and tags
  • Organize your data with primary Grail fields and tags
  • Enrich OneAgent telemetry with primary Grail fields and tags
  • Enrich Kubernetes telemetry with primary Grail fields and tags
  • Set primary Grail tag rules in OpenPipeline
  • Create a GCP connection (Preview)
  • Primary Grail fields
  • Plan your tagging strategy
  • Best practices for enriching primary Grail fields and tags
Related tags
Dynatrace Platform