Core concepts

Six terms cover almost everything. They are worth five minutes because the portal uses them literally.

Agent

The software you install on a host. It runs the checks assigned to it, writes results to a local buffer, and ships them.

An agent is also a vantage point, a place a measurement is taken from. This is the part that makes network measurement different from uptime monitoring. “Is the ERP system slow?” has no single answer; it is fast from the data centre and slow from the Dublin office, and knowing which is the whole job. You get that by putting agents where the users are.

Test

A named thing you are measuring, usually against one target. “Path to the Frankfurt VPN concentrator.” “The customer-facing API.”

A test holds the target, the address family, its labels, and one or more checks. It is the unit you create, name, enable, disable and delete, and the unit results are shown for.

Check

One kind of measurement inside a test. A test against your API might contain an HTTP check, a DNS check and a Path Health check, three different measurements of the same target, on one screen, sharing one definition.

Each check has its own interval, timeout and parameters. That matters because useful intervals differ by an order of magnitude: an HTTP check every 30 seconds is reasonable, whereas a full path trace every 30 seconds is mostly noise and wasted probes.

Checks are grouped by what they need, and the groups cannot be mixed arbitrarily:

Group	Needs	Examples
Remote target	A host, URL or IP	Path Health, HTTP, DNS, SSH, TCP Connect
Local link	Nothing; measures the network the agent is on, or the host itself	DHCP, ARP Scan, WiFi Scan, LLDP, Host Metrics
Standalone	Its own arrangement	SNMP, SNMP Discovery, Multi-agent mesh
Custom	A script you supply	Custom Script

Remote-target checks combine freely with each other. Local-link checks combine freely with each other. The two do not mix, because one needs a target and the other has none. Standalone checks stand alone. The portal disables the combinations that cannot work rather than hiding them, so the constraint is visible while you are choosing. See check types.

Labels

Key-value pairs attached to agents and tests: site=dublin, tier=production, circuit=mpls-primary.

Labels are how you ask questions across many tests at once. A dashboard panel can plot a metric across everything labelled site=dublin without naming the tests individually, so adding the twelfth branch office does not mean editing eleven dashboards.

Network scope

A special grouping derived from selected agent tags that tells RouteSpear how to interpret internal devices and IP addresses. It keeps devices on separate networks apart when they use the same IP.

For example, two isolated LANs or VLANs might each have a gateway at 192.168.1.1. Giving them different network scopes prevents RouteSpear from treating those gateways as the same device. Agents in the same network scope can contribute observations about the same devices; matching IPs alone do not prove device identity.

Choose the tag keys under Organization → Network scope. If you select site and vrf, an agent tagged site=london and vrf=corporate gets the scope site=london/vrf=corporate. Ordinary tags remain available for filtering; only the selected keys define the network scope.

With no keys selected, or a required tag missing, each agent gets its own scope: agent:<id>. Changing the keys or their values affects new data; historical data keeps its original scope.

Record

One measurement result. A single execution of a check produces one record: what was measured, when, from where, what came back, and how much to trust it.

RouteSpear keeps the records, not just averages of them. Rollups exist and are what dashboards read for long time ranges, but the underlying samples remain queryable, because the interesting question during an incident is usually about one specific bad minute rather than the hour containing it.

Each record carries three trust qualifiers, fidelity, confidence and agent health, describing how good the measurement mechanism was, how certain each hop is, and what the agent could and could not do at the time. These are the numbers most tools discard. The trust model explains them.

How they fit together

Agent  (a host, somewhere that matters)
  └── runs checks assigned to it
        └── belonging to a Test  (a target you care about)
              └── producing Records  (with trust qualifiers)
                    └── read as results, panels and dashboards
                    └── or watched by a health rule, which pages a channel
                          through a policy, see Alerts

Next

• Creating tests
• Check types
• Alerts: watching a record’s metric continuously instead of reading it
• The trust model