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

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

Search for the invalid node using SQL queries

First 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 discovery 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 are 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 it 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 there are no results from this query, it's possible we might 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.

If you did not get a result, then there are 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.

niscache - what it is, what it does

https://comm.support.ca.com/kb/niscache-what-it-is-what-it-does/kb000034717


Removing devices from usm in UIM 8.2 and later

https://comm.support.ca.com/kb/removing-devices-from-usm-in-uim-82-and-later/kb000033702