Dev
Dummy Prometheus Metrics Generator
Building Grafana dashboards, writing Alertmanager rules, or testing a custom Prometheus exporter all require a scrape target that returns valid exposition format. Standing up a real service for that purpose takes time you do not have. This generator produces valid Prometheus text exposition output — with correct # HELP and # TYPE declarations, counter, gauge, histogram, and summary blocks — that you can serve immediately from a local HTTP server. The Service Name field namespaces every metric: enter api_gateway and every line is prefixed api_gateway_http_requests_total, api_gateway_process_cpu_seconds_total, and so on. The Metric Types selector controls which sections appear. HTTP + system generates request counters with method, endpoint, and status label cardinality; a request duration histogram with all eleven standard _bucket boundaries plus _sum and _count; and system-level CPU, memory, and goroutine gauges. HTTP only omits the system metrics. Database only switches to a query duration summary with 0.5, 0.9, and 0.99 quantiles plus a connection pool gauge. System only generates just the CPU, memory, and goroutine metrics. The output follows the official Prometheus exposition format spec. Save it to a file, serve it with python3 -m http.server 9100, and point a local Prometheus instance at it to get a real scrape cycle running in under two minutes.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Enter your service name in the Service Name field, matching the name used in your Prometheus scrape config or app labels.
- Select the metric type category from the Metric Types dropdown — choose HTTP + system for a broad mix or a narrower option if you only need specific signals.
- Click the generate button to produce a complete block of Prometheus exposition format output in the results panel.
- Copy the output and paste it into a file, a mock server response, or directly into a test fixture used by your integration tests.
- Adjust numeric values in the copied text manually to simulate specific conditions like high error rates or latency spikes before scraping.
Use Cases
- •Serving fake /metrics from a Python HTTP server so Prometheus scrapes it during CI integration tests
- •Building Grafana dashboard panels with histogram bucket data before the real service is deployed
- •Triggering Alertmanager threshold rules during development by tweaking counter values above rate() conditions
- •Validating custom relabeling rules in a Prometheus scrape config against realistic label cardinality
- •Onboarding engineers to Prometheus by showing concrete _bucket, _count, and _sum line relationships
Tips
- →Serve the output with `npx serve` or Python's http.server and point a local Prometheus instance at it to get a real scrape cycle running in under two minutes.
- →When testing histogram-based alerts, manually edit the _bucket values so higher le buckets accumulate counts gradually — flat buckets across all le values look unrealistic to PromQL rate() calculations.
- →Use a service name like `payment_service` rather than a generic word; namespaced metric names like payment_service_http_requests_total make Grafana variable templating work without regex edits.
- →Paste the same output into two scrape targets with different instance labels to simulate a multi-replica service and test Grafana panels that aggregate with sum() by (job).
- →If you're building recording rules, generate metrics with the exact names your rules reference, then verify the rule output using promtool check rules before touching a live cluster.
- →For Alertmanager end-to-end tests, combine this generator with a webhook receiver like alertmanager-webhook-logger to confirm the full pipeline from scrape to notification fires correctly.
FAQ
how do I serve this output as a real /metrics endpoint locally
Save the generated text to a file named metrics.txt, then run python3 -m http.server 9100 in the same directory. Add a scrape job in your Prometheus config pointing to localhost:9100/metrics.txt and it will ingest the fake data on the next scrape interval.
is the output valid enough for Prometheus client libraries to parse
Yes — the output follows the official Prometheus exposition format spec, so compliant parsers including Go's text_string_to_metric_families and the Python client's equivalent should read it without errors. If you see a parse failure, confirm your parser handles multi-line histogram and summary blocks correctly.
what metric types does this generator produce
The HTTP + system preset produces counters (http_requests_total), a histogram (http_request_duration_seconds with eleven _bucket lines plus _sum and _count), and gauges (process_cpu_seconds_total, process_resident_memory_bytes, go_goroutines). Database only adds a summary (db_query_duration_seconds with 0.5, 0.9, 0.99 quantiles) and a connection pool gauge. System only generates just the CPU, memory, and goroutine gauges.
what is the difference between a counter and a gauge metric
A counter only ever increases (or resets to zero on restart) — think total requests served — and you typically apply rate() to it in PromQL. A gauge goes up and down to represent a current value, like memory in use or active connections. The generated output includes both types with correct # TYPE lines so your dashboards and alert expressions can be tested against each kind.
You might also like
Popular tools from other categories that share themes with this one.
Try these next
More free tools from other corners of the catalog, picked by shared themes.