If you’re building or validating an OpenTelemetry (OTel) Collector pipeline, there’s one thing you’ll need before anything else: telemetry. But getting access to real-world traces, metrics, and logs isn’t always easy — especially when you’re in development, testing transformations, or troubleshooting data routing. Last week we looked at a telemetry generation tool called otelgen – this week we’re looking at another called telemetrygen – this one packaged in the OpenTelemetry Contrib Collector itself (or OTel collector contrib)
telemetrygen
— is a simple tool purpose-built for generating OpenTelemetry-compatible telemetry data on demand.
In this post, we’ll show you how to use telemetrygen to:
- Quickly generate traces, metrics and logs
- Validate OpenTelemetry Collector configurations
- Simulate production-like telemetry for development and testing
🔧 What Is telemetrygen?
telemetrygen is a lightweight telemetry generator included in the OpenTelemetry Collector Contrib repo (OTel collector contributor). It emits trace, metric and log data using the OpenTelemetry Protocol (OTLP) — which makes it perfect for testing OTel Collector pipelines.
You can:
- Emit traces with custom service names, spans, and latency
- Generate metrics with configurable values and intervals
- Send telemetry to any OTLP receiver (HTTP or gRPC)
📦 Installing telemetrygen
You can run telemetrygen directly from Docker (in this case pointing at an OTel collector running locally on our Mac) — no Go or local build required:
docker run --rm ghcr.io/open-telemetry/opentelemetry-collector-contrib/telemetrygen:latest \
traces \
--otlp-endpoint=host.docker.internal:4317 \
--otlp-insecure
🔁 If you’re using Linux (vs Mac), replace
host.docker.internal
with localhost or your host IP.
Or we can install locally with Go if we prefer:
go install github.com/open-telemetry/opentelemetry-collector-contrib/cmd/telemetrygen@latest
🚀 Example: Sending Test Traces to the OpenTelemetry Collector with telemetrygen
Let’s assume you’ve got the OpenTelemetry Collector running locally (on our Mac again) with an OTLP receiver on port 4317
. You can send sample traces like this using Docker:
docker run --rm ghcr.io/open-telemetry/opentelemetry-collector-contrib/telemetrygen:latest \
traces \
--otlp-endpoint=host.docker.internal:4317 \
--otlp-insecure \
--duration=30s \
--rate=5 \
--service="test-service"
This generates:
- 5 spans per second
- A duration of 30 seconds
- Spans tagged to the service
test-service
This is a great way to simulate what actual application telemetry would look like in a live environment — without having to instrument a real app. Replace traces
with metrics
or logs
to try different telemetry types, and use the help option to explore all parameters like
docker run --rm ghcr.io/open-telemetry/opentelemetry-collector-contrib/telemetrygen:latest metrics -h
🧪 Validating an OTel Collector Pipeline
Using telemetrygen, you can quickly verify:
- That your OTLP receiver is working
- That your processors (e.g., filter, transform, dedupe) behave as expected (the tap processor can be handy here too….)
- That your exporters (e.g., debug, OTLP, or third-party destinations like Datadog or Prometheus) are receiving the data
Example Docker Compose to test it where otel-config
is the collector configuration you’ve constructued locally to test (see here for an example sample collector config):
services:
otel-collector:
image: otel/opentelemetry-collector-contrib:latest
command: ["--config=/etc/otel/config.yaml"]
ports:
- "4317:4317"
volumes:
- ./otel-config.yaml:/etc/otel/config.yaml
telemetrygen:
image: ghcr.io/open-telemetry/opentelemetry-collector-contrib/telemetrygen:latest
depends_on:
- collector
command:
[
"traces",
"--otlp-endpoint=host.docker.internal:4317",
"--otlp-insecure",
"--duration=30s",
"--rate=10"
]
This will spin up a self-contained telemetry test harness.
🔍 Example Use Cases
- 🔁 Testing processors like
transform
,filter
, ortail_sampling
- 📊 Validating metric pipelines before rolling out Prometheus scraping
- 🔐 Testing OTLP receivers with TLS, authentication, or custom headers
- 💸 Simulating high volume traffic to evaluate collector performance or cost impact
🌟 Tips for Effective Use
- Use
--telemetry-attributes
to add test attributes for filtering or routing (e.g.--telemetry-attributes='env="dev",region="us-central",feature_flag="on"'
) - Combine with
debug
orfile
exporters to verify output structure - Pair with a backend like Grafana, Jaeger, or Datadog to visualize trace flow
✅ Conclusion
If you’re working with the OpenTelemetry Collector, telemetrygen is one of the fastest ways to validate your configuration and generate sample telemetry on demand. Whether you’re testing a brand new pipeline or debugging production behavior in a staging environment, it gives you the flexibility to move fast — without waiting on real services.
Want help optimizing your OTel pipeline or replacing the Datadog agent with the OpenTelemetry Collector?
👉 Book a free telemetry strategy session with ControlTheory
press@controltheory.com