Reading the network views

Dashboard

Network → Dashboard summarizes every test — pass/fail, latency and loss trends, the worst performers — and the mesh health across your agents. Read it top-down: a red tile is a test crossing its threshold now; the trend charts tell you whether it is a spike or a slide; the worst-performers list tells you which target to open first.

Topology

Topology draws agents, test targets and discovered devices as a map, with health on every link. Select a test to overlay its measured path, so a degraded edge and the test that proves it sit on the same picture. Discovery adds what agents found on their local networks — where it is enabled — and SNMP-polled devices appear with their interface health.

Agents and the mesh

Agents is both the fleet list and the mesh view. Each agent card shows status, host, version, capabilities and its measurements to every other agent — latency, jitter, loss and, if you have turned it on, bandwidth. The latency matrix puts every pair on one grid: for a multi-site estate this is the fastest way to see that it is Frankfurt ↔ Singapore that is struggling and not Frankfurt in general.

Path Analysis

Path Analysis is the hop-by-hop route from an agent to a target, kept over time so you can see where the route changed and where the latency is introduced. Read the RTT column downwards: the hop where it jumps is where the problem starts. Hops inside your own address space are yours to fix; a jump at a transit provider's hop is evidence to send them; a jump only at the last hop is the destination.

Events & Changes

Events & Changes is the chronological record: route flips, agents going offline and coming back, tests crossing and recovering from thresholds. It is the tab to open when someone asks "what happened at 14:20?" — and the one that turns a topology snapshot into a story.

Dependencies

Dependencies comes from passive observation rather than from tests you remembered to configure: what each host actually talks to, the traffic matrix between hosts, and the top talkers, over the last 15 minutes to 24 hours. Every view states the completeness of what it shows. Exact means an eBPF collector saw every connection; Sampled · counts are lower bounds means the collector reads the socket table on an interval and misses connections shorter than it; and a host whose collector could not run is shown as unavailable, never as an empty table — because "we could not look" and "it talks to nothing" are different findings and only one of them is reassuring.

Metrics

Metrics exposes the raw series behind everything above — latency, loss, jitter per test and per agent — for when you want to overlay two targets, zoom into one hour, or export the numbers. The same series are written to the platform's metrics store as network_test_*, network_mesh_* and network_agent_* metrics, so they are available in dashboards, Data Explorer and alert rules like any other metric.

Cookbook: localize a latency complaint

1. Open Dashboard; confirm which test and target are degraded, and since when.
2. Open Agents. If the agent that runs the test is red to every peer, the agent's own host or uplink is the problem, not the target. Stop here and look at that machine.
3. Otherwise open Path Analysis for the target from that agent and find the hop where RTT jumps.
4. Open Events & Changes around the time it started: a route flip at the same minute is your cause.
5. If the bad hop is outside your network, you have evidence it is the provider, with timestamps; if inside, you know which segment to fix. Either way the alert already went to the right people, because the test carried the threshold.

In a Workbook, a Network Probe node runs the same probe inline, so a pipeline can confirm the application can reach its database before asserting on a write.