Dash0 Raises $110M Series B at $1B Valuation

Last updated: May 8, 2026

Drilldown: Filter Translation

How chart drilldown translates PromQL filters and series labels into the destination explorer's filter syntax.

When you drill down from a chart, Dash0 translates the chart's PromQL filters and the labels of the clicked series into the destination explorer's filter syntax. The translation runs as a two-step pipeline:

  1. Filter extraction — decide which matchers from the chart should land in the destination.
  2. Filter conversion — translate those matchers from PromQL syntax to OpenTelemetry attribute syntax.

Both steps are best-effort. When information can't be carried over reliably, drilldown drops it rather than guess. The destination filter set may end up looser than the chart, but it never misses records the chart included.

Step 1: Filter Extraction

The first step decides which matchers to apply in the destination. Drilldown combines two sources:

  • Labels carried by the returned timeseries. Each series in the chart carries the attributes the query grouped or split by — service.name, k8s.pod.name, http.response.status_code, and so on. These describe what the row actually represents, so they are the authoritative source.
  • Equality matchers in the chart's PromQL expression. Filters baked into the query itself — for example, service.namespace = "shop" — are extracted to fill in any dimension the returned series no longer carries (because of group by, label_replace, or other aggregation).

When both sources carry the same dimension, the series label wins — it describes what's actually in the row, while PromQL filters only bound what was queried.

Not every matcher in a PromQL expression can be safely applied. Complex queries that combine multiple sub-expressions with binary operators (or, and, unless, arithmetic between metrics) can produce filter sets that don't have a single coherent meaning for the destination signal. In those cases, drilldown applies the matchers it can extract confidently and drops the rest.

Step 2: Filter Conversion (PromQL → OpenTelemetry)

The second step translates each extracted matcher from PromQL syntax to the destination explorer's native attribute syntax.

PromQL labels and OpenTelemetry attributes live in different namespaces, and the reverse translation is not a simple character substitution. PromQL identifiers can't contain dots, so OTel attribute names like service.name are written as service_name in PromQL. Going back the other way isn't always reliable: multiple OTel attributes can collapse onto the same Prom label, labels added by PromQL functions like label_replace have no OTel origin, and queries can use custom labels with no known equivalent. When drilldown can't reliably convert a Prom label, it drops the label rather than guess.

For some signals, conversion also normalizes value casing — for example, span attributes such as otel.span.kind, otel.span.status.code, and dash0.operation.type are uppercased to match what the Spans Explorer expects.