Skip to main content
Back to Dev generators

Dev

Dummy OpenTelemetry Trace Generator

Used by developers, writers, and creators worldwide.

The dummy OpenTelemetry trace generator produces realistic mock spans you can feed directly into observability pipelines, collector configs, or demo dashboards — no live instrumented service required. Each span includes a trace ID, span ID, parent-child relationships, timestamps, durations, HTTP status codes, and attributes for database, cache, queue, and HTTP operations. Set the service name to match your actual deployment (say, checkout-service or payment-service) and choose a span count to simulate anything from a single RPC call to a deep multi-hop trace tree. Teams use this to validate Jaeger and Zipkin integrations, stress-test OpenTelemetry Collector pipelines, and onboard engineers to distributed tracing concepts with concrete, readable examples.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  1. 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).
  2. Enter your target service name exactly as it appears in your observability platform to ensure dashboard filters align.
  3. Click Generate to produce a set of mock spans with trace IDs, parent-child links, and varied operation types.
  4. Copy the output and paste it into your collector endpoint, test fixture file, or SDK integration under test.
  5. 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 50–100 to load-test a trace storage backend or simulate batch imports.