Network Monitoring Systems

Network monitoring systems (NMS) are designed to help network administrators monitor their networks. However, the concept of “network” has evolved since the term started being used.

Traditionally, it was used to describe the network infrastructure within an organization’s control, including routers, switches, firewalls, and servers located in data centers or public clouds. In recent times, it has extended to network services outside the organization’s direct control, including anything that could affect the end-user’s experience, such as the path through internet service provider networks and third-party services.

This article explores traditional network monitoring systems, including their components and the metrics typically measured. Beyond that, it also examines recent advances in network monitoring, including the modern internet stack and network experience monitoring.

Summary of Key Network Monitoring Functionality

Traditional Network Monitoring Systems

The first thought that a network engineer or administrator has when they hear “network monitoring” is a tool to gain continuous insight into the infrastructure they own and control, such as routers, switches, firewalls, and servers, using pings or the Simple Network Management Protocol (SNMP) or NetFlow. These tools can be hosted locally (on-premise) or in the cloud. They provide metrics such as:

• Availability monitoring: “Is the device online?”, interface up/down
• Health monitoring: CPU and memory utilization, temperature, and fan status
• Performance monitoring: Latency, packet loss, jitter, throughput
• Traffic monitoring: Bandwidth usage, traffic patterns and anomalies, top talkers
• Application monitoring: “Is the process running?”, service dependencies

The typical setup of such tools includes an interface to manage and monitor devices, a method to capture relevant data from managed devices, and some form of alerting.

Management Interface

Network monitoring systems typically include an interface for managing devices. This can be presented as a command-line interface (CLI) or a graphical user interface (GUI). Such interfaces will allow you to:

• Add a new device or device groups to be managed. This will typically be via an IP address or hostname.
• Specify the data collection method(s) for those devices (as defined in the next section).
• Optionally, monitor the devices that are being managed.

Some tools provide monitoring features in the same management system, while others rely on external or third-party tools. Monitoring can range from simple visualization of monitored devices and their status to more complex features, such as the ability to view historical data and display alarms.

Data Collection

Network monitoring systems collect data from devices using different methods.

Ping

This is a simple utility that uses the Internet Control Message Protocol (ICMP) to monitor availability. It can also provide performance monitoring, such as response times and packet loss. One thing to note about ping is that some firewalls block ICMP by default, which means the ping may fail. Therefore, such networks must take an extra step to allow ping within their domain.

SNMP

Simple Network Management Protocol (SNMP) is a standardized protocol for monitoring and managing network devices. It uses a manager-agent model in which the SNMP manager polls the agent on the device to get or set specific parameters, known as management information base (MIB) variables.

For example, there can be an MIB variable for CPU utilization and another for disk usage. Agents can also send messages to the manager in the form of traps or inform requests.

Flow

Network flow technologies, such as NetFlow, sFlow, and IPFIX, are particularly useful for traffic monitoring and analysis. They collect useful statistics about network traffic, such as source and destination addresses, top talkers, and traffic patterns. They can also be used for traffic analysis (e.g., bandwidth usage) and anomaly detection.

Logs

Network devices produce log messages when specific events occur, such as a switch interface going down. These logs can be sent to network monitoring systems for processing (and storage). Logs aren’t easy to work with due to their unstructured nature, but protocols like syslog can be helpful.

Custom Checks

Scripts can be written to check certain metrics. This is usually done when the network monitoring system doesn’t have that feature out of the box, or if the information should be presented differently. Common programming languages like Python may be used to write these checks, or they may rely on standard management protocols like SSH or Telnet. These checks are particularly useful for application and service monitoring.

Agents

The data collection methods mentioned already operate using industry-standard protocols, which are implemented in the software of most network devices. As such, we can refer to them as “agentless” monitoring. It may also be necessary to install agent software on devices to enable certain monitoring capabilities.

Alerting and Notification

One goal of monitoring is to know when something happens so you can choose to take action. As such, network monitoring systems typically include a mechanism to set up alerts around key events with their managed devices.

Alerts can take various forms, including color-coded symbols/lists (e.g., a red icon indicating a downed router), flashing messages on the dashboard, or notifications sent via channels such as SMS, Slack, or email.

Some network monitoring systems go beyond alerting to taking action. For example, a system could be configured to restart a Linux process whenever it dies.

The Modern Internet Stack

Modern internet technologies present a challenge for traditional network monitoring systems. Even when internal tools report no issues, the multiple internet hops between users and the application remain outside that view, and those hops directly affect the experience.

These hops and paths are out of the organization’s control but directly affect the user’s experience. This has given rise to the concept of an Internet stack, which includes the components below.

ISP and BGP

Internet service providers (ISPs) are the gateway through which an organization’s network connects to the global internet. Border Gateway Protocol (BGP) is the routing protocol of the Internet. It enables ISP-to-ISP communication, and in some cases, peering between an organization’s network and its ISP. Multiple issues can occur at this level, including bottlenecks, outages, suboptimal routing, and even the loss of BGP routes with upstream providers.

In one case study, an organization’s VPN connections to AWS routes frequently and randomly dropped. Tunnels to non-AWS destinations stayed up. The team eventually determined that the internet path through that ISP was dropping traffic or losing BGP routes. They moved the tunnels to a device using a different ISP, and they remained stable.

DNS

The Domain Name System (DNS) works in the background to resolve the IP address of a network resource when a user types its URL or fully qualified domain name (FQDN). DNS infrastructure must be available, respond quickly, and provide accurate results. DNS records must be authentic, and changes must propagate quickly. Additionally, security attacks such as DNS floods and DNS cache poisoning pose common challenges to DNS.

For example, on October 20, 2025, many internet services, including Ring, Zoom, and Roblox, were severely affected for several hours due to DNS resolution issues with an AWS API endpoint on which these services rely.

