NPM (Network Performance Monitoring)

Continuous measurement of network performance, availability, and quality — latency, packet loss, jitter, throughput — using SNMP, flow data, packets, and synthetic tests.

Network Performance Monitoring (NPM) is the continuous collection and analysis of data about how a network behaves and how the traffic flowing across it performs. The point is to measure network quality the way users and applications actually feel it — to spot slowdowns early and pinpoint where the cause sits: which device, link, or service. NPM pulls data from several sources at once — device metrics, records of traffic flows, packets, and tests that generate artificial traffic — and compares them against a baseline, a stored picture of what the network looks like on a normal day.

What metrics does NPM measure?

Network performance is described by a handful of repeatable indicators. They form the core of any NPM system:

  • Latency — the time a packet takes to travel its path. It is usually given as RTT (round-trip time) in milliseconds. Rising latency usually means a congested link or a longer route.
  • Packet loss — how many packets never reach their destination. It matters a lot for voice and video calls, and for the TCP protocol, which then has to resend them.
  • Jitter — the variation in latency between consecutive packets. High jitter degrades calls and video even when average latency is low.
  • Throughput and bandwidth utilization — how much data was actually sent compared with the link’s capacity.
  • Errors and discards — errors on device ports or out-of-order packets that signal hardware faults or congestion.
  • Availability and device state — whether devices and ports are up, and how loaded their CPU and memory are.
  • Application-layer signals — DNS and HTTP response times, which tie the state of the network to what the user feels.

How does Network Performance Monitoring work?

NPM does not rely on a single data source. It combines several kinds of telemetry, because each shows the network from a different angle. The most common sources are:

  • SNMP — a protocol the system uses to poll devices every so often for port counters, status, and CPU and memory load. A classic, widely supported method, usually at minute-scale intervals.
  • Streaming telemetry — a newer method that replaces polling (e.g., gNMI, YANG models). Here the device pushes data almost in real time, more often and in more detail than SNMP.
  • Flow data — condensed records of conversations between IP addresses: NetFlow, IPFIX (the IETF standard), sFlow (sampling), J-Flow. They show who talks to whom, how much data they send, and which applications generate the traffic — without looking at the content itself.
  • Cloud flow logs — VPC Flow Logs (AWS), NSG Flow Logs (Azure), VPC Flow Logs (GCP). They give visibility into hybrid and multi-cloud environments.
  • Packet data (packet capture, PCAP) — capturing packet headers, and sometimes full payloads, for the deepest analysis. The most detailed source, but resource-heavy and dependent on special tap points (network TAP, SPAN/mirror port).
  • Synthetic tests — probes that generate traffic mimicking a user (ping, traceroute, DNS/HTTP checks). They catch problems before a person reports them and measure path quality to cloud services and across the internet.

The collected data is cleaned up, correlated, and compared against baselines. Deviations from normal trigger alerts and feed reports and dashboards.

What is a baseline in network performance monitoring?

A baseline is a history-derived picture of „normal” network behavior — typical latency, bandwidth use, and traffic patterns for a given time of day and week. Alerts based only on fixed thresholds create noise and miss context-dependent problems. Comparing against a baseline lets you catch anomalies — departures from the norm — instead of waiting until traffic crosses some preset value. Security detection rests on the same idea: a sudden spike in outbound traffic, unusual top talkers (the addresses generating the most traffic), or new pairs of communicating devices can signal an incident, not just a performance issue.

How does NPM differ from APM, NDR, and NMS?

Network performance monitoring sits next to several related fields that are easy to confuse:

  • NPM vs APM (Application Performance Monitoring) — APM looks at the application itself, usually through agents built into the code that trace specific transactions. NPM looks at the network: devices, links, flows. APM tells you which transaction is slow; NPM tells you whether and why the network is to blame. Together they settle the old „it’s not the app, it’s the network” argument.
  • NPM vs NDR (Network Detection and Response) — both analyze traffic, but for different reasons. NPM asks „what is slow and why”; NDR asks „what has been compromised and how.” NDR uses the same telemetry (flows, packets, metadata), but to hunt for threats: an attacker’s lateral movement across the network, command-and-control links, and data exfiltration.
  • NPM vs NMS (Network Management System) — NMS focuses on whether devices are alive and ports are up. NPM goes further and measures service quality and the user’s experience. The related term NPMD (Network Performance Monitoring and Diagnostics, per the research firm Gartner) stresses combining device metrics, traffic data, and raw packets into a single troubleshooting process.

Why does NPM matter for security?

NPM was built to measure performance, but its data is also useful for security and the work of a SOC (Security Operations Center). The same flows and packets that reveal a bottleneck also expose an attacker’s traces:

  • Traffic anomaly detection — a departure from baseline (a volume spike, unusual ports, new connection directions) can mean network scanning, lateral movement, or a command channel.
  • Data exfiltration signal — unexpected, long-running outbound traffic to unknown addresses is often the first visible sign of data theft.
  • DDoS detection — a sharp rise in packets per second, packet loss, and link saturation is the classic picture of a volumetric attack, which NPM sees almost in real time.
  • Context for SIEM and SOC systems — network data enriches events from other sources and provides independent evidence where logs from the machines themselves fall short (IoT/OT devices, agentless hardware).
  • Post-incident analysis (forensics) — retained flows and packets let you reconstruct an incident after the fact.

This is the boundary between performance monitoring and threat detection: the same data stream feeds both NPM and NDR-class tools. From an operations standpoint, NPM is also a natural part of the NOC (Network Operations Center), where it underpins visibility and response time to events affecting service availability.

Learn more

  • Probe (Sonda) — A probe collects network data used to monitor performance and detect issues.
  • Digital Experience Monitoring — DEM measures user-facing service quality, complementing NPM with endpoint experience data.
  • Network Observability — Network observability uses NPM data to understand traffic, behavior, and faults.