Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Per second interface chart

I had a client asking me if he can have a chart on his dashboard (NPM), which will show bandwidth utilization for an interface per second or at least every 5 seconds! Much like a live monitoring chart.

I didn't find any better option than 1 minute, but I'm fairly new to SW so I would like another opinion on the matter!

Thanks

Find more posts tagged with

Accepted answers

rschroeder

Before I had the latest version of NPM, I relied exclusively on the Engineer's Toolset for this. I used the Bandwidth Gauges and polled the desired switches or routers, then selected the appropriate interfaces, and chose to display the Historical Graph of each one's traffic.

However, that's a LOT of polling to hit a big number of devices/interfaces with per-second polling. Instead I set it for ten seconds, and the graphs work perfectly well.

In fact, you can use this information to compare NPM's 120-second default polling of interfaces and get an idea just how far off NPM's polling is when it doesn't poll frequently enough. Yes, NPM gives great stats and trends, but the ACTUAL bandwidth consumed may be 30% more when polled every ten seconds as opposed to every 120 seconds.

In this way I discovered some interfaces and WAN links that were peaking and clipping--their utilization showed maxed out with flat lines in the Bandwidth Gauge Historical graphs, but did NOT show the same in NPM's 120-second polled graphs.

Per-second polling through PerfStack is something I'm looking into. I think it makes sense for a brief review of traffic in real time, but I'd ask Cisco if leaving it going for long term is acceptable. It may be possible that extended rapid polling may have an negative impact on switch/router CPU or memory resources. And although snmp uses relatively little bandwidth, real-time polling does increases port bandwidth utilization. If you're circuit/port is very close to being fully utilized, and if you haven't deprioritized snmp polling with QoS, your rapid polling could theoretically cause problems.

Test it, but don't promise the customers anything until you've verified it doesn't cause problems--both for your circuits & routers or switches, and for NPM.

All comments

ecklerwr1

It would be impossible for NPM to scale if you were trying to poll that often. For something like that you'd almost need a realtime DPI packet capture like tool. Also depending on the speed of your interfaces this might even require special hardware. This would also be quite a bit much more expensive of an option. Anyhow... that's how I see it.

mesverrum

NPM doesn't do per second, since everything polled gets added to the DB it would very quickly become unworkably large. There is a tool from Solarwinds called the engineers toolkit which is more geared toward real time monitoring, and can integrate . Depending on your hardware many devices only actually update their SNMP counters every 10 seconds or so but that's just going to be a limitation of whatever hardware you have.

Network Engineer’s Toolset - Network Tools | SolarWinds

aLTeReGo

This is already possible today in NPM 12.2 using PerfStack.

PerfStack 2.0 - Real-Time Polling

mesverrum

Oh nice, should have paid more attention to the release notes, I haven't actually had any clients deploy 12.2 into prod yet so i guess I missed that. Neat feature for sure.

rschroeder

However, that's a LOT of polling to hit a big number of devices/interfaces with per-second polling. Instead I set it for ten seconds, and the graphs work perfectly well.

Test it, but don't promise the customers anything until you've verified it doesn't cause problems--both for your circuits & routers or switches, and for NPM.