Migrate Management Zones → Segments
Management Zones → Three New Concepts
Management zones served multiple purposes in Gen2. Gen3 splits them into three specialized concepts, each handling one responsibility:
MZ Responsibility Gen3 Replacement What It Does
───────────────────────────── ─────────────────────── ──────────────────────────────
Organize data by retention Data Partitioning Grail buckets with per-bucket retention
Control who sees what data Data Access (IAM/ABAC) Policies with dt.security_context
Filter data in dashboards/UI Data Segmentation Segments — DQL filter expressions
💡 This is the key insight: management zones tried to do all three at once. Gen3 separates them so each can scale independently.
Segments: Query-Time Filtering
Management Zones (Gen2) Segments (Gen3)
────────────────────────────────────── ──────────────────────────────────────
Entity-based rules DQL filter expressions
Pre-computed (performance overhead) Query-time (no pre-computation)
Environment-level Account-level, reusable
Applied globally Applied per app/dashboard/notebook
Limited to entity attributes Filter on ANY data attribute
🛠 Try it: Ctrl+K → "Segments" → Create new → Name it "Production" → Add filter: matchesValue(tags, "env:production") → Save. Now apply it to any dashboard.
OAuth Replaces API Tokens (for many use cases)
API Tokens (Gen2) OAuth Clients (Gen3)
────────────────────────────────────── ──────────────────────────────────────
Environment-level Account-level
Never expire (unless set) Auto-expire in 300 seconds
Broad scopes Fine-grained scopes
Stored in environment Managed in Account Management portal
One token = one set of permissions Client credentials + scopes per request
💡 OAuth is required for Gen3 resources: dashboards (Document API), workflows, platform SLOs, and anomaly detectors. API tokens still work for classic Settings API and Extensions.
Creating Segments
// Segment filter examples:
// By tag
matchesValue(tags, "env:production")
// By host group
matchesValue(dt.entity.host.hostGroup, "web-servers")
// By entity name pattern
matchesPhrase(entity.name, "payment")
// Combine multiple conditions
matchesValue(tags, "env:production") AND matchesPhrase(entity.name, "api")
⚠️ Segments are account-level resources. Unlike management zones, they're shared across environments. Plan your naming convention carefully.
Host Tag Propagation (Key Migration Step)
For segments to work, your data needs tags. The official Dynatrace upgrade guide recommends setting tags at the source via OneAgent:
// Set host tags via OneAgent CLI
oneagentctl --set-host-tag=env=production
oneagentctl --set-host-tag=team=payments
oneagentctl --set-host-tag=app=checkout
// These tags appear on EVERY signal from that host in Grail
⚠️ Three special tag keys propagate to derived data (service metrics, Davis problems): dt.security_context, dt.cost.costcenter, and dt.cost.product. Regular tags only propagate to raw signals (logs, spans, events).
Cost Allocation Tags
For chargeback and cost allocation, use the built-in cost tags:
Tag Key Purpose Example
─────────────────────── ────────────────────────────── ──────────────────
dt.cost.costcenter Chargeback to cost center dt.cost.costcenter=CC-1234
dt.cost.product Chargeback to product/service dt.cost.product=checkout-api
dt.security_context ABAC data access filtering dt.security_context=team-payments
💡 Set these tags on hosts via OneAgent, and they'll flow through to all observability data. Then use ABAC policies with WHERE storage:dt.security_context MATCH ("team-payments") to restrict data access per team.