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

Any reason not to monitor a component?

I had a conversation with a co-worker today, discussing what we should our shouldn't monitor when setting up a node in SAM. His question was, "Why not monitor everything? Why exclude anything from monitoring? Since Alerting is a separate function/feature, which is controlled separately (and what wakes us up at night if Orion decides something has gone wrong), we want to carefully consider what we Alert on, but shouldn't we be monitoring everything?"

I couldn't come up with an answer. I have seen that, for example, on Windows servers, by default CD-ROM drives aren't monitored nor floppy drives. Why not? What harm does it do to monitor them?

Find more posts tagged with

Accepted answers

All comments

tomasv

There could be constraint your number of components per your licenses and scalability (~8-10k component monitors per polling engine - see http://www.solarwinds.com/documentation/Orion/docs/ScalabilityEngineGuidelines.pdf )

cdowning

I was thinking the same thing... there is a limit on how much a polling engine can handle, so you could overload one if you monitored too much. You can add more, but that's more money with no real benefit.

Also, it's going to increase database size which could affect response time, database size on disk, database maintenance, etc.

And, the more you monitor, the more traffic comes across the network. Probably not a major consideration, but still...

And, if you aren't going to use the information, why waste resources to collect it?

elhannaford

I hadn't thought of licensing constraints.

I hate licensing.

I had considered database size, but our environment isn't big enough to challenge even a moderate SQL Server.

We're using mostly SNMP for our monitoring, so I'm not too concerned about network traffic. Extra components aren't going to add that much to an SNMP request.

In answer to the use question, my co-worker responded something like this, "Sure, you don't expect certain things, like the loopback NIC, to change or even get used; that's why you don't bother alerting on it. However, if a server goes south, and you look at the node page and see oddball behavior on a component that shouldn't be changing or even getting used, that can give you the lead you need to figure out what's going wrong."

If not for licensing, I'd agree with him.