Skip to main content
To migrate your PromQL queries to Metrics Processing Language (MPL), choose one of the following options:
  • Manually translate your PromQL queries to MPL. This page explains the differences between MPL and PromQL and provides examples of how to migrate your queries.
  • Use the Query metrics skill to translate your PromQL queries to MPL.

Differences between MPL and PromQL

While MPL and PromQL are both designed for querying metrics data, they differ in fundamental ways that impact how queries are written and interpreted. This section outlines the key differences to help you adapt PromQL workflows when migrating to Axiom.

Richer type system

Prometheus treats all label values as strings, which often leads users to rely heavily on regular expressions for filtering. MPL, by contrast, supports a broader and more expressive type system, including native types like numbers, booleans, and timestamps. This means you can write cleaner, type-aware queries and avoid the pitfalls of string-only comparisons. For OpenTelemetry (OTel) data, this difference means that MPL preserves source types, enabling more accurate and efficient filtering and aggregation.

Labels versus fields

PromQL is optimized for a sparse label space and performs poorly with high-cardinality label sets. This design limits how many dimensions can be encoded as labels. MPL doesn’t impose the same restrictions. It encourages richer, high-cardinality data ingestion, allowing you to store and query more attributes per event without performance degradation. Additionally, PromQL users often use enrichment queries to simulate dimensional joins and join label values from one series into another. MPL doesn’t currently support this pattern because it diverges from OpenTelemetry semantics, which emphasize event-based modeling over metric enrichment.

Histogram behavior

Histogram support differs significantly. In PromQL, histogram queries typically yield one time series per bucket or a single quantile series depending on the function. MPL allows histogram operations that can output multiple series in a single query, providing greater flexibility for analyzing distributions or rendering percentile summaries directly.

Regular expression syntax

In PromQL, regular expressions are written as string literals using the =~ operator. This requires escaping special characters using double quotes and backslashes, which can be error-prone. MPL treats regular expressions as a first-class type. Use the == and != operators with a regex literal prefixed by #/. There is no =~ operator in MPL.
// PromQL
service=~"checkout|payment"

// MPL equivalent
| where service == #/checkout|payment/
Regex is a native type in MPL. Denote regex using #/ and / instead of quotation marks (' or ").In regex, escape slash (/), but don’t escape quotation marks (' or ").

Examples

Average over time

Calculate the fraction of time JVM CPU utilization across checkout and payment services stays below 80% over a 7-day window.
avg_over_time(
   (
      max by (service) (
          jvm_cpu_recent_utilization_ratio{
              service=~"checkout|payment"
          }
       ) < bool 0.8
   )[7d:]
)

Multiply each value by 100

Convert CPU utilization from a ratio (0–1) to a percentage (0–100).
process_cpu_utilization_ratio{} * 100

Calculate average error rate

Calculate the average error rate per 5-minute windows for HTTP server requests.
sum(rate(http_server_request_duration_seconds_count{status_code=~"5.."}[5m]))
/
sum(rate(http_server_request_duration_seconds_count{}[5m]))

Calculate rate

Calculate the rate of HTTP requests by method, route, and status code.
sum by (method, route, status_code) (
      rate(
          http_server_request_duration_seconds_count{
              status_code=~"[123].."
          }[5m]
      )
  )