CDN

Content Delivery Networks (CDNs) allow web content to be stored (cached) and delivered closer to users, leading to lower latency and a better user experience. Misconfigured settings, caching issues, and network-level outages are among the issues faced by CDNs.

APIs

Many mobile and web applications rely on internal and 3rd party application programming interfaces (APIs) to function. Payment gateways, “Login with X”, and Google Maps API are real-world examples of API usage. Factors that can affect a user’s experience, apart from API availability, include response times, throughput, and data accuracy.

Monitoring Systems for the Entire Network Experience

Traditional network monitoring isn’t sufficient on its own and must be complemented by tools that monitor the entire network experience. Here are some features expected of such tools.

Synthetic Monitoring

These tools monitor network reachability and performance from the user’s perspective, using simulated user flows (synthetic monitoring), HTTPS/ICMP/DNS tests, and traceroute from globally distributed agents.

This enables the visualization and analysis of data across trends and benchmarks, allowing an organization to identify issues before users raise them.

Traceroute, for example, can be useful in “tracing” the network path between a source and destination, providing visibility into routing, and allowing you to identify sub-optimal paths. It supports both IPv4 and IPv6.

Here’s an example output from running traceroute, highlighting the hops taken to reach the destination and the times taken to reach those hops.

Microsoft Windows [Version 10.0.19043.1288]
(c) Microsoft Corporation. All rights reserved.
C:\Users\Michael>tracert catchpoint.com
Tracing route to catchpoint.com [64.79.149.76]
Over a maximum of 30 hops:
1	2ms	1ms	1ms 10.0.0.1
2 	10ms	10ms	10ms 96.120.40.245
3	10ms	11ms	12ms	96.110.175.85
4	10ms	16ms	10ms 	162.151.63.57
5	19ms	16ms	20ms	96.108.21.57
6	15ms	19ms	14ms	96.216.134.10
7         	19ms 	22ms 	21ms 	be-32121-cs02.350ecermak.il.ibone.comcast.net [96.110.42.181]
8         	22ms 	34ms 	22ms 	be-2204-pe04.350ecermak.il.ibone.comcast.net [96.110.37.38]
9         	22ms 	20ms 	20ms 	50.208.234.106
10       	51ms 	50ms 	49ms 	ae18-0.cr02.dlls02-tx.us.windstream.net [40.128.10.135]
11       	73ms 	72ms 	72ms 	ae4-0.agr03.phnd01-az.us.windstream.net [169.130.193.231]
12       	84ms 	73ms 	75ms 	ae1-0.pe05.phnd01-az.us.windstream.net [169.130.169.31]
13       	85ms 	84ms 	85ms 	h241.23.132.40.static.ip.windstream.net [40.132.23.241]
14       	*         	82ms 	78ms 	be181.las-n10s1-core1.switch.com [66.209.64.121]
15       	79ms 	77ms 	80ms 	bell011.las-agg7s5-1.switch.com [66.209.72.26]
16       	79ms 	77ms 	79ms 	64.79.139.18
17       	77ms 	77ms 	87ms 	64.19.149.76
Trace complete

BGP Monitoring

These monitoring tools should detect BGP route leaks, outages, and configuration errors. This is typically done by collecting and analyzing BGP data, like peering sessions, prefix updates, and AS path changes. This data can be collected by peering directly (passively) with an organization’s edge routers or peering with public BGP route collectors.

Real User Monitoring

Perform real user monitoring (RUM) to analyze metrics such as page load time, DNS latency, and CDN response time. This complements synthetic monitoring because it takes and analyzes data from real users’ devices, rather than relying on simulated user paths like synthetic monitoring does.

Organizations typically implement RUM by adding JavaScript code to their application or website, which collects data when users visit it. The tool then analyzes this data to identify user interactions (pages visited, navigation, etc.), bugs, or performance issues, which can inform improvements to the application or website.

In a specific RUM use case, an organization noticed that its website page load time was significantly slower for users in the UAE. It was able to determine this because its RUM tools capture data such as users’ locations, OS, and web browser type.

Armed with that information, the organization used synthetic monitoring tools to determine which point of the internet path is responsible for this slow access.

The screenshot below, from LogicMonitor’s RUM solution, shows bounces, page views, and conversions for users accessing the application, grouped by the cities they’re located in.

API Monitoring

Such monitoring tools should support API observability to analyze and understand API performance. This works by collecting data from:

• Metrics, such as API endpoints’ uptime, response times, and error rates
• Logs, which are quite useful for debugging, as they provide records of events and errors
• Traces, which offer a complete view into the journey of an API request

An effective tool provides API monitoring using both synthetic and real-user monitoring and presents the data in a robust dashboard.

An API monitoring dashboard combining relationships and metrics 

Endpoint Monitoring

Finally, such tools should be able to look beyond the devices in the network path to the devices being used to access an organization’s resources. For example, a user with a poor WiFi connection or bogged-down CPU will complain of “slow access” even though the fault is with their endpoint.

Endpoint monitoring will typically involve installing an agent on the device to monitor metrics such as system performance (CPU and RAM usage), applications and processes (e.g., Microsoft Teams), and network activity. Since agents need to be installed, endpoint monitoring is mostly useful for the employees of an organization who now work from more diverse locations, such as in the office, from home, or from public spaces.

A typical digital experience score report showing data from monitored endpoints (Source: LogicMonitor)

Conclusion

In this guide, we looked at how traditional network monitoring systems help organizations keep an eye on their internal infrastructure. These tools aren’t sufficient on their own because they don’t account for areas of the network the organization doesn’t control, such as CDN, DNS, and APIs. As such, traditional network monitoring systems must be complemented by platforms that monitor the entire internet stack.

FAQs