Apply primary Grail tags across an example AWS estate

All enrichment rules live in Settings > Collect and capture > Ingest enrichment configuration.

Choose the rule type

The Rule type determines where the rule reads its value and which component evaluates the rule and enriches the data:

For example, a Kubernetes namespace label rule with source app and target Primary tag app reads the app label from the namespace and writes it as primary_tags.app.

Cloud rules apply only to data that arrives through the cloud connection, so OneAgent on a cloud VM doesn't evaluate them. To tag the OneAgent data of that VM as well, add a Host/Process property rule for the same tag, as Tag OneAgent data on EC2 does for the EC2 instance.

For all rule types and form fields, see Configure ingest enrichment rules.

Choose the scope

Set each rule at the scope of the estate it describes rather than environment-wide:

When rules at several scopes target the same field, the narrower-scope rule takes precedence. You can still add a broader environment-wide default, and no rule applies to an estate it doesn't describe. To open the rules for a scope, go to the entity page (for example, the Kubernetes cluster or the host group), open Settings, and search for Ingest Enrichment Config. Alternatively, go to Settings > Collect and capture > Ingest enrichment configuration and select Go to scope to pick the scope. For details, see Scope hierarchy. To automate the setup via the Settings API, use the Ingest enrichment configuration schema. The scope takes the form KUBERNETES_CLUSTER-<id> for a Kubernetes cluster, HOST_GROUP-<id> for a host group, and AWS_ACCOUNT-aws.account.id:<account-id> for an AWS account.

The two fixed values have no source to read, so they use the Custom value rule type with the literal text as Source. A rule only applies in the scope where you add it, so Tag Kubernetes telemetry on EKS, Tag OneAgent data on EC2, and Tag AWS cloud metrics, logs, and entities each include this pair alongside their other rules. Each copy covers the Kubernetes, host, and cloud data in its own scope. For more about these fields, see Configure security context and Configure cost allocation.

Enable metadata enrichment in your DynaKube before label rules take effect:

spec:
  metadataEnrichment:
    enabled: true

The astroshop namespace carries app=astroshop and stage=prod, and each deployment carries a team label. Two rule types map them. Add these rules at the scope of the Kubernetes cluster, together with the two fixed-value rules from Plan the rules:

In Settings > Collect and capture > Ingest enrichment configuration, select the cluster scope and add a rule for each row:

The two Custom value rules write the fixed text astroshop-prod and cc-4711 to all signals in this scope. The rules don't read any field.

Workload and pod rule types require Dynatrace Operator version 1.11+ ActiveGate version 1.347+.

Values resolved from Kubernetes metadata are applied when a pod starts, so restart the pods after changing a label.

For details, see Enrich Kubernetes telemetry with primary Grail fields and tags.

The EC2 instance astroshop-invoice-processor already carries the AWS resource tags team, app, and stage. OneAgent reads them through the instance metadata service and exposes them as host properties named aws.tags.<key>. Access to instance tags in instance metadata is off by default in AWS, so enable it on the instance first. For details, see View tags for your EC2 instances using instance metadata.

Map the properties with Host/Process property rules at the scope of the host group the instance belongs to, again with the two fixed-value rules alongside:

In Settings > Collect and capture > Ingest enrichment configuration, select the host group scope and add a rule for each row:

The two Custom value rules write the fixed text astroshop-prod and cc-4711 to all signals in this scope. The rules don't read any field.

These rules cover everything OneAgent produces for the instance. The AWS_EC2_INSTANCE node is created by the cloud connection and is tagged in Tag AWS cloud metrics, logs, and entities.

Azure VMs follow the same pattern. You can use azure.tags.<key> as source for your OneAgent data.

For details, see Enrich OneAgent telemetry with primary Grail fields and tags, AWS, Azure, and Google Cloud.

The connection produces cloud metrics, cloud logs, and cloud entities for all three AWS resources. Tagging that data takes two settings.

First, create an AWS tag rule per key, which adds the resource tag to the data as aws.tags.<key>. Add these rules at the scope of the AWS account, with the fixed-value pair alongside:

In Settings > Collect and capture > Ingest enrichment configuration, select the AWS account scope and add a rule for each row:

The two Custom value rules write the fixed text astroshop-prod and cc-4711 to all signals in this scope. The rules don't read any field.

Second, create an OpenPipeline primary Grail tag rule to promote aws.tags.team to primary_tags.team.

Repeat for app and stage.

Keep isNull(primary_tags.team) as the matching condition. The default condition is true, which overwrites values other sources already set, including the Operator's team tag on pods and the Lambda function's DT_TAGS value.

Azure and Google Cloud follow the same two-step pattern with Azure tag and GCP label rules, reading azure.tags.<key> and gcp.labels.<key>. For details, see Enrich AWS telemetry with primary Grail fields and tags, Azure, and Google Cloud.

A Lambda function doesn't load the ingest enrichment configuration, so its tags come from the DT_TAGS environment variable that you set in the function configuration:

environment {
  variables = {
    DT_TAGS = "primary_tags.team=checkout primary_tags.app=astroshop primary_tags.stage=prod"
  }
}

Keys are space-separated and keep the primary_tags. prefix. The variable enriches the spans, metrics, and logs that OneAgent emits from the function with the primary Grail tags. The AWS_LAMBDA_FUNCTION Smartscape node is tagged in Tag AWS cloud metrics, logs, and entities, where the isNull() condition keeps the OpenPipeline rule from overwriting DT_TAGS.

For details, see Enrich OneAgent telemetry with primary Grail fields and tags.

RUM data arrives through the rumagent ingest source, which ingest enrichment rules don't reach. Use an OpenPipeline DQL processor instead.

Apply the same processor in each of these six configuration scopes: Settings > Process and contextualize > OpenPipeline > Smartscape events, User events, Events, Davis events, Business events, and Timeseries.

In each scope:

For User sessions, repeat the same steps with a different matching condition, because frontend.name is an array in that scope:

arrayContains(frontend.name, "Astroshop") and isNull(primary_tags.team)

The fieldsAdd DQL is identical.

All five fields are set in each scope, because the fixed-value rules from Plan the rules don't apply to RUM.

For details, see Enrich RUM telemetry with primary Grail fields and tags.

The enrichment rules from the earlier steps don't reach Synthetic, so a monitor uses only the tags you set on it. Go to Synthetic, select the monitor, select Edit, and fill in the Primary Grail tags section, or set the primaryGrailTags field via the Synthetic API:

primary_tags.team   = checkout
primary_tags.app    = astroshop
primary_tags.stage  = prod
dt.security_context = astroshop-prod

For details, see Primary Grail tags for Synthetic.