We have deployed a robot to a server and configured the cdm probe, the same server is also being monitored by the vmware probe which is running on a separate robot.
In this scenario two device entries are displayed in the USM, one vmware entry containing the vmware data. The other is the robot entry containing the cdm data.
After several weeks, a new file system was added to the server. All other file systems display under the robot however, the newly added file system is displayed under the vmware probe entry.
Checking the SLM or PRD portlets in the UMP, show all data is displayed under the same device entry using the FQDN. The robot entry has the server short name in the USM and the vmware entry also has the server short name (and the same primary ipv4 address) but, also displays the FQDN and other IP Addresses. Reviewed the hosts file on the server where the robot (cdm) is running (C:\Windows\System32\drivers\etc) - The shortname, IP and FQDN are present.
More information on Device Correlation, can be found here: Device Correlation Configuration - https://docops.ca.com/ca-unified-infrastructure-management-probes/ga/en/alphabetical-probe-articles/discovery_server-discovery-server/device-correlation-configuration
- UIM v8.51
- Robot v7.80
- cdm v6.30
- vmware v6.87
- discovery_server v8.51
- discovery_agent v8.51
There is an underlying correlation issue which has caused duplicate entries for the vmware / robot entries and this issue is a symptom of the correlation problem.
1. Go to the robot in question where the cdm probe is running. Open the cdm probe in Raw Configure -> Under the set up section will be a key called: "allow_remote_disk_info" by default this should be set to "yes". Change the value to no: "allow_remote_disk_info = no" and save the changes.
- This key, when set to "no" in cdm, forces the mounted filesystems to receive the same dev_id as the robot itself, which will ensure that the filesystems monitored by CDM will be forced to correlate with the robot and not the vmware probe entry.
2. On the robot where the cdm probe is running, select the controller probe from IM, and hit Ctrl P to open the Probe Utility. Within the PU window, select the Options icon and enable (tick) "Expert Mode". Select the "_nis_cache_clean" from the Probe commandset and hit play. After the command has run, restart the robot.
3. Go to the database and run the following query for the device IP. Take a note of the cs_key values for the vmware and robot entries, as it will be used in the next step.
SELECT name,ip,origin,cs_key FROM CM_COMPUTER_SYSTEM WHERE ip = '<ip>';
4. Go back to IM and select the primary hub robot -> select the discovery_server probe, and hit Ctrl P to open the Probe Utility. Select the "remove_master_devices_by_cskeys" from the Probe commandset. One by one, enter the two cskeys and press the play button. After this, restart the discovery_server probe.
- We expect only one device entry to be recreated, displaying both cdm and vmware probe data.
**NOTE: After following the above procedure, if the USM only returns one entry as expected but the device now shows "No Metrics" under the details tab and/or the file system information is not complete, please follow the below steps**
1. Deactivate data_engine probe -> Open the data_engine raw config and add the following key/value: update_metric_id = yes
- The update_metric_id key instructs the data_engine to update the metric_id when it is changed. By default, the key is set to no, or not present in the configuration.
2. Activate data_engine probe.
3. Restart the robot in question.
4. Restart discovery_server probe on Primary hub
- Wait for roughly 15-30 minutes and the remaining metrics should now show as expected.