Network monitoring overview
Path health from the points that matter: active tests from network agents, passive observation of what hosts talk to, and SNMP for the devices in between — and what the platform never renders as 'nothing wrong'.
What network monitoring is for
Network monitoring answers the question host monitoring cannot: is the path healthy, and if not, where is it broken? A server can be up, its service healthy, and a branch office still unable to reach it — because of a saturated link, a bad hop at a transit provider, a DNS resolver that has started timing out, or a certificate that expired last night. VerOps measures the network from the points that matter to you and shows where latency, loss and failures are introduced.
It does this from network agents — small services you install at the vantage points you care about: a branch, a VPC, a data centre, a region. Everything in this category flows from them.
Three ways of seeing the network
| Method | What it measures | Where it comes from |
|---|---|---|
| Active tests | Reachability, latency, jitter, loss, DNS resolution, full HTTP timing, TLS certificate validity, hop-by-hop path, path MTU, agent-to-agent bandwidth — on a schedule, from the agents you choose. | Created under Network → Tests; the platform assigns them to agents, which run them and report results. |
| Passive observation | Which processes on a host are talking to which endpoints, how often and whether it succeeds — dependencies, traffic matrix, top talkers. Never payloads. | Opt-in on the agent ([passive]); eBPF where the kernel allows it, socket-table sampling otherwise. Optional NetFlow v5/v9 collector for router-exported flows. |
| SNMP | Switches, routers and firewalls: event-driven traps and scheduled polling for reachability, uptime and per-interface health. | The agent on the same network as the devices; targets and credentials managed in the platform. |
Agents also measure each other. When more than one agent is deployed they form a mesh, continuously sampling latency, jitter and loss between every pair — which is how a multi-site estate sees which pair of locations is struggling, not just that something is slow.
What you get
- Dashboard — every test's pass/fail, latency and loss trends, and the worst performers.
- Topology — agents, targets and the links between them, with health on each edge.
- Path analysis — the hop-by-hop route to a target so you can localize degradation to your network, the provider, or the destination.
- Dependencies — from passive observation: what each host actually depends on, and what it is failing to reach.
- Events & changes — route flips, agents going offline, tests crossing thresholds, in order.
- Alerts — every test carries thresholds; results feed the same alert rules, silences and on-call routing as the rest of the platform.
Where to start
- Install a network agent at your first vantage point — the one closest to the users who complain.
- Create a test to the thing they are trying to reach.
- Add a second agent somewhere else and let the mesh tell you whether the problem is the path or the destination.
- Read the results with the network views, and turn on SNMP for the devices in between.
Design rule worth knowing: the platform never renders "nothing observed" as "nothing wrong". Where a collector could not run — an agent without raw-socket privileges, a host where eBPF could not load, a sampled view that misses short connections — the view says so rather than drawing an empty, reassuring grid.
In a Workbook, the Network Probe node runs the same probes inline, so a pipeline can confirm the application can reach its database before asserting on a write.