Dynatrace now extracts histogram metrics directly from spans and logs during ingestion using OpenPipeline, eliminating the need to re-instrument services to get distribution data. Histogram metrics preserve full data distributions rather than collapsing them into a single average, enabling accurate percentile queries (p50, p90, p99), precise SLO measurement via a new percentRank() DQL function, and better anomaly detection through distribution-aware baselining. The extracted metrics use the exponential histogram format aligned with OpenTelemetry and Prometheus conventions, with dynamic bucket boundaries that require no upfront configuration. Metrics are stored in Grail and available for dashboards, DQL queries, and SLO definitions.
Table of contents
Why do averages hide important performance signals?How to extract histogram metrics from spans and logs at ingestHow do histogram metrics help with SLOs and reliability engineering?Get started with histogram metricsQuestions this post answers
How can I get percentile metrics like p99 latency without re-instrumenting my services in Dynatrace?
Dynatrace OpenPipeline can extract histogram metrics directly from spans and logs already being ingested, without changing SDKs, applications, or OpenTelemetry collectors. You configure a histogram metric extraction rule that converts span or log data into exponential histogram metrics at ingest time, which are then queryable with functions like timeseries percentile() instead of scanning raw telemetry on every query. Developers weighing observability pipeline changes can track platform updates like this on daily.dev.
What is the new percentRank() function in Dynatrace Query Language used for?
percentRank() is a Dynatrace Query Language aggregation function that returns the estimated fraction of observations below a given threshold, working in the opposite direction from a percentile calculation. Given a latency threshold like 500 ms, it answers what fraction of requests completed under that value, making it useful for defining SLOs based on latency distributions rather than simple averages. Teams building latency-based SLOs can follow DQL feature updates like this via daily.dev.
Why do average response time metrics hide performance problems?
An average blends fast and slow requests into one misleading number; for example, if 80% of requests complete in 10 ms while 20% take 2 seconds, the average comes out to 408 ms, representing neither group accurately. Once only the average is stored, the underlying distribution is lost, making it impossible to analyze percentiles, tail latency, or SLO compliance afterward. Anyone debugging misleading latency dashboards can find deeper observability explainers through daily.dev.