Network Monitoring: Are We Overcomplicating Something That Used to Be Simple?

I’ve worked in enterprise networking for more than 25 years, and one thing I’ve learned is that good network monitoring doesn’t have to be complicated.

Years ago I used SolarWinds Orion extensively. I could open a dashboard, pick a router or switch, look at interface utilization and historical bandwidth, and spot a potential problem in seconds. PRTG gave me much the same experience. Neither tool was perfect, but both did one thing very well: they gave network engineers the information they needed without making them dig for it.

Today I find myself asking a simple question:

Have we made network monitoring unnecessarily complicated?

1. The Problem With Modern Monitoring

Recently I tried to generate a bandwidth utilization report across multiple network locations using Splunk. I waited several minutes. Some locations returned data and others came back empty. All I wanted was a straightforward view of bandwidth utilization across our network.

That raises a fair question: why should something as basic as interface utilization take so much effort?

To be clear, Splunk is a powerful platform. It’s excellent at log analytics, searching operational events, and correlating information across many systems. It can handle network metrics too, including SNMP and streaming telemetry, but only when the data is collected and stored for that purpose (for example, in metrics indexes or pre-summarized data rather than raw event searches). Without that design work, a general-purpose Splunk deployment isn’t a replacement for a dedicated Network Performance Monitoring (NPM) platform.

2. Traditional Network Monitoring Still Matters

When I’m managing an enterprise network, I want immediate visibility into a few fundamentals:

• Availability: Are my routers, switches, and circuits reachable?
• Bandwidth: How much traffic is each interface carrying?
• Traffic: Who and what is generating that traffic, and where is it going? (This is where NetFlow comes in.)
• Health: Am I seeing interface errors, discards, or congestion?
• Latency and loss: Is the path between sites, or to the Internet and cloud, performing as expected? (This usually requires active probing, not just device polling.)
• Routing: Are my BGP neighbors and BFD sessions stable?
• Capacity: Am I approaching circuit or interface limits?
• History: What did utilization look like yesterday, last week, or over the past three months?

These aren’t unusual requirements. They’re the foundation of running a reliable network, and a well-designed monitoring platform should make them easy to see.

3. What Happened to SolarWinds Orion and PRTG?

The good news is that both are still around.

SolarWinds

SolarWinds Orion was one of my preferred enterprise monitoring platforms. Network Performance Monitor (NPM), NetFlow Traffic Analyzer (NTA), and Network Configuration Manager (NCM) together gave an integrated view of the network infrastructure.

It’s worth acknowledging why many organizations moved away: the 2020 supply-chain attack that compromised Orion software updates caused a lot of security teams to reassess the platform. SolarWinds has since reworked its security practices and rebranded its portfolio, including SolarWinds Observability Self-Hosted, and its core network monitoring capabilities remain relevant.

PRTG

PRTG is still a strong option. Its sensor-based model makes it straightforward to monitor device availability, interface utilization, traffic statistics, and infrastructure health. For organizations that mainly need infrastructure monitoring without deploying a large observability ecosystem, it’s worth evaluating, though you should review current licensing and pricing before committing.

4. What Else Are Network Engineers Using?

The monitoring market has expanded considerably:

The important point is that these tools don’t do the same job:

• Kentik shows which sources and destinations are consuming bandwidth, using NetFlow/IPFIX.
• ThousandEyes shows where latency or packet loss occurs between two endpoints.
• SolarWinds or PRTG show historical utilization for the physical interfaces carrying that traffic.
• Splunk correlates network events with logs from firewalls, servers, applications, and other systems.

Each gives a different perspective on the same network.

5. SNMP Is Still Relevant

There’s plenty of discussion about streaming telemetry, APIs, automation, and modern observability architectures, and all of them have value. But SNMP is still extremely useful for fundamental monitoring. With SNMPv3 and the right counters, you can collect:

• Interface traffic using 64-bit counters (ifHCInOctets / ifHCOutOctets).
• Interface errors and discards.
• Operational and administrative interface status.
• Hardware and system information.
• Device-specific performance metrics.

The basic bandwidth calculation hasn’t changed:

Bandwidth (bps)  = (Change in octets × 8) / Polling interval in seconds
Utilization (%)  = Bandwidth (bps) / Interface speed (bps) × 100

With consistent polling and a properly designed time-series database, historical utilization reporting should be straightforward, as long as counter wraps, device reboots (counter resets), and polling gaps are handled correctly.

Streaming telemetry is valuable where you need higher-frequency measurements and richer operational data. But newer technology doesn’t automatically make proven methods obsolete.

6. NetFlow: The Tool I Always Include

If SNMP is the speedometer, NetFlow is the trip log. SNMP tells me how much traffic an interface is carrying. NetFlow tells me who is sending it, where it’s going, and what it is. I’ve relied on it for most of my career, and I don’t consider a monitoring design complete without it.

