Datadog Tagging Best Practices
Overview
This skill defines Datadog's official tagging best practices for unified service tagging across all telemetry (APM traces, logs, metrics).
The Three Core Tags (Required)
Datadog reserves three standard tags that automatically connect all telemetry:
| Tag |
Environment Variable |
Description |
Example Values |
env |
DD_ENV |
Deployment environment |
production, staging, development, local |
service |
DD_SERVICE |
Application/service name |
payment-api, user-service, ddtrace-agent-v3 |
version |
DD_VERSION |
Code version/release |
1.2.3, v2.0.0, 0.3.0 |
Additional Recommended Tags
| Tag |
Purpose |
Example Values |
team |
Ownership/cost allocation |
platform, backend, infra |
component |
Sub-service component |
api, worker, scheduler |
cluster |
Kubernetes cluster name |
tundra-dome, gastown, minim4-tundra |
namespace |
K8s namespace |
default, datadog, airflow |
Tag Naming Rules
- Lowercase only - Tags must be lowercase
- Start with letter - Tags must begin with a letter
- Alphanumeric + underscores - Use
a-z, 0-9, _, -, :, /, .
- Max 200 characters - Tag names limited to 200 chars
- Colons for namespacing - Use
: for hierarchical tags (e.g., team:backend)
- No spaces - Use underscores or hyphens instead
Implementation Patterns
Python Scripts (ddtrace)
#!/usr/bin/env python3
from __future__ import annotations
import os
# Datadog Unified Service Tagging
try:
from ddtrace import config, patch_all, tracer
# Core tags (required)
config.service = os.environ.get("DD_SERVICE", "script-name")
config.env = os.environ.get("DD_ENV", "development")
config.version = os.environ.get("DD_VERSION", "0.1.0")
# Additional tags
tracer.set_tags({
"team": "platform",
"component": "automation",
})
patch_all()
except ImportError:
pass
Environment Variables (Shell/CI)
export DD_ENV=production
export DD_SERVICE=my-service
export DD_VERSION=1.2.3
export DD_TAGS="team:backend,component:api,cluster:tundra-dome"
Kubernetes Labels
metadata:
labels:
tags.datadoghq.com/env: "production"
tags.datadoghq.com/service: "my-service"
tags.datadoghq.com/version: "1.2.3"
Service Naming Conventions
| Pattern |
Example |
Use Case |
{app}-{component} |
crew-api |
Microservices |
{domain}-{function} |
payment-processor |
Domain-driven |
{script-name} |
ddtrace-agent-v3 |
Standalone scripts |
{package-name} |
tundra-automation |
Python packages |
Anti-Patterns to Avoid
- Over-tagging - Each tag adds cost; keep tag cardinality low
- High-cardinality values - Avoid UUIDs, timestamps, user IDs as tag values
- Inconsistent naming - Use same tag names across all services
- Missing core tags - Always set
env, service, version
- Hardcoded values - Use environment variables for flexibility
Version Tag Strategies
| Strategy |
Format |
Example |
| Semantic versioning |
MAJOR.MINOR.PATCH |
1.2.3 |
| Git SHA (short) |
{sha} |
abc1234 |
| Date-based |
YYYYMMDD.N |
20260205.1 |
| Branch + SHA |
{branch}-{sha} |
main-abc1234 |
Cost Optimization
- Limit custom tags to essential ones (team, component, cluster)
- Use tag inheritance from infrastructure where possible
- Avoid creating new tags for each deployment
- Use
DD_TAGS for static tags shared across requests
References
1---2name: dd-tags3description: Datadog Tagging Best Practices4---5# Datadog Tagging Best Practices67## Overview89This skill defines Datadog's official tagging best practices for unified service tagging across all telemetry (APM traces, logs, metrics).1011## The Three Core Tags (Required)1213Datadog reserves three standard tags that automatically connect all telemetry:1415| Tag | Environment Variable | Description | Example Values |16|-----|---------------------|-------------|----------------|17| `env` | `DD_ENV` | Deployment environment | `production`, `staging`, `development`, `local` |18| `service` | `DD_SERVICE` | Application/service name | `payment-api`, `user-service`, `ddtrace-agent-v3` |19| `version` | `DD_VERSION` | Code version/release | `1.2.3`, `v2.0.0`, `0.3.0` |2021## Additional Recommended Tags2223| Tag | Purpose | Example Values |24|-----|---------|----------------|25| `team` | Ownership/cost allocation | `platform`, `backend`, `infra` |26| `component` | Sub-service component | `api`, `worker`, `scheduler` |27| `cluster` | Kubernetes cluster name | `tundra-dome`, `gastown`, `minim4-tundra` |28| `namespace` | K8s namespace | `default`, `datadog`, `airflow` |2930## Tag Naming Rules31321. **Lowercase only** - Tags must be lowercase332. **Start with letter** - Tags must begin with a letter343. **Alphanumeric + underscores** - Use `a-z`, `0-9`, `_`, `-`, `:`, `/`, `.`354. **Max 200 characters** - Tag names limited to 200 chars365. **Colons for namespacing** - Use `:` for hierarchical tags (e.g., `team:backend`)376. **No spaces** - Use underscores or hyphens instead3839## Implementation Patterns4041### Python Scripts (ddtrace)4243```python44#!/usr/bin/env python345from __future__ import annotations4647import os4849# Datadog Unified Service Tagging50try:51 from ddtrace import config, patch_all, tracer5253 # Core tags (required)54 config.service = os.environ.get("DD_SERVICE", "script-name")55 config.env = os.environ.get("DD_ENV", "development")56 config.version = os.environ.get("DD_VERSION", "0.1.0")5758 # Additional tags59 tracer.set_tags({60 "team": "platform",61 "component": "automation",62 })6364 patch_all()65except ImportError:66 pass67```6869### Environment Variables (Shell/CI)7071```bash72export DD_ENV=production73export DD_SERVICE=my-service74export DD_VERSION=1.2.375export DD_TAGS="team:backend,component:api,cluster:tundra-dome"76```7778### Kubernetes Labels7980```yaml81metadata:82 labels:83 tags.datadoghq.com/env: "production"84 tags.datadoghq.com/service: "my-service"85 tags.datadoghq.com/version: "1.2.3"86```8788## Service Naming Conventions8990| Pattern | Example | Use Case |91|---------|---------|----------|92| `{app}-{component}` | `crew-api` | Microservices |93| `{domain}-{function}` | `payment-processor` | Domain-driven |94| `{script-name}` | `ddtrace-agent-v3` | Standalone scripts |95| `{package-name}` | `tundra-automation` | Python packages |9697## Anti-Patterns to Avoid9899- **Over-tagging** - Each tag adds cost; keep tag cardinality low100- **High-cardinality values** - Avoid UUIDs, timestamps, user IDs as tag values101- **Inconsistent naming** - Use same tag names across all services102- **Missing core tags** - Always set `env`, `service`, `version`103- **Hardcoded values** - Use environment variables for flexibility104105## Version Tag Strategies106107| Strategy | Format | Example |108|----------|--------|---------|109| Semantic versioning | `MAJOR.MINOR.PATCH` | `1.2.3` |110| Git SHA (short) | `{sha}` | `abc1234` |111| Date-based | `YYYYMMDD.N` | `20260205.1` |112| Branch + SHA | `{branch}-{sha}` | `main-abc1234` |113114## Cost Optimization115116- Limit custom tags to essential ones (team, component, cluster)117- Use tag inheritance from infrastructure where possible118- Avoid creating new tags for each deployment119- Use `DD_TAGS` for static tags shared across requests120121## References122123- [Unified Service Tagging](https://docs.datadoghq.com/getting_started/tagging/unified_service_tagging/)124- [Tagging Best Practices](https://learn.datadoghq.com/courses/tagging-best-practices)125- [Assigning Tags](https://docs.datadoghq.com/getting_started/tagging/assigning_tags/)