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

How to use the API/SWQL for Interface "additions"

OK, So we have Switch A.

Switch A is already monitored and is monitoring interfaces Eth1, eth2 and eth3. Eth4 doesnt exist yet.

Someone comes along and ADDs interface Eth4 to the switch.

After the default 30 min "rediscovery" interval, If we go to SwitchA and "list resouces" it shows a cached version, with Eth4 in the list (not selected). Its been discovered, but its not been Added to Orion/NPM for Monitoring.

It does not seem to appear as an "interface added" event in the Audit/Event tables, this only happens once its been selected for monitoring (Unless Im wrong, or we have a bug?).

So my question is

a) how do we know the device has had a new interface appear (Via the API, or in an SWQL table).

b) Where are the "Cached" results stored? the interface appears in the cached "list resouces" element on the Web Gui, but does not appear against the NodeID in the Orion.NPM.Interfaces table in SWQL.

We use an External platform and the API to track changes, and update monitored interfaces. But it can only do that by knowing if an interface has been added.

For example, our API sees an Audit event for "interface changed" and then the API takes the nodeID and does a re-discovery, selecting which interfaces we want.When we add a new interface like in the above example, because that interface is not monitored, we dont get an "interface added" event.

Any help greatly appreciated!

Find more posts tagged with

Accepted answers

mesverrum

Im fairly certain that Orion doesn't normally just go out and get lists of new interfaces. I think they only pick them up as part of discoveries or actually hitting list resources. There is a verb in the api for discoverinterfacesonnode, it could maybe help with your scenario but it only works on snmp nodes, and the data it kicks back is a bit frustrating to work with for small reasons.

In situations like yours I have set up script based automatic scheduled discoveries to target this stuff as needed.

All comments

adam.beedell

I think you need a network discovery running across those nodes - You can track monitored interfaces vs discovered interfaces that way at least. Possibly with an auto-import to round it out.

I think they've added some functions recently to make taking care of interface reconfiguration easier, personally I've not got those patches in live yet though so not sure if it helps your scenario.

This sort of this is certainly a faff and i've not got a good solution in my live environment as of yet, but the way above was my best option last I looked into it.

ashleyh

HI Adam! Thanks for the Reply.

Yeah unfortunatly due to the complexity, size (2800 devices), over 250,000 interfaces, and differing standards/requirements, the auto discovery option in built isnt powerful enough for our use case. So we use the API to perform discoveries, run our own criteria and regex matches, and then import the results using the API. generally, this can work well, however we need a way of telling the API when an interface is added which is the bit we are missing at the moment! We can watch the "events" on Orion for Interfaces changes and removal and up/down events, but not for "additions" to kit that are not yet re-discovered by solarwinds,..despite them being picked up in the 30 min rediscovery cache interval!

adam.beedell

I think without a discovery you're back to having to make something custom - I don't think the info you're after is in the DB otherwise.

I've got a similarly sized environment and the idea of discovering everything sounds painful, but if they're in SLW already you've definitely got all the details it takes. Note you don't need to import anything from a discovery, just use it to discover what you've already got and then compare the Orion.NPM.DiscoveredInterfaces table with the interfaces table with a few joins to identify where stuff is missing

I suppose you could write something to script discoveries based on some custom data too, or even just use the list of every IP in use to form the IP list to scan.

Might even be easier to cut straight to policy and just ask that people who muck with interfaces put the name of the box somewhere so you can action based off those names.

mesverrum

I've gone round and round a few times trying to find where the cached resource data lives, doesn't seem like they are in the db unless they have some completely misdirecting table name.

ashleyh

Agreed! This is making the job really hard.

If I create a new interface like "loopback 10" on a Cisco switch, would you expect to see an "interface added" event when its passed the rediscovery interval and shows it available on "list resouces" or only "interface added" event when i actually 'tick' it for monitoring?

mesverrum

In situations like yours I have set up script based automatic scheduled discoveries to target this stuff as needed.

ashleyh

Thanks! Looks like some expensive discovery jobs we need to run every day. We have a massive amount of change of infrastructure links in the environment, so doing this for every box every day gets quite expensive to then do compare's with our criteria for each and every device. But at least I now understand the battle