Skip to content
RouteSpear
Start free

Choose the evidence your team is missing.

Network visibility is usually assembled from several tools that each see one slice. It is worth being precise about which slice each one sees, because the gap between them is where the expensive incidents live.

We have deliberately not written this against named products. Feature grids comparing vendors go stale within a quarter and are written to be won rather than to be accurate. Approaches are more durable, and you can map the products you are actually evaluating onto them yourself.

Uptime and synthetic checks

Status pages, HTTP monitors, scripted browser checks

Where it helps
Unbeatable at answering "is the service up, from outside, right now". Cheap, easy to run, and the right first alarm for a public endpoint.
What to investigate next
They measure an outcome and stop. When the check goes slow, everything between the prober and the service is one opaque box, so the finding is "it is slow" and the next step is a conference call.
Where RouteSpear fits
RouteSpear measures the same outcomes and the route underneath them at the same time, on the same schedule and the same timeline, so the answer arrives with a location attached.

Complementary. Keep them; they answer a different question.

Traceroute and MTR

Command-line diagnosis, on-demand path tools

Where it helps
The correct instinct. Looking at the path is exactly right, and MTR adds the repetition that turns a snapshot into a rate.
What to investigate next
An on-demand trace describes its current time and vantage point. Implementations that vary fields used by load balancers can also combine hops from different routes; flow-consistent traceroute methods address that limitation.
Where RouteSpear fits
Runs continuously from assigned vantage points and retains the history. Supported transports hold a flow constant within each trace; stable flows track changes and an explorer samples other branches. Transport limitations remain part of the result.

Direct replacement, and the closest thing to what we are.

SNMP polling and device monitoring

Interface counters, device health, traditional NPM

Where it helps
Authoritative about equipment you own. Interface errors, discards, saturation and device health are facts straight from the device, and nothing infers them better.
What to investigate next
It can only see devices you administer. The moment traffic leaves your edge it is invisible, which is where an increasing share of the things people complain about now live. Every interface can be green while the path through them is unusable.
Where RouteSpear fits
RouteSpear polls SNMP too, including subnet discovery so the inventory maintains itself. The difference is that device health sits beside path measurement rather than standing in for it.

Complementary, and partly included.

Flow analytics

NetFlow, sFlow, IPFIX, packet brokers

Where it helps
The best answer to "what is on my network and who is talking to whom". Indispensable for capacity planning, security investigation and settling arguments about bandwidth.
What to investigate next
Flow records describe volume, not experience. They will tell you a conversation happened and how many bytes it moved; they will not tell you it took four hundred milliseconds to establish and retransmitted a fifth of its segments.
Where RouteSpear fits
On Linux hosts RouteSpear can observe real TCP behaviour in-kernel (retransmits, resets, failed connects, smoothed round trips) per peer, without sending a probe. Real traffic, measured for quality rather than counted.

Complementary. Different axis entirely.

APM and real user monitoring

Tracing, front-end analytics, session replay

Where it helps
Definitive about what your users experienced and where time went inside your application. If the slow part is your code, this is the tool that proves it.
What to investigate next
The network appears as a single unexplained interval. RUM can tell you the users in one office had a bad afternoon. It cannot tell you which hop, or whose.
Where RouteSpear fits
Fills in that interval from vantage points that sit where those users sit, which turns "the network was slow for the Manchester office" into a specific link with a specific owner.

Complementary. We are the missing half of the timeline.

Every tool on that list is authoritative about something it owns

Your APM owns the application. Your SNMP platform owns the devices. Your flow collector owns the traffic crossing your edge. Each is excellent inside its boundary.

The path between them is owned by nobody. It crosses your LAN, your firewall, your circuit, one or more carriers, and somebody else's cloud, and it is where a growing proportion of user-visible problems now occur, precisely because it is the part no existing tool is responsible for.

That is the gap we were built for. Not another opinion about your servers, but continuous measurement of the connective tissue, from the places your users actually sit.

The conversation this ends

A branch office reports that the ERP system is unusable. The application team shows green dashboards and normal response times. The network team shows every interface healthy and no errors. The carrier reports no faults on the circuit.

Everybody is telling the truth. Everybody is looking inside their own boundary, and the problem is in the space between them, typically one leg of a load-balanced path, degraded but not down, which is invisible to every tool in the room.

With a continuous per-hop record from that office, the meeting is a lookup instead of a negotiation.

Six questions worth asking every vendor, including us

These separate tools that measure the path from tools that draw one. We have written our own answers on the measurement pages; ask the same of anyone else on your shortlist.

  1. 01

    Does it hold the flow identifier constant across the whole path?

    If probes change fields used by a load balancer, the hop list can combine different routes. Check the recorded transport and flow-control limits before comparing adjacent hops.

  2. 02

    What does it do when a hop stops answering but traffic still gets through?

    If the answer is "shows loss", you will be paging people about healthy routers, and your team will learn to ignore the middle of the path.

  3. 03

    Does it keep measuring when it cannot reach its own control plane?

    Otherwise the record of your worst incident is a gap in the graph across exactly the window everyone will want to examine.

  4. 04

    Can the vendor raise the probe rate on agents inside my network?

    If rate limits live server-side, a compromise of the vendor is a compromise of your network capacity.

  5. 05

    Are individual samples kept, or only rollups?

    Averaged data cannot answer a question about a specific minute last month, which is the question incident reviews actually ask.

  6. 06

    Does a measurement record how it was taken?

    Without the transport, the clock resolution and the degradation reason, you cannot know which figures are comparable, and you will eventually compare two that are not.

Read our answersBook a demo