Documentation menu
The trust model
Fidelity, confidence and agent health, why every measurement carries how much to believe it, and how to use that during an incident.
Most monitoring presents every number as equally true. Measurement is not equally reliable, and the gap between those two facts is where bad incident decisions come from.
RouteSpear records how much to trust each measurement alongside the measurement itself.
The rule
Show your confidence; do not round it up. A degraded or uncertain measurement is surfaced with its reason, never quietly presented as clean data.
Three qualifiers carry this, and each answers a different question, at a different point in one measurement’s life:
Agent takes a measurement
│
├─ Fidelity ──────── how good was the measurement mechanism, this pass?
▼
Probe crosses each hop
│
├─ Confidence ────── is this hop really what it appears to be?
▼
Record is written
│
└─ Agent health ──── was the agent even in a position to see this?
Fidelity
How good was the measurement mechanism on this pass?
When a probe has to fall back to a less precise method, it records that it did. Fidelity describes the measurement, not the result. A low-fidelity sample is not a bad result; it is a result to weight differently.
This is what stops the most insidious kind of false alarm: a change in how you measured looking exactly like a change in what you measured.
Confidence
Is this hop really what it appears to be?
Hops are ambiguous more often than people expect:
- Load balancers send successive probes down physically different paths.
- Anycast means one address is a different device depending on where you are standing.
- Rate-limited routers answer some probes and ignore others, so a missing response is not a missing hop.
Confidence is recorded per hop rather than per measurement, because a path is usually unambiguous in most places and ambiguous in one. That one hop is the one that generates the wrong conclusion.
This is the qualifier you see most directly. In the path view, hops that are rate-limited or otherwise uncertain are drawn as uncertain, with the reason available on the hop. A router that discards probe replies while forwarding traffic perfectly produces alarming-looking loss that is not loss, and this is what stops you paging someone about it.
Agent health
Was I in a position to see what I am claiming not to have seen?
What the agent could and could not do at the time.
This is what makes a gap in a graph interpretable. A missing window is either the network being broken (a finding) or the agent being starved of CPU, which is not. Without agent health those two look identical, and they lead to opposite actions.
Using them
The path view marks uncertain hops directly, so the most common case needs no effort.
Beyond that, the qualifiers are fields on the record rather than decoration in the interface, which means they can be filtered and plotted like any other metric. You can build a panel that excludes low-confidence hops and compare it against one that does not; if a step change disappears when the uncertain hops are excluded, the step was ambiguity rather than a latency change.
Every measurement is also readable in full through Inspect on a result panel, including the qualifiers. There is no level of detail below that one.
A worked example
An RTT graph shows a step change at 03:14. Four questions, in order:
- Were the hops certain? If the step disappears when low-confidence hops are excluded, you were looking at path ambiguity.
- Was the agent healthy? If it was starved in that window, the step is an artefact of the instrument.
- Did the mechanism change? If fidelity dropped at 03:14, you changed how you were measuring, not what you measured.
- Only then is it a network event, and the route fingerprint tells you which hop changed and when.
The first three take seconds. In a system that discarded these qualifiers, each one is an argument that cannot be settled.
Why every sample is kept
Aggregating on arrival and keeping only averages is cheaper, and it works right up until the question is about one specific ninety seconds three weeks ago, at which point the data that would have answered it has been averaged away.
RouteSpear keeps the individual measurements and builds rollups alongside them. Dashboards read rollups because they are fast; investigations read the samples because they are still there.
The trust qualifiers are what make that worth doing. Keeping every sample only helps if you can tell the good ones from the doubtful ones afterwards.
Next
- Reading results
- Capabilities: where degraded measurements come from