Reading throughput on the canvas
The topology canvas isn’t just a wiring diagram — when a collector is reporting self-telemetry, every element carries a live throughput overlay: a small sparkline (recent trend), the current rate, and — where it matters — a queue fill bar and an error flag. This page explains how to read them.
Toggle the overlays with the Throughput switch in the canvas toolbar. With it off, you get the plain wiring graph.
Units: events per second — and bytes at the edges
Section titled “Units: events per second — and bytes at the edges”By default every number on the canvas is events per second — log records, metric data points, or spans. The OpenTelemetry collector reports its internal throughput as item counts, so events/second is what LinkMesh can show accurately from the metrics the collector already emits, with no extra instrumentation. It’s also the honest default axis for LinkMesh, which isn’t priced per gigabyte.
Bytes, measured — not guessed. Turn on detailed telemetry for a collector (a per-collector toggle on its detail page) and its network-edge overlays — the edges to destinations and to other collectors — gain a measured bytes/second, taken from the collector’s transport-size histograms rather than estimated from an average event size. It’s opt-in per collector because detailed telemetry multiplies the collector’s self-metric series (roughly tenfold), so you enable it on the collectors where byte-level egress accounting actually matters. Node-internal counts stay events/second — bytes only exist where data crosses the wire.
The overlay matrix
Section titled “The overlay matrix”Each kind of canvas element shows throughput for a specific point in the pipeline. Read it as “what flows, and which direction”:
| Element | What the sparkline shows | Direction |
|---|---|---|
| Source row (expanded collector card) | that source’s own events ingested per second; — when the collector reports nothing for it | in |
| Collector node | two lines — total received (the sum of its sources) vs total sent across all its exporters | in & out |
| Route edge | offered vs matched — how many events reached the route, and how many it kept. The gap is what the route filtered out | in (offered) / out (matched) |
| Collector → Destination edge | events sent to that destination per second | out |
| Collector → Collector edge | two lines — events forwarded by the sender vs events received by the peer | out & in |
| Destination node | events sent per second, plus a queue fill bar and an error flag when the exporter is struggling | out |
| Processor step (expanded route) | each step’s in → out, with the drop % that step removes | in & out |
Sources and collectors
Section titled “Sources and collectors”Sources are rows inside their collector’s card, not nodes of their own. Expand the card and each source row shows how fast events are coming in through that source. — means the collector reports nothing for that source: it was just activated, nothing has arrived, or its receiver does not emit the standard counters. A measured zero shows as a number, not a dash.
A collector node shows two lines: everything it receives versus everything it sends. When in and out track each other, the collector is passing traffic through cleanly. A persistent gap means events are being dropped or buffered somewhere between ingest and export — open the collector to see which route or processor is responsible.
Route edges — offered vs matched
Section titled “Route edges — offered vs matched”A route’s job is to select events, so its overlay shows two numbers: how many events were offered to the route, and how many it matched and forwarded. The difference is what the route filtered out.
This is exactly what you want when tuning a filter: if a route meant to keep “only errors” is matching 95% of what’s offered, your filter is too loose. If it’s matching 0%, it’s too strict — or the upstream isn’t sending what you think.
Connections between collectors
Section titled “Connections between collectors”When one collector forwards to another, the edge shows two lines: what the sender exported, and what the receiving collector accepted. If the sent line is healthy but the received line is flat, events are leaving the sender but not arriving — usually a missing receiver or a firewall on the target. LinkMesh also flags this specific misconfiguration directly on the edge.
Destinations — watch the queue and errors
Section titled “Destinations — watch the queue and errors”A destination node shows egress rate, but two extra signals matter more for catching trouble early:
- Queue fill bar — the exporter buffers events when the downstream (Grafana Cloud, Loki, your backend) can’t keep up. The bar fills as the queue grows; it turns amber past 80% and red past 95%. A filling queue is your earliest warning that data loss is coming — the collector drops events once the queue is full.
- Error flag — appears when the exporter is failing to send (rejected requests, timeouts). The destination tints red and shows an errors/second figure.
Per-processor drop rate
Section titled “Per-processor drop rate”Expand a route in a collector’s routing tab to see a Live
throughput strip: the route’s own offered→kept rate, then each
pipeline-processor step with its in → out and the percentage it
drops. A masking step should drop ~0%; a filter step drops by design.
A step shedding nearly everything is flagged — usually a
mis-written filter condition eating events you meant to keep.
Cadence and window
Section titled “Cadence and window”- Refresh: the numbers update roughly every 30 seconds — the interval at which collectors push their self-telemetry. A brand-new collector shows a flat baseline until its first push lands (within a minute of enrollment), not a false zero.
- Window: the canvas holds the last 24 hours of throughput. It’s a recent-trend view for spotting what’s happening now and over the last day — not a long-term history. For 30-day trends, pair a Prometheus scrape of the collector with your own observability stack.
The fleet-level summary
Section titled “The fleet-level summary”The canvas is the per-element view. For a one-glance fleet number, the Dashboard shows total throughput across all collectors, alongside the routes and destinations counts and a per-collector throughput column in the fleet table.
See also
Section titled “See also”- Self-telemetry — where these numbers
come from: the collector pushing its own
otelcol_*metrics over standard OTLP. - Build your first pipeline — wire up a source, route and destination, then watch the overlays light up.
- Route — how a route’s match filter selects events (the offered-vs-matched number on every route edge).