Dev
Dummy OpenTelemetry Trace Generator
Validating an OpenTelemetry pipeline or a distributed tracing UI requires realistic spans, but instrumenting a real service just to get test data is overkill. This generator produces mock spans in OTLP-compatible JSON, each with a shared trace ID, a unique span ID, a parent span ID (null for the root span), an operation name drawn from realistic categories like http.request, db.query, cache.get, and queue.publish, a start timestamp, a duration, and a status of OK or ERROR. HTTP spans include http.method, http.status_code, and http.url attributes; database spans include db.system, db.statement, and db.name. The service name input sets the serviceName field on every span, matching whatever name your Jaeger or Grafana Tempo instance uses for that service. The span count input controls how many spans are in the batch, from 1 to 20. Spans are sequentially timestamped so they form a plausible timeline rather than all starting at the same moment. To send the output to a real collector, POST each span JSON to your OTLP HTTP endpoint on port 4318, or pipe the batch through otel-cli. For snapshot tests, commit a single generated output as a static fixture and avoid regenerating each run, since trace IDs are random.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Set the Number of Spans to match the depth of the trace tree you want to simulate (5-15 is realistic for a single request).
- Enter your target service name exactly as it appears in your observability platform to ensure dashboard filters align.
- Click Generate to produce a set of mock spans with trace IDs, parent-child links, and varied operation types.
- Copy the output and paste it into your collector endpoint, test fixture file, or SDK integration under test.
- Regenerate as many times as needed — each run produces new unique trace and span IDs for isolated test cases.
Use Cases
- •Stress-testing an OpenTelemetry Collector pipeline's sampling and export rules before production rollout
- •Populating a Jaeger or Grafana Tempo UI with a realistic multi-span checkout-service trace for a demo
- •Writing Jest unit tests for a custom OTLP span processor or trace exporter
- •Reproducing high-latency database spans to validate P99 alerting thresholds in Grafana
- •Generating fixture payloads for Postman collections that test a trace ingestion REST endpoint
Tips
- →Generate two batches with different service names, then import both to verify your tracing backend renders a multi-service dependency graph correctly.
- →Keep spanCount below 20 when testing UI rendering; very deep traces (50+ spans) are better suited for storage and ingestion benchmarks.
- →Name your service after a real planned microservice so any dashboard templates you build during testing are production-ready from the start.
- →Look for spans with 4xx and 5xx status codes in the output — use those specifically to validate that your alerting rules fire on error traces.
- →Pair the output with otel-cli to push spans directly to a local Collector without writing any code: otel-cli exec accepts OTLP JSON on stdin.
- →If you need reproducible IDs for snapshot tests, copy a single generated output and commit it as a fixture rather than regenerating each test run.
FAQ
how do I send generated OpenTelemetry spans to a real collector
POST the JSON payload to your Collector's OTLP HTTP endpoint — default port 4318 — with Content-Type: application/json. Alternatively, pipe the output through otel-cli or write a short script using any OpenTelemetry SDK's SpanExporter to forward spans directly.
are these mock spans compatible with Jaeger or Zipkin
The spans follow OpenTelemetry semantic conventions and OTLP-style structure, so they work with any OTLP-compatible backend. For Zipkin's native JSON or Jaeger's Thrift format, run them through the OpenTelemetry Collector's transform processor first.
how many spans should I generate for realistic trace testing
A typical microservice request produces 5–15 spans: one root HTTP span plus child DB, cache, or queue calls. Use 5–15 to mimic a single trace, or go up to 20 (the maximum) to load-test a trace storage backend or simulate a deep call chain.
does the generator produce a proper parent-child span hierarchy
The first span in the batch has a null parentSpanId, making it the root. Every subsequent span has a random parentSpanId value. The spans are not automatically nested into a strict tree — they share a traceId, but the parent relationships are illustrative rather than forming a verified DAG.
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.