Distributed acceleration
Monitoring relay
Read the relay line, lag, backlog trend, payload and wire rates, compression ratio and capture spool on a relayed pipeline's page.
A relayed pipeline's page shows both halves under the one pipeline: the capture half on one agent and the apply half on the other. A figure an agent hasn't reported yet is left off rather than shown as zero.
The relay line
On a pipeline created with a relay, a line under the headline metrics is always visible:
- Relay, then one chip per half: capture: and apply:, each followed by the half's status. A green chip is healthy, red is failing, amber is anything in between. not reported means that half's agent hasn't sent a status yet.
- pending: the number of change events the capture half has read from the source that the apply half hasn't applied yet. It's the one figure that measures the relay rather than either half. It appears once both halves have reported.
Hover over a chip for the agent it runs on and its last error.
Relay details
Open Details under the metrics to see the rest:
| Chip | What it shows |
|---|---|
| capture lag | From the source commit to the capture half reading the change. |
| apply lag | From the capture half to the target commit. |
| backlog: | Whether pending changes are shrinking, growing or steady, fitted over the last minute. While it shrinks, the chip estimates when the backlog is drained. |
| serialized payload: | The uncompressed bytes per second of the changes the capture half shipped, averaged over a recent span that the tooltip names. initial load is added while a load runs. |
| wire: | The bytes per second the capture half actually put on the link, over the same span, followed by the compression ratio, for example 3.20x. |
| capture spool: | The size of the capture half's spool on disk. It grows while the link is down. |
| Endpoint | The address the capture half ships to. |
Each half reports only the lag it can measure itself, so there is no end-to-end lag figure.
Rates use decimal units: 1 MB is 10^6 bytes.
Compression ratio
The ratio after wire: is the serialized payload divided by the wire bytes over the same span. A ratio of 4.00x means the link carried a quarter of the bytes it would have carried uncompressed.
The ratio changes with the data and with how far behind the relay is: it is usually higher while the relay catches up, because the relay then compresses harder. See How relay works.
What to watch
| You see | It means | What to do |
|---|---|---|
| backlog: growing for a long time | Apply doesn't keep up with capture. | Check the apply agent and the target. See Sizing and tuning. |
| capture spool growing, wire at zero | The link is down or the apply agent is unreachable. | Check the apply agent and the network between the agents. The capture half keeps capturing meanwhile. Watch the source log too. |
| wire steady but low, backlog: growing | The link's bandwidth may be the limit. | Compare the wire rate with the link's capacity. See Sizing and tuning. |
| apply: not reported | The apply agent hasn't sent a status. | Check that the apply agent is online on Agents. |
The Details card
The Details card on the Overview tab names the relay's parts:
- Capture agent and Apply agent.
- Relay endpoint: the host and port the capture agent dials.
- Relay pairing: "negotiated by the control plane" and the pairing id.
- Relay security: "TLS 1.3 mTLS · exact-pinned identities".
Relayed targets
A target applied on another agent shows a chip in the Targets card: on agent, and · shared relay when other targets use the same pairing. The chip turns red with relay unavailable while that agent isn't online.
Relay logs
The apply agent's own log reports each listener it opens, with a relay apply line that says ingest listening on and names the endpoint. A connection that fails before the relay starts, such as a TLS handshake failure, is reported as relay ingest connection ended: with the reason.
The apply agent also records every relay connection in relay-audit.jsonl, under <data-dir>/spool/relay/.
