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

Additional load for monitoring access switches

Hello,

I wanted to ask the opinion of the forum about using NPM to monitor "user facing" Ethernet ports on Access layer switches.

It would be handy to know if a port hasn't been used for a while, but I'm concerned that monitoring hundreds of additional interfaces is going to add load to the Orion server.

Bearing in mind that NPM goes to the device once every 10 minutes anyway to get it's status, does it really add a lot of overhead to collect the interface statuses also?

Do other users collect stats for all interfaces on the network?

Thanks

~sm

Find more posts tagged with

Accepted answers

seigniory

From my experience, even when doing a full snmp-walk on a device with 11k+ OIDs (snmp-informant), the device's CPU never deviates from baseline by more than 1-2%. As long as your poller can handle the additional datapoints, (and SNMP polling is properly implemented on the host to control process usage) I say go for it.

All comments

lchance

MY OPINION

We have the ‘unlimited’ SLX license but you definitely have to balance that out with hardware on Orion and the hardware for SQL. We use two servers – Orion and Orion’s SQL.

At first I was reluctant to monitor every switch port but after Orion offered a ‘unpluggable’ feature for port monitoring it helped make sense for something like you said “…to know if a port hasn't been used for a while”.

But having hundreds of ports can become a maintenance nightmare. We only have 2,800 being monitored and the polling and data collections have been fine with no major issues. But I know some folks have ten times that number and they have to have multiple Orion’s – that is, extra Polling Engines to pick up and distribute the load.

ecornwell

Hi sm,

We monitor all our switch ports. We were using MRTG before moving to NPM and it monitored all the ports and we enjoyed being able to see who is using what kind of traffic. We've got nearly 20k interfaces that we monitor. We've thought about slimming it down, especially at some of our remote sites. It seems that just about the time we do, we run into something that we can use the data to help troubleshoot or prove a case for something. I'm happy we do it but it puts a strain on the SQL server.

Hope that helps...
Eric

seigniory

SimonMorris

Thanks for your opinions.

~sm

DirtySouth

We currently monitor a little over 1400 interfaces and 3633 total elements. I only monitor the uplinks on access switches. We've never really had a need to monitor all of the individual interfaces. If there is a problem, I'll fire up Engineer's Toolset and watch individual ports or just login to the switch and look for issues. Granted, we can't see historical. If you have enough licenses and the right hard-ware for polling and DB, I'd say go for it, but it does add alot more management to Orion.

ecornwell

Thanks for your opinions.

~sm

Thank you for the rating!