Starting January 2026, we're making two changes to how OTLP metrics are processed:
We are introducing an opt-in setting for "advanced OTLP metric dimensions" (docs).
The upside 🙂 after enabling it, OTLP metrics will support extended dimension capabilities, including Primary Grail Fields, higher cardinality limits, faster queries, and relaxed requirements for dimension names (including uppercase, or special characters like slashes).
The downside 😥 after enabling this setting:
OTLP metrics will no longer be automatically enriched with `dt.entity.service`. If you use this dimension in SLOs, alerts, or dashboards, you'll need to update your queries.
Mixed-case dimension keys are no longer normalized to lowercase. Previously, Metrics Classic required dimension names to be lowercase, so they were normalized on ingest (e.g. from myCustomDimension to mycustomdimension). With the toggle on, dimensions are stored exactly as your instrumentation sends them. DQL is case-sensitive, so existing queries that reference the lowercased form will return no data until updated.
dt.entity.service filtersCurrent pattern:
timeseries sum(request_counter, rate: 1m),filter: { dt.entity.service == "SERVICE-4E5FC455D32B2912" }
New pattern:
Since dt.entity.service was calculated from SDv2 service detection rules, you can filter using the same underlying attributes. For Kubernetes workloads:
timeseries sum(request_counter, rate: 1m), filter: {
k8s.workload.name == "productcatalogservice"
and k8s.namespace.name == "astroshop"
and k8s.cluster.uid == "28d34e2d-2420-4ca7-9d3a-4fc69cac077b"
}
For non-Kubernetes deployments, use service.name:
timeseries sum(request_counter, rate: 1m),
filter: { service.name == "productcatalogservice" }
These attributes must already be present as resource attributes on your OTLP metrics. Dynatrace does not automatically add them. OpenTelemetry instrumentation must send them. If you've customized your SDv2 detection rules, use the same custom attributes in your queries.
If your instrumentation emits camelCase or PascalCase dimension keys, update queries to match the original casing.
Before (Metrics Classic forced lowercase):
timeseries sum(http_requests), filter: { httpmethod == "GET" and customertier == "gold" }
After (toggle on, original casing preserved):
timeseries sum(http_requests), filter: { httpMethod == "GET" and customerTier == "gold" }
Audit notebooks, dashboards, SLOs, and alerts for any dimension keys that your instrumentation sends in mixed case. If you'd rather keep lowercase queries, normalize at the source: in your instrumentation, in an OpenTelemetry Collector processing pipeline, or via an OpenPipeline rule.
Once enabled, OTLP metrics support:
Primary Grail Fields as dimensions: Use fields like k8s.namespace.name, aws.account.id, azure.subscription, gcp.project.id for filtering, grouping, and correlation.
Higher cardinality limits: Significantly increased limits compared to the previous protocol.
Faster query performance: Optimized for Grail.
Special characters in dimensions: Slashes and other characters now supported.
Original dimension casing preserved: Mixed-case keys (e.g., myCustomDimension) are stored as sent, instead of being force-lowercased to match Metrics Classic rules. See migration note above.
These dimensions enable downstream capabilities like pipeline routing, bucket assignment, security context, cost allocation, and segment-based alerting, provided your instrumentation sends the relevant resource attributes.
aws.account.id
aws.region
azure.location
azure.resource.group
azure.subscription
gcp.project.id
gcp.region
k8s.cluster.name
k8s.namespace.name
dt.host_group.id
February 2026: Opt-in available
A toggle appears in Settings: Enable advanced OTLP metric dimensions
Enabling the toggle removes dt.entity.service from OTLP metrics
Enabling the toggle preserves original dimension key casing (no more forced lowercase)
Test in lower environments before enabling in production
Ongoing rollout
New tenants get the toggle enabled by default
Existing tenants get it enabled when they opt into Phase 3, or at any time via the toggle
No forced migration for existing tenants; you stay on the previous behavior until you opt in
Update your queries, SLOs, alerts, and dashboards before enabling
If you have questions or need assistance migrating your queries, contact your Dynatrace support team or reply to this post.