Routers, switches, and firewalls summarize traffic into flow records (source and destination IP, ports, protocol, interfaces, byte and packet counts) and export them to a collector. The common formats are NetFlow v5 and v9, IPFIX (the IETF standard based on v9), and sFlow, a packet-sampling approach used by many switch vendors. Most collectors accept all of them.

What NetFlow helps me answer

• Top talkers and top applications: When a circuit hits 95%, I can see in seconds whether it’s backups, a software update, video, or something that shouldn’t be there.
• Capacity planning: Trends by application, site, or destination show which traffic is actually growing, not just that the link is getting fuller.
• Cloud and Internet traffic: How much is going to SaaS, cloud providers, or specific destinations, which helps with circuit sizing and routing decisions.
• Security and forensics: Unusual volumes, scanning behavior, DDoS traffic, or data leaving the network to unfamiliar destinations. Flow records are often the only record of a conversation after the fact.
• Troubleshooting: Confirming that traffic is taking the path you expect, and whether a policy, QoS marking, or routing change actually took effect.

Getting NetFlow right

• Export from the right places: Internet edge, WAN edge, data center core, and firewalls give the most value. You don’t need it on every access switch.
• Avoid double counting: Use ingress-only flow collection consistently, or make sure your collector correctly handles a mix of ingress and egress.
• Set the active timeout: Long-lived flows are only exported when the active timeout expires. A timeout of about 60 seconds keeps graphs accurate; long defaults on some platforms cause big flows to appear as late spikes.
• Know your sampling rate: Sampled flow (1 in N packets) reduces load on busy devices but is less precise for small flows. Make sure the collector knows the rate so it scales the numbers correctly.
• Use a consistent source interface (such as a loopback) for exports, and keep SNMP enabled so the collector can map interface indexes to real interface names and speeds.
• Plan retention: Keep detailed flows for days or weeks and summarized data for months, so you can look back when someone asks what happened last quarter.

Most of the platforms in this article support it: SolarWinds NTA, PRTG flow sensors, Kentik, LogicMonitor, and open-source options such as ntopng and ElastiFlow. The tool matters less than making sure flow data is being collected at all.

7. Monitoring Bandwidth Isn’t the Same as Understanding Traffic

There’s an important difference between interface monitoring and traffic analysis.

Suppose an organization has four 10 Gbps Internet connections, and traffic from all of them ultimately flows through a single 10 Gbps link into a data center core or firewall cluster. Each Internet connection might look healthy on its own. But when they’re all busy at the same time, that downstream 10 Gbps link becomes the bottleneck. The constraint isn’t at the Internet edge; it’s deeper inside the network, and adding more external connectivity won’t fix it.

This is where the layers work together. An NPM platform shows where utilization is approaching capacity. NetFlow shows what traffic is consuming it and where it’s coming from. Together, they give you what you need for sound architecture and capacity planning decisions.

8. Missing Data Is Also a Monitoring Problem

One thing that concerns me is a dashboard that shows inconsistent information. If ten locations are monitored and only seven report bandwidth, what happened to the other three?

• Are the devices unreachable?
• Did SNMP polling fail (credentials, ACLs, timeouts)?
• Were the interfaces never added to monitoring?
• Did a collector stop working?
• Or is the report query simply failing to retrieve the data?

A monitoring platform should clearly distinguish between:

• Zero utilization.
• Missing telemetry.
• A device or interface that is down.
• A monitoring or collection failure.

These are completely different conditions, and the monitoring system itself should alert when data goes stale, not just when a device goes down.

9. My Preferred Approach: Use the Right Tools

I don’t believe every enterprise needs a single platform responsible for every part of observability. Trying to force everything into one tool can create as much complexity as it removes. I prefer a layered approach:

• Network Performance Monitoring: A purpose-built platform for SNMP/telemetry polling, device health, interface utilization, and historical reporting.
• Network Traffic Analytics (NetFlow/IPFIX): Flow data to understand sources, destinations, applications, usage patterns, and capacity trends. In my designs, this layer is never optional.
• Network Path Monitoring: Active measurements for reachability, latency, packet loss, and path changes across WAN, Internet, and cloud.
• Log Analytics: A centralized logging platform to correlate events, investigate problems, and retain operational history.

These layers should complement each other, not compete.

10. Final Thoughts

Technology evolves, and network monitoring should evolve with it. But we shouldn’t lose sight of the fundamentals. As a network engineer, I should be able to open a dashboard and quickly answer a few simple questions:

Is my network up? How much bandwidth am I using? Where is the traffic going? Where are my bottlenecks? What changed?

If answering those questions means waiting several minutes for a report that comes back incomplete, something needs to improve. That doesn’t necessarily mean the platform is bad. It may be an implementation problem, an architectural limitation, or simply the wrong tool for the requirement.

SolarWinds and PRTG were built around these foundational needs, and they’re still relevant. Pair any of them with NetFlow, and you can answer not just how busy the network is but why. Modern observability platforms offer far more capability, but more functionality doesn’t always mean better operational visibility.

Sometimes the best monitoring solution is the one that lets a network engineer identify a problem in seconds instead of spending minutes trying to generate a report.