CI_METRIC_ID column in S_QOS_DATA table not updated to new CI_METRIC

Products

DX Unified Infrastructure Management (Nimsoft / UIM) CA Unified Infrastructure Management On-Premise (Nimsoft / UIM) CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

Metrics fail to display correctly in the Operator Console (OC) after configuration changes, such as modifying an origin or moving a robot. This occurs when the CI_METRIC_ID column in the S_QOS_DATA database table does not update to match new discovery values. If these IDs mismatch, the data_engine cannot map incoming QoS data to the proper inventory items.
If any changes to discovered servers are made that would change the CI_METRIC_ID, e.g., origin, the CI_METRIC_ID needs to be updated in the S_QOS_DATA table.
If it does not update, there will be a mismatch and the servers will not show data correctly.
How do I update the CI_METRIC_ID column on the S_QOS_DATA table after a change to the DB?
Due to a mismatch of CI_METRIC_ID's, metrics are not showing correctly in OC.
How do I have the data_engine reset them?

Potential symptoms
Metrics are missing in Operator Console Inventory for specific robots or probes
Origin changes are not reflected in the QoS data tables
Reports show no data for newly discovered or migrated devices

Environment

DX UIM 20.4.* / 23.4.*
data_engine
discovery_server
robot (niscache)

Cause

Possible Causes

Origin Migrations: Stale references in S_QOS_DATA after origin name changes.
Cloned Robots: Duplicate dev_id or CI_METRIC_ID collisions caused by cloning VMs without resetting the UIM robot ID/deleting the niscache.
Blacklisting: The discovery_server intentionally skips processing inventory if the device ID is present in CM_BLACKLIST_DEVICE.
Queue Backlogs: Communication failures in ROBOT_NIS_CACHE prevent backend updates.

Resolution

Find CI_METRIC_ID mismatches between S_QOS_DATA and the CM_* tables (read through entire instructions before trying). Run the following SQL query:

select distinct c.dev_id,r.address nimbus_address,r.ip robotip,r.domain,
r.hub hubname,s.name robotname,cg.name groupname,s.nimbus_type,
d.source source,d.origin,s.os_type os_major,s.os_name os_minor,s.os_version,
s.os_description,d.ci_metric_id,d.qos,d.target,d.r_table,d.probe,d.table_id,
d.samplevalue value from S_QOS_DATA d
left join CM_CONFIGURATION_ITEM_METRIC m
on m.ci_metric_id=d.ci_metric_id
      left join CM_CONFIGURATION_ITEM I on i.ci_id = m.ci_id
      left join CM_DEVICE c on c.dev_id = i.dev_id
      left join CM_COMPUTER_SYSTEM s on c.cs_id = s.cs_id
      left join CM_GROUP_MEMBER cm on c.cs_id = cm.cs_id
      left join CM_GROUP cg on cg.grp_id = cm.grp_id
      left join CM_NIMBUS_ROBOT r on s.ip = r.ip and r.origin = d.origin
      where d.probe = 'cdm'
      -- and d.robot = <robot>
      -- and d.origin = <origin>

Using the additional WHERE clauses in that query will narrow the results down to a single robot or origin. This will give you a list of all the QoS data points for a robot/origin.
Scan the results for improper origin names, mismatched robot names, or bad CI_METRIC_ID’s (you can verify CI_METRIC_ID’s against a robot’s niscache folder by checking names of any files that end in .met against the CI_METRIC_ID listed in a given row).
If the CI_METRIC_ID is incorrect in the robot's niscache, the niscache folder in the Nimsoft root directory will need to be deleted and the robot will need to be restarted to repopulate the data.
If any of these items are incorrect, it's likely that the robot has the wrong CI_METRIC_ID’s in S_QOS_DATA. It is possible to force a reset of these ID’s by taking the following steps:
1. Take a backup of your database as a precaution
2. Deactivate the data_engine
3. Issue the query: UPDATE S_QOS_DATA SET CI_METRIC_ID = NULL WHERE ROBOT = ‘<robotname>’ AND PROBE = ‘cdm’
4. Activate the data_engine to force repopulation of the CI_METRIC_ID column.

Additional Information

Potential causes of ci_metric_id not updating in UIM

1. Configuration & Origin Changes

Origin Updates or Migrations: Modifying the origin for a robot, hub, or probe in the configuration without clearing old references causes S_QOS_DATA to retain stale metric associations.

Moving Robots or Probes Across Hubs: Moving a robot to a new hub or moving a probe (e.g., cdm, net_connect) to a different robot generates new device and metric IDs. If the previous IDs persist in S_QOS_DATA, the table won't automatically map to the new metric ID.

2. Corrupted or Stale Local Cache (niscache) Stale Robot Cache
The robot stores local inventory mapping files (.met) in its niscache directory. If these files contain outdated dev_id or metric_id information, the robot will continue advertising outdated metric signatures.

VM Cloning/Duplication: Cloning a virtual machine that already has a UIM robot installed copies the existing niscache. This leads to duplicate dev_id and CI_METRIC_ID collisions across multiple hosts.

3. Queue and Communication Failures
Missing or Misconfigured Hub Queues: Higher-version UIM setups (e.g., UIM 23.4+) require specific message queues like ROBOT_NIS_CACHE on hubs. If these queues or standard discovery queues (PROBE_DISCOVERY) are missing or attached improperly, metric registration updates won't reach the backend processing probes.

Queue Backlogs in Probes: A backup in qos_processor or discovery_server queues prevents inventory and metric mapping updates from reaching the database.

4. Database & Processing Bottlenecks
data_engine stalling: The data_engine probe is responsible for mapping QoS messages to inventory items. If data_engine crashes, stalls, or fails to re-read updated cache tables, it won't recalculate and populate CI_METRIC_ID.

Missing Counterpart in Inventory (CM_* Tables): If the device discovery process failed or the item was removed from Inventory, there is no corresponding ci_metric_id in CM_CONFIGURATION_ITEM_METRIC. S_QOS_DATA cannot link to an ID that doesn't exist in NIS inventory.

5. Blacklisting

Blacklisting is also a common, valid cause for CI_METRIC_ID failing to populate or update in DX UIM.

When a device, robot, or probe target is blacklisted, discovery_server intentionally skips processing inventory data for it. Because discovery updates are blocked, the CM_* tables (specifically CM_CONFIGURATION_ITEM_METRIC) never receive new or updated metric entries. Consequently, data_engine cannot map incoming QoS data in S_QOS_DATA to a valid CI_METRIC_ID, leaving the column NULL or linked to an outdated ID.

How Blacklisting Happens
Prevent Rediscovery Option: When deleting a device or robot from Operator Console (OC), checking the "Prevent rediscovery" box adds its device ID or IP to the CM_BLACKLIST_* tables.

IP/Device ID Collisions: If a robot or VM is cloned or reassigned an IP previously used by a blacklisted host, discovery_server automatically flags and blocks the new device, logging entries such as Skipping excluded DeviceId.

How to Check and Fix Blacklisting
Verify Blacklisting in the Database:
Check if the affected device ID exists in the blacklist tables:

SELECT * FROM CM_BLACKLIST_DEVICE WHERE DEV_ID = '<device_id>';

Unblacklist the Device
Run the unblacklist_devices callback on the discovery_server probe (or clear the CM_BLACKLIST_* entries).

Clear Cache & Force Rediscovery:

Run the _nis_cache_clean and _reset_device_id_and_restart callbacks using the probe utility in expert mode on the target robot.

Run resync_device_cache on discovery_server.