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

Report to show missing elements?

Hello,

I'm no SQL guru by far. I've been scratching my head trying to figure out if there's a way to write a report to show "missing elements". Here's an example:

Every so often I come across servers that have had an additional hard disk added (virtuals), or servers that were added to Orion but someone neglected to select the NICs, volumes, CPU/memory checkboxes. I do have a report to show me new nodes added within the last week, and I audit those, but it doesn't catch existing systems where something has changed. A lot of times other admins virtualize severs and forget to update the volumes/NICs when their IDs change. With 25 people adding nodes, it becomes cumbersome to keep reminding people and I don't want to be the only person updating/adding nodes with the amount of change in our environment.

So, is it possible to find nodes where there are identified (discovered) elements, but they are NOT selected for monitoring? I have tried using various NULL conditions but nothing is returned.

Example below - i recently came across this node where absolutely nothing was selected, and it was set for regular SNMP monitoring..

Thanks for any insight!

Find more posts tagged with

Accepted answers

All comments

cdoyle

Hi LGentile,

The reports wouldn't be able to help you with this requirement, as they will only be able to pull data that already exists in the database for you. When you run a List Resources against a device, it will pull that information back via SNMP from that device - so this is fresh data pulled from the devce every time you run it.

What you might find useful though, would be the Scheduled Discovery feature - this allows you to go out and run a Discovery against whichever IP ranges you choose on a scheduled basis. The results of the discovery will update you and let you know if the discovery has found new nodes, and will also let you know if its found new Interfaces and Volumes on existing nodes.

HTH!
Caroline

LGentile

I suppose this makes sense, you can't report on what doesn't exist. My main worry is that sometimes the C: or drive details change (i assume this is from someone extending the drives, changing them, re-ordering them) - they are almost always virtual. So, you'll have a server out there that 'used' to have a C: drive listed, but it shows up as a ? and then a new serial # for a C: drive exists but it wasn't automatically selected.

I can set up some discoveries, but I don't want them to be network-based. We have a fairly 'good' control over what machines get put on the wire (SMS discovers them and adds them to our DB). I will try to set up some interface/volume discoveries. I do use some reports to show nodes that require attention (i.e. volume changes). I will let you know if this works out for me.

Thanks!

cgregors

I ran into the same concern. My solution (that I can't share the code for at this time) works like this:

Run a re-discovery script written in php to enumerate the resources on each node monitoried in Orion.
1. include filesystems
2. include interfaces
3. include cpu and mem
Store the data in a custom table in the Orion database
Write a report to compare the discovered resources against the monitored resources and output the differences

The process becomes time consuming when dealing with large switches with 200+ interfaces. They show up as not monitored in my difference report. The solution to this will be for me to tag discovered items in my custom table with an identifier something like "do_not_monitor" so they can be excluded from the difference report.

Chris