Skip to content
RouteSpear
Documentation
Documentation menu

Managing agents

Status, reconfiguration, remote restart and upgrade, and the history of what an agent has been told to do.

Configure → Agents lists every agent, with its version, operating system, status and when it was last heard from. Selecting one opens its detail.

Named agent clusters

Open Configure → Agents → Agent clusters, enter a cluster name and choose Create cluster. Add agents and assign each membership a role: Measurement worker, Test worker, or Measurements + tests. Customers manage private clusters; provider operators manage public clusters through Admin → Fleet.

Set the Measurement vantage group to the intended network location and egress, enable Centrally coordinate measurement placement, and save. Enable shared hop context for coordinated direct-hop measurements. Assign tests to the named cluster using the Agent picker.

For ten agents, you can choose three measurement workers and seven test workers. The control plane assigns measurement keys among eligible workers and sends membership and assignment information when agents phone home. There is no elected peer leader: ownership is per measurement and protected by a lease. Roles apply to cluster placement, not mandatory host reporting or direct assignments.

A common router IP does not make separately collected samples interchangeable. Shared context retains the actual source and keeps destination-specific path measurements separate. Group only agents representing the intended vantage.

Tenants cannot change provider-owned public membership, worker roles or safety limits. Public measurements have target restrictions and capacity caps, including in financial observation mode. Private clusters remain tenant scoped and can measure authorized internal networks. See shared usage for allocation and settlement.

Overview

The overview shows health at a glance, the network interfaces the agent can see, and the address its traffic actually leaves from.

The egress address is more useful than it looks. An agent whose traffic exits somewhere unexpected (through a VPN it should not be on, or via a secondary circuit) is measuring a path nobody meant to measure, and every result it has produced needs rereading in that light. It is worth checking whenever a site’s numbers look inexplicably different from its neighbours.

Tests

Which checks this agent is running. The quickest way to answer “why is this host busier than the others” and to confirm a new test actually landed somewhere.

Resources

The agent’s own health over time: what it can do, what it is spending, and whether it is keeping up.

An agent is a measuring instrument, and an instrument under load produces worse measurements. A host that is short of CPU will add its own scheduling delay to every latency figure it reports, which looks exactly like network latency and is not. Check here before believing a site has gone slow.

Configuration

Reconfigure changes the agent’s name, labels, location, probe budget and concurrency limit.

Labels are worth keeping disciplined. They drive dashboard grouping, so a consistent site and role across the fleet is what lets one panel cover everything without being edited each time a site is added.

For VDI fleets, the image wizard uses an agent label such as pool=Finance desktops. It does not create a network scope or a named agent cluster. Target the pool with a dynamic label selector using key pool and the exact pool-name value; optionally add a network scope to narrow it. See VDI pool targeting and endpoint matching for the rollout steps and current release requirements.

Location places the agent geographically, which feeds the agent map and the geographic path view.

Probe budget and concurrency cap what the agent will do. Lower them on a host that is doing something else important, or on a link where probe traffic itself is a consideration. Note that a served configuration can only lower an agent’s ceilings, never raise them past what the host was started with, the limit belongs to whoever administers the host.

Restart and upgrade

Reset agent, beside Restart on the Overview tab, clears this agent’s local spool and pending uploads, then restarts collection. The confirmation explains that discarded measurements cannot be recovered and tests briefly stop. Choose Clear pending data and restart to proceed, or Cancel to keep the backlog. Enrollment, settings, and uploaded history remain. Uploads already in progress may still arrive. Ordinary Restart agent preserves pending measurements.

Reset requires agent management permission and an updated agent that reports reset support. An offline request waits for reconnection and expires after 15 minutes. The portal distinguishes queued, resetting, failed, expired, and reconnected states; check the service on the host if it does not return.

Two commands can be sent from the portal.

Restart stops and restarts the agent cleanly. Restarting is uneventful by design: results already measured are on disk in the agent’s spool, so nothing in flight exists only in memory.

Update upgrades the agent to a newer build, and can be applied in bulk from the agent list. Bulk upgrade is the reason to keep the fleet current without scheduling a change window per host.

Both are requests rather than instant actions. The agent picks them up on its next poll, so an agent that is offline runs the command when it returns.

Logs

The Logs tab is the history of commands and events for that agent: what it was asked to do, when, and how it went.

This is the record to check when an agent is not doing what you think you told it to do, because it distinguishes the two cases that look identical from outside, the instruction never arrived, or it arrived and failed.

Application log collection is configured separately under Configure → Log ingest rules. Choose a collection agent, a local file or Windows event channel, or a remote SSH host. Select which unhealthy agents or tests trigger capture; returned excerpts appear in the triggering incident’s Log evidence section. Local sources also support Log Beacon and numeric extraction. See log ingest rules.

Reporting identity and fleet actions

The reporting identity section shows lease state and historical identity conflicts. A conflict can follow a copied credential or a recent process restart; it does not by itself prove an active clone. A reporting lease is separate from agent uptime and is not a connectivity test. See ephemeral agents and usage limits.

Select agents in the fleet list to preview eligible bulk updates or changes to active/suspended status. An update success means the command was queued; check later for installation completion. Suspension blocks configuration delivery and ingestion while leaving the installed service on the host. Reactivation resumes reporting and can increase usage.

For small endpoint deployments, the install wizard includes a thin-client preset. For available builds and update selection, see agent releases.

Removing an agent

Uninstall the service on the host, using the uninstall script from the install pack. Removing an agent from the portal is not available today; agents that stop reporting show as such, and the records they produced remain until they age out normally.

Next

Before reconfiguring a host

Confirm the agent identity and recent status, then review the changed settings before submitting. The reconfiguration dialog keeps its heading and actions visible while its settings scroll.

After applying a change, check the agent’s next report and any capability errors. Downloading a new install pack and changing a running agent’s configuration are separate actions.

Screenshot