Generate test telemetry

The telemetry generator produces synthetic logs, metrics, or traces — or replays a captured sample — and sends them through a real collector at a rate and volume you control. Use it to exercise a pipeline end to end, baseline throughput, or load-test a route, all without standing up a real source.

Every generated record is tagged so you can tell synthetic traffic apart from real telemetry and keep it out of production destinations.

How it works

The generator runs inside the agent co-located with a collector, and sends its output into that collector’s OTLP receiver — so generated traffic flows the real pipeline path: routes, processors, and destinations, exactly as production telemetry would.

Because it runs in the agent, the generator is available only on collectors that have a co-located agent connected — the same requirement as live capture. On a collector without one, the Generate test data action is disabled with a prompt to enroll an agent first.

Note

Every generated record carries the resource attribute linkmesh.synthetic=true plus a generator-session id. That tag is how you filter synthetic traffic in routes and exclude it from production destinations — see Keep synthetic data out of production.

Start a generator session

1. Open the collector’s detail page and click Generate test data (in the Actions panel).

2. Pick the signal — logs, metrics, or traces — and a mode: Template (synthesise records) or Replay (loop a captured sample).

3. Set the rate (events per second, and optionally a bytes-per-second ceiling) and the bounds (max events and max seconds). Bounds are mandatory — a session always stops on its own.

4. Click Start generating. A live view shows the events and bytes sent and the progress toward your bounds. Stop early whenever you want, or let it end on its bound.

Screenshot pendingcollectors/generate-panel

The Generate test data panel: signal and mode up top, template and rate/bounds below, with live counters while a session runs.

Template mode

Template mode synthesises records from a chosen shape:

• Logs — pick a built-in template: Syslog, JSON app-log, Nginx access, Apache access, or Plain text.
• Metrics — gauge series with a value pattern (constant, sine, step, or spike) and a bounded series count.
• Traces — small trace trees with a configurable spans-per-trace and an error-span percentage.

Tune the load with the events/s rate and the max events / max seconds bounds. An optional bytes/s ceiling caps throughput by volume as well — the tighter of the two limits applies.

Replay mode

Replay mode loops a captured sample as load, so you can drive real-shaped traffic through a pipeline:

1. Capture a sample from a live route and save it to the Sample Library.

2. In the generator panel, choose Replay and pick the sample.

3. Set the rate and bounds and start. The generator loops the sample’s records, rewriting each record’s timestamps to now so replayed data looks current while preserving the timing between records within the sample.

Replay currently supports log samples. There is a size cap on how large a sample can be for replay — if a sample is too large, capture a smaller one.

Note

Replayed records are re-tagged synthetic: the original resource identity is preserved under linkmesh.replay.original.* attributes, and linkmesh.synthetic=true is added, so replayed traffic can’t be mistaken for the original source.

Keep synthetic data out of production

Synthetic traffic flows the real pipeline path, so if a route points at a production destination, generated records will reach it. Two ways to prevent that:

• Route synthetic traffic to a debug destination. Send it to a throwaway/debug output while you test, not to a production destination.

• Exclude it with a route filter. On any route you don’t want synthetic data on, add a filter that drops records carrying the synthetic tag:

  resource.attributes["linkmesh.synthetic"] == true

  Use that as the drop condition to keep generated records out of the destination.

Load-test a pipeline

Use the generator to baseline and stress a pipeline’s throughput:

1. Start a logs session at a modest rate — say 100 events/s — with a generous duration bound.

2. Watch the pipeline canvas: the throughput overlays show records flowing through each node, and node saturation surfaces where a processor or destination starts to fall behind.

3. Step the rate up (200, 500, 1000 events/s) and watch where throughput plateaus or saturation climbs — that’s your bottleneck.

Caution

Load-testing drives real work through your collector and destinations. Keep bounds tight, start low and step up, and point synthetic traffic at a debug destination — never ramp load straight into production.

Safety and limits

• Bounds are mandatory. Every session has a max-events and max-duration bound; an unbounded session isn’t possible.
• Server caps apply on top of your bounds — the rate and bounds are capped server-side (up to roughly 10,000 events/s, 10 MB/s, and one hour). A request above a cap is rejected, not silently run.
• Sessions are audited — who started one, on which collector, at what rate and bounds.

Permissions

Starting and stopping generator sessions requires the generate:run permission. It’s separate from capture — being able to run captures does not grant the ability to generate load. Grant it to the roles you want to let load-test or produce test telemetry.