Dummy Prometheus Metrics Generator
Generates realistic fake Prometheus-format metrics output for monitoring and testing
About this 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
- 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.