motel

motel /mōˈtel/ noun mock opentelemetry. A synthetic signal generator for testing and developing observability pipelines.

motel is a synthetic OpenTelemetry generator.

Describe your distributed system in YAML and motel generates realistic traces, metrics, and logs — no live services required.

Already using telemetrygen? See how motel compares.

Install

brew tap andrewh/tap
brew install motel

Or with Go:

go install github.com/andrewh/motel/cmd/motel@latest

Or download a binary from the releases page.

Quick start

# my-topology.yaml
version: 1

services:
  gateway:
    operations:
      GET /users:
        duration: 30ms +/- 10ms
        error_rate: 1%
        calls:
          - users.list
  users:
    operations:
      list:
        duration: 15ms +/- 5ms

traffic:
  rate: 10/s

# Validate the topology
motel validate my-topology.yaml

# Generate traces to stdout
motel run --stdout --duration 5s my-topology.yaml

# Send to an OTLP collector
motel run --endpoint localhost:4318 --duration 30s my-topology.yaml

What it does

motel reads a YAML topology file describing services, operations, call patterns, latency distributions, and error rates. It walks the topology tree once per trace, producing spans that look like they came from real instrumented services. Every span carries synth.service and synth.operation attributes, and all signals include a motel.version resource attribute, so synthetic traffic is never mistaken for real data.

Use cases:

• Test observability pipelines — feed realistic traces into collectors, backends, or dashboards without deploying services
• Load test — generate trace traffic at controlled rates with configurable patterns (uniform, diurnal, bursty, custom)
• Demo and prototype — show what your system's telemetry will look like before building it
• Import real traces — motel import infers a topology from existing trace data, so you can replay and modify production patterns

motel vs telemetrygen

telemetrygen is the OpenTelemetry Collector's built-in generator, and it's the right tool for checking that the pipe is connected: it emits identical spans at a configurable rate. motel exists for the questions telemetrygen can't answer — whether your pipeline behaves correctly when the telemetry looks like production.

	telemetrygen	motel
Trace shape	identical flat spans	arbitrary service topology, parallel/sequential calls
Latency	fixed span duration	per-operation distributions (30ms +/- 10ms)
Errors	one status code for every span	per-operation error rates
Failure modes	—	time-windowed scenarios, backpressure, circuit breakers, queue rejection
Traffic	constant rate	uniform, diurnal, bursty, custom patterns
Metrics & logs	generated independently	correlated — derived from the same topology as the traces
Semantic conventions	generic attributes	semconv domains generate standard attributes per operation
Replay production	—	motel import infers a topology from real trace data

Rule of thumb: use telemetrygen to smoke-test connectivity and soak raw throughput. Use motel when correctness depends on the content of the telemetry — tail sampling, OTTL transforms, alert thresholds, sampling integrity, dashboards, and demos.

Signals

By default motel emits traces. Use --signals to add metrics and logs:

motel run --stdout --signals traces,metrics,logs --slow-threshold 200ms topology.yaml

All three signal types are driven by the same topology.

Documentation

• Getting started tutorial
• CLI reference
• DSL reference — full topology schema
• Example topologies
• Follow-along Compose stack — collector with tail sampling + Jaeger, one docker compose up away
• Modelling your services
• How import infers a topology
• How motel uses OTel semantic conventions

Licence

Apache 2.0