Observing a k6 test

1. Why export? #

The summary is not enough.

Seeing over time #

Available in: ✓ OSS ✓ Enterprise ✓ Cloud

The end-of-test summary gives global averages and percentiles. To understand when latency breaks down and why, you need to see k6 metrics over time, next to the CPU, database connections and traces of the system under test.

2. To Prometheus #

The remote write output.

Configuration #

# Prometheus doit accepter le remote write
prometheus --config.file=prometheus.yml --web.enable-remote-write-receiver

K6_PROMETHEUS_RW_SERVER_URL=http://localhost:9090/api/v1/write \
K6_PROMETHEUS_RW_TREND_STATS="p(95),p(99),avg,max" \
k6 run -o experimental-prometheus-rw --tag testid=release-2.4 script.js

Good practice: With K6_PROMETHEUS_RW_TREND_AS_NATIVE_HISTOGRAM=true, durations are sent as native histograms: any percentile can then be computed in Grafana.

Good to know: The testid tag distinguishes runs: it lets you compare two tests in the same dashboard. Grafana publishes an official « k6 Prometheus » dashboard to import.

With OpenTelemetry #

k6 also has an OpenTelemetry output (-o opentelemetry) that sends its metrics over OTLP to a Collector or to Alloy, handy if your stack is already OTLP.

3. Correlating with the system under test #

Explaining the results.

Method #

1. Mark the test: testid tag and a Grafana annotation at the start and end.
2. Show on the same dashboard: k6 throughput and latency, service saturation (CPU, memory, connection pool), errors.
3. Find the moment latency breaks down and look for the resource saturated at that instant (USE method).
4. Open slow traces from that period (exemplars) and the service's CPU profile (Pyroscope).

import http from 'k6/http';
// Propager un en-tête de trace pour retrouver les requêtes du test dans Tempo
export default function () {
  http.get('http://api/produits', { headers: { 'X-Test-Id': __ENV.TEST_ID } });
}