How do I find the source of a USM entry?

Document ID : KB000034726
Last Modified Date : 14/02/2018
Show Technical Document Details

Summary:

There are times when we need to specifically locate why a device is showing up in USM.  For example,

  • Duplicate entries in USM and we need to find the source of the duplicate
  • Customer deleted an entry from the database and it keeps reappearing

 

Instructions:

Search for the invalid node using SQL queries

First, we need to find the cs_id of the items we are investigating.

SELECT * FROM CM_COMPUTER_SYSTEM WHERE ip = '<ipaddress>';
SELECT * FROM CM_COMPUTER_SYSTEM WHERE NAME LIKE = '<hub/robot name>';



Take the cs_id from that record and run the following query:

SELECT * FROM CM_DEVICE WHERE cs_id = <cs_id>;



This will show all of the perspectives that this device is being discovered by.  Some will be obvious, like vmware or discovery_agent.  The more difficult ones are where we show probe_name of "niscache" or an "unknown" entry and those are the ones we will focus on for this article.

When you see a probe_name entry that simply reads "niscache" it means that it's being detected by a TNT2 style probe. TNT2 probes are probes that place their dev, met and ci files into the niscache folder on a robot.  Notice that the entries that show "niscache" also have a dev_src_id field populated.  This field is a link back to the robot that is monitoring the device.

So the next query will be as follows:

SELECT * FROM CM_DEVICE WHERE dev_id = '<dev_src_id>';


Now we have the name of the robot that this probe is installed on that is monitoring this device.  This is sometimes useful for jogging somone's memory, but it doesn't give us very specific information about which probe is actually doing it, so it's not always helpful.  So let's back up for a moment and rerun the previous query:

SELECT * FROM CM_DEVICE WHERE cs_id = <cs_id>;


Now we're going to walk one more step up the CM tables and look at the configuration item (CI) that is causing this entry to be populated.  A CI is corresponds to a profile configuration in a probe.  Note the actual dev_id of the record and run the following query:

SELECT * FROM CM_CONFIGURATION_ITEM WHERE dev_id = '<dev_id>';


This will typically give you quite a bit more information.  For example, net_connect will show a ci_name of "ping". Sometimes this will be enough information to make a determination.  If not, we can dig a little more.  The next query will not yield us any more information, but is a necessary hop to get to the S_QOS_DATA table.  Note any ci_id from the previous query and run the following query:

SELECT * FROM CM_CONFIGURATION_ITEM_METRIC WHERE ci_id = '<ci_id>';


If you don't get any results from this query, it's possible you may need to pick a different ci_id.  Not every CI will have a metric.

It's not unusual to have multiple records return from this, so pick a ci_metric_id from this list and run the following query:

SELECT * FROM S_QOS_DATA WHERE ci_metric_id = '<ci_metric_id>';


With this query result you now have the robot and probe that is monitoring this node/machine/device.

Additional Info:

If you didn't get a result, then there's two possibilities:

  1. You have a ci_metric_id mismatch
  2. The device has no associated QOS data.  This can be a possibility where you have a probe configured only to alarm.  Unfortunately, if this is the case, chances are you won't be able to make a specific determination beyond the profile information from the CI tables.

See the following article for more explanation on niscache: TEC000005313

See the following article for deleting devices from inventory: TEC000005096