Tagging Best Practices

Quick Answer: Use key:value tags consistently. Datadog recommends unified service tagging with env, service, and version. Put dimensions in tags, not metric names. Avoid high-cardinality tags like request_id that explode timeseries count and cost.

Tags are the glue across every Datadog product surface — Metrics Explorer, dashboards, Host Map, monitors, log search, and APM. The Data Collection domain tests tagging as a design discipline, not a cosmetic label. Poor tagging makes dashboards unusable; good tagging lets one metric answer dozens of questions through filters and grouping.

Tag Format and Syntax

Datadog's standard tag format is:

key:value

Examples: env:prod, service:payment-api, region:us-east-1, team:platform.

In datadog.yaml, global tags use YAML list syntax:

tags:
  - 'env:prod'
  - 'service:web'

Invalid list syntax (missing quotes, arrow notation, comma-separated strings without brackets) breaks YAML parsing — a Computer Fundamentals crossover topic that appears when editing Agent configs.

Unified Service Tagging

Datadog recommends three reserved tags for cross-product correlation:

When the same three tags appear on metrics, traces, and logs, Datadog can correlate signals in the UI — pivot from a latency spike in APM to matching error logs and infrastructure metrics without guessing naming conventions.

On the Exam: Unified service tagging is env + service + version, not cluster/node/pod (Kubernetes infrastructure tags) and not host/ip/subnet (network identity tags). Know the official trio.

Setting Unified Tags

Sources include:

• datadog.yaml global tags list on the Agent
• Container orchestrator labels (converted by Autodiscovery)
• APM tracer DD_ENV, DD_SERVICE, DD_VERSION environment variables
• DogStatsD tags parameter on each metric call

Align all sources to the same values per deployment; conflicting service tags between traces and metrics break correlation.

Tags vs Metric Names

A common anti-pattern embeds dimensions in metric names:

Why tags win:

1. One query, many slices — avg:orders.count{*} grouped by env instead of maintaining parallel metric names.
2. Consistent monitors — one monitor template scoped by tag rather than duplicating per environment.
3. Cross-signal reuse — the same env:prod tag filters logs, traces, and metrics.

Cardinality: The Cost and Query Trap

Cardinality is the number of unique tag-value combinations on a metric. Each combination creates a distinct timeseries. Low-cardinality tags (env, region, service) have bounded values. High-cardinality tags grow without limit.

Common Trap: Tagging every request with request_id does not help aggregate dashboards — it creates millions of single-point series, increases custom metric billing, and slows queries. Use request IDs in logs and traces, not as metric tags.

Host Tags vs Custom Metric Tags

The Agent automatically applies host tags: cloud provider metadata, availability-zone, instance-type, and hostname. Integration checks add integration-specific tags (db:postgres, nginx_host).

DogStatsD submissions inherit host tags plus any tags passed in the metric call. You do not need to repeat host manually — Datadog associates the series with the reporting host.

Tag-Based Filtering and Grouping Preview

Tags power query operations tested across Data Collection and Visualization domains:

Design tags so the keys you group by in monitors (host, service, availability-zone) exist at collection time.

Worked Scenario: Tag Refactor

A team emits checkout.latency.prod, checkout.latency.staging, and checkout.latency.dev as separate metrics. Their monitor count tripled and dashboards drifted.

Refactor plan:

1. Consolidate to single metric checkout.latency.
2. Add env:prod|staging|dev tag at emission (DogStatsD or tracer).
3. Add unified tags service:checkout and version from CI.
4. Rewrite dashboards to avg:checkout.latency{*} by {env}.
5. Replace three monitors with one multi-alert monitor grouped by env.

This is exactly the design thinking Fundamentals rewards — fewer metric names, richer tag dimensions, lower operational burden.

Reserved vs Custom Tag Keys

Beyond unified service tags, Datadog recognizes common infrastructure keys (availability-zone, kube_deployment, image_name) from cloud and orchestrator metadata. You may add custom keys (team, cost_center, tier) as long as they stay low-cardinality. Document a tagging policy so new services do not invent synonyms (app vs service) that break cross-team dashboards.

Inherited Tags on DogStatsD Metrics

When application code emits statsd.gauge("cache.size", value), the resulting series inherits host tags from the Agent plus any inline tags in the call. You do not need a separate metric per host — hostname association is automatic, which simplifies fleet-wide queries like avg:cache.size{env:prod} by {host}.