Infrastructure monitoring

Open Monitor → Infrastructure to investigate the systems behind your measurements: the machines running applications, the switches carrying traffic, the containers consuming resources, and the radios serving users.

RouteSpear brings several kinds of evidence together. A machine can be known through an installed agent, an SSH collection, an SNMP poll, or local network discovery. Its detail page preserves those sources while connecting identity to interfaces, resources, workloads, and kernel measurements. You can move from a fleet-level symptom to the specific host, port, process, or wireless observation that helps explain it.

Find the right starting point

• Machines and identity: find a system by name, IP, MAC, or serial number; inspect what discovered it and why observations were correlated. Follow its source-specific tabs without losing its identity.
• Host and kernel diagnostics: inspect CPU, memory, filesystems, interfaces, and processes, then investigate scheduler wait, disk latency, process churn, and OOM events on supported Linux hosts.
• Network devices and SNMP: discover devices, read interface utilization and errors, trace learned addresses and neighbours, and inspect hardware, sensors, storage, printers, and UPS equipment.
• Containers and Kubernetes: start with workloads across hosts, drill into containers, and distinguish node resource pressure from cluster state such as missing replicas or unschedulable pods.
• Passive network flows: examine real TCP connections by peer and process, including retransmits, handshake timing, kernel packet-drop reasons, and local queue delay where supported.
• Wireless and access points: organize radios into physical access points and compare associated-link experience with radio coverage observed from your agents.
• Floor plans and positioning: upload or draw floors, calibrate scale, mark rooms, place known anchors, and inspect wireless samples across a building or campus.

Build coverage in layers

Infrastructure reads the observations your collectors produce. Opening a tab does not start a scan, enable a check, or grant an agent new privileges.

1. Establish a vantage point. Install an agent where it can observe the host, network segment, or radio environment you care about. For hosts without an installed collector, use Remote Host Metrics over SSH or SNMP as appropriate.
2. Configure collection. Use Configure → Test management to add the relevant checks. A local Host Metrics or Containers check measures its own agent host; an SNMP or SSH check measures a remote target.
3. Verify one successful sample. Check the test’s results, then find the machine or observation in Infrastructure. Inventory processing can add a delay after the first measurement arrives.
4. Add the next source when it answers a question. For a Linux service host, combine host resources, containers, and passive flows. For a branch switch, combine SNMP with path measurements from the users’ side of the network.
5. Make useful findings repeatable. Put supported metrics on dashboards or create health rules. Use test automation for assignment and running hours where the check’s placement rules allow it.

Agent enrollment, configuration, and releases remain under Configure → Agents. Infrastructure is where you investigate the observations those agents supply.

Follow a symptom across sources

For a slow application, first establish which users, agents, and times are affected in test results. Then use the evidence that can resolve the next question:

• Is the application host constrained? Inspect host resources, container throttling, or kernel scheduler and disk latency.
• Are real connections struggling? Check passive TCP peers and the processes opening those connections.
• Is a device interface showing trouble? Inspect SNMP utilization, errors, and discards, with neighbour and address tables to identify the relevant port.
• Is the issue local to wireless users? Compare their associated-link measurements and locations with the surrounding radio coverage.

These sources support one investigation, but their measurements answer different questions. A switch discard counter does not by itself prove which application packets were dropped. A busy host does not establish an upstream network fault. Keep the source, interface, vantage, and time window attached to each conclusion.

Read time and confidence together

Infrastructure offers Last hour, Last 6 hours, Last 24 hours, Last 7 days, and Last 30 days; the default is 24 hours. Machine, container, wireless, and flow views use this window, which is retained in their links. Floor plans expose their own window selector for wireless health and samples; their geometry and saved placements are current configuration.

Each detail panel retains its own sample time. An inventory entry last seen yesterday, a recent SNMP poll, and a flow aggregate over 24 hours are not a simultaneous snapshot. A shared relative window rolls forward when reopened.

Identity confidence, source badges, refused probes, skipped poll sections, and truncated samples explain what the product can support. Missing evidence remains unknown. An ARP sighting is not a health check, an unmeasured CPU is not idle, and an inferred floor position is not a surveyed location.

Use Ask Spear on a machine for an investigation or telemetry-coverage check in context. For missing or inconsistent observations, follow Infrastructure troubleshooting.