Prometheus Query Builder (PromQL Playground)
Learn Prometheus Query Language (PromQL) with an interactive playground. Master label filtering, rate calculations, aggregations, and histogram quantiles with real-time query execution.
Category: Observability
Topics covered: prometheus, promql, observability, sre, metrics, monitoring
// simulator
Prometheus Query Builder (PromQL Playground)
Learn Prometheus Query Language (PromQL) with an interactive playground. Master label filtering, rate calculations, aggregations, and histogram quantiles with real-time query execution.
Missions
Goal: Show only the POST requests. Add a label filter: {method="POST"}.
Ctrl or Cmd + Enter runs the query.
Examples
Run a query to see its result here.
Understanding Prometheus & PromQL
Core concepts
- Time Series: A stream of timestamped values identified by a metric name and labels (key-value pairs).
- Instant Vector: A set of time series with one sample per series at a single point in time.
- Range Vector: A set of time series with multiple samples over a time range (e.g., [5m]).
- Scalar: A simple numeric floating point value.
Common functions
- rate(): Calculate per-second rate over a time range (for counters).
- irate(): Instant rate based on last two samples (more responsive).
- sum/avg/max/min: Aggregation operators across multiple series.
- histogram_quantile(): Calculate percentiles from histogram buckets.
Key concepts
- Counters: Monotonically increasing values (use rate() or increase()).
- Gauges: Values that can go up and down (use directly).
- Histograms: Observations bucketed by value (use histogram_quantile()).
- Summaries: Pre-calculated quantiles (use directly, no histogram_quantile()).
Label matching
=Exact match:method="GET"!=Negative match:status!="500"=~Regex match:path=~"/api/.*"!~Negative regex:job!~"dev-.*"
Overview
PromQL is the query language of Prometheus, and most of it comes down to selecting a time series, turning counters into rates and aggregating by labels. This playground teaches that in a guided sequence against sample HTTP request metrics. You start by selecting every series of a request counter, then filter it with label matchers to keep only GET requests, then narrow further to successful GET requests. Next you use rate() to turn an ever-growing counter into requests per second, sum() to add the series together, and sum by method to break the total down by HTTP method. The last step builds a real-world error rate: the rate of 5xx responses divided by the rate of all responses, expressed as a percentage, which is the query behind many alerts and SLOs. Each step shows the query and its result, so you can see what each function does to the data. The explanation below covers counters, gauges, histograms, label matching and the common functions you will meet in dashboards.
Try this
- Run the first query to see every request series, then add a label matcher to keep only GET requests.
- Use the requests per second step to see how rate() turns a counter into a per-second value.
- Build the error rate percentage query and compare it with the total requests per second.
Frequently asked questions
- Why use rate() on a Prometheus counter?
- A counter only goes up, so its raw value says little. rate() computes the per-second increase over a time window, handles counter resets and gives you a usable throughput number.
- What is the difference between rate() and irate()?
- rate() averages the increase across the whole range, which suits alerts and graphs. irate() uses only the last two samples, so it reacts faster but is noisier.
- How do I calculate an error rate in PromQL?
- Divide the rate of error responses by the rate of all responses, for example sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])), and multiply by 100 for a percentage.
Try next
// simulator
Log Aggregation Pipeline Simulator
Follow production logs from applications through collection, parsing, filtering, buffering, sharded indexing, and search. Trigger traffic spikes, parser failures, and slow indexing to see where backpressure builds and logs can be lost.
// simulator
Idempotency and Retry Lab
Lose payment responses, replay idempotent requests, compare backoff with full jitter during an outage, and move exhausted jobs to a dead-letter queue.
// simulator
GraphQL N+1 and DataLoader Lab
Trace nested GraphQL resolvers, count N+1 SQL queries, batch users and comments with DataLoader, and discover why a loader cache must stay inside one request.