
We run several network discovery jobs daily on our network to find any new nodes that have been added to the network and daily we then looked at the discovery results to either add the new nodes or ignore them. We also used the daily discoveries to find any new interfaces or disks on the nodes. But since we added a second polling engine we have had nothing but problems with the discovery results and they are very unusable. All of our discovery jobs run on poller1 but since some of the nodes are now on poller2 the discovery job always sees those nodes on poller2 as new nodes and they show up in the discovery results. Also, since the nodes are on poller2 they do not show up as changed when a new interface is added to the nodes.
We have had to do a couple of things to address this issue since calls to customer service have not resolved our issue.
We created two new discovery jobs, one running on each polling engine with a list of ipaddresses to discovery to look for changes on existing nodes. We then setup this query to run daily on our sql server to update the list of ipaddresses for the discovery jobs to look at. We can now see when a new interface is added to any of our existing nodes.
Delete from DiscoveryProfileIPBulk
Insert INTO DiscoveryProfileIPBulk (ProfileID, Host) SELECT '25',IP_Address FROM Nodes WHERE EngineID = 3
Insert INTO DiscoveryProfileIPBulk (ProfileID, Host) SELECT '26',IP_Address FROM Nodes WHERE EngineID = 1
We also needed to tackle how to see if a node is new or if it is just a discovered node that is on poller2. We created a simple report that uses this query to show all nodes that are not ignored where the ipaddress does not exist in the nodes table.
select discoverynodes.name, discoverynodes.machinetype, discoverynodes.primaryaddress, discoverynodes.snmpdescription, discoverynodes.snmplocation from discoverynodes where discoverynodes.primaryaddress not in (select nodes.ip_address from nodes) and discoverynodes.ignorednodeid is NULL order by discoverynodes.machinetype
It is still quite a manual process to look at the report and decide if we want to import the nodes, ignore the node, or take no action on the node. Anyways, thought this might be interesting for others to see and hopefully Solarwinds will eventually improve the Discovery process so it can see if a discovered node is being managed by any polling engines instead of simply looking at the polling engine that is performing the discovery.
NOTE: I am not a sql query expert so I am sure there are better ways to run this but it seems to work ok for us so far.
Thanks for posting this dregier. I would like to hear from SolarWinds on this please.
Are the issues that dregier is experiencing "normal" behavior for the Discovery process?
What changes or enhancements is SW looking at in the lab right now that may address this problem?
Solarwinds, Please provide some immediate aid in correcting the shortcomings of the discovery engine. Surely, there are some hotfixes as this is a long lived issue.
Thanks
I'm checking with development to see if they are aware of the issue. I was not aware of it before this post so I'll give y'all an update when I have more details.
Mav
Could this be why we are seeing duplicate nodes created on IPs that exist as interfaces on existing nodes? We recently upgraded some modules at least.
We're running Orion Core 2011.2.1, IPAM 2.0.1, NPM 10.2.1, NTA 3.8.0, Storage 5.0.1, IVIM 1.2.0