“No metrics available” for one or more hosts in USM
- May consist of several factors
1- Check the integrity of the data
Check that the “CI_METRIC_ID” column values in the S_QOS_DATA table are present in the “CM_CONFIGURATION_ITEM_METRIC” table.
If the metric IDs (“CI_METRIC_ID CI_METRIC_ID” column in the “S_QOS_DATA” table) do NOT have a corresponding row in the “CM_CONFIGURATION_ITEM_METRIC” table, they will not display in USM.
In this example, we identified the following hosts as not having metrics available in USM: walsh04-HOST1, walsh04-HOST2, and walsh04-HOST3. Note: In the queries below, pay attention to the Target values.
Query 1 -
SELECT SOURCE, TARGET, CI_METRIC_ID FROM S_QOS_DATA WHERE SOURCE IN /** enter your source names here **/ ('walsh04-E15600','walsh04-E15601','walsh04-e15603') AND CI_METRIC_ID NOT IN (SELECT CI_METRIC_ID FROM CM_CONFIGURATION_ITEM_METRIC);
The CI_METRIC_ID from S_QOS_DATA and the one from CM_CONFIGURATION_ITEM must be the same. If there are any rows returned from the query above, the data will need to be corrected.
First, validate whether data is being saved to a new location.
Query 2 -
SELECT SOURCE, TARGET, CI_METRIC_ID FROM S_QOS_DATA WHERE SOURCE IN ('walsh04-E15600','walsh04-E15601','walsh04-e15603') AND CI_METRIC_ID IN (SELECT CI_METRIC_ID FROM CM_CONFIGURATION_ITEM_METRIC);
Pay attention to the “TARGET” values from “Query 1” and “Query 2”. Note if any are the same or similar, for example an interface name changed from ‘Fa0’ to ‘Fa0(FastEthernet0)’.
If the target name had changed, look to merge the QOS data by following this technical document: kb000072808 .
2- Update the S_QOS_DATA table
If the “Target” name change is not related, then to correct the data for a single device, run an UPDATE statement (replace 'walsh04-E15601' below).
UPDATE S_QOS_DATA SET CI_METRIC_ID = NULL WHERE SOURCE LIKE = 'walsh04-E15601';
3- Delete the niscache on the robot where the QoS is coming from and then restart that robot.Steps to delete the niscache
Clearing the niscache, using the Infrastructure Manager console
Find the robot
Open the Probe utility, by selecting the “controller” probe and CTRL-P
Enable Expert Mode:
Clearing the niscache using the Web Admin Console (alternative to using the IM console steps above).
Clearing the niscache through the filesystem (alternative to using IM console steps above).
Navigate to the Nimsoft install folder
Delete all files under: <Nimsoft Home>\niscache\
4- Deactivate “discovery_server” and the “nis_server” using the IM or Web Admin Console.
5- Restart these probes on the primary hub:
Note: the discovery_server and nis_server are responsible for cm_configuration_item_metric. That will force the CI (configuration item) to be put in cm_configuration_item_metric table.
6- Check the “CM_CONFIGURATION_ITEM_METRIC”
table to see if it is now present, then check the “Metrics” or “Interface Metrics” in the USM/USM Interface Tab view once again to see if it still shows "No Metrics Available".
You can use one source/device/robot as a test, then restart the data_engine. This will take some time but the mappings should be corrected after this - but please try it on a single robot first to be sure.
More complete instructions are detailed below:
You may want to try a FULL reset of discovery first to clean up entries/stale data/origins etc.
You can reset discovery in 7.x as per the available Article in the Knowledge base but you may still have some leftover nodes showing no metrics. Sometimes the ci_metric_ids from an initial / previous discovery run end up mismatched due to a subsequent discovery after changes have been implemented in the environment, e.g., robot/device name was changed or probe profile names changed etc., so as a result they have to be reset in the tables
Therefore to fix the issue of "No metrics available"
Drag and drop the niscache cleaner probe to the given Robot(s).
The file is attached to this article.
Restart the Robot Watcher Service (On Linux issue the command ./niminit stop to stop the Robot and then ./niminit start to start the Robot again, then check to make sure the robot is running.ps -ef | grep nim
The "controller", "hdb" and "spooler" should show up.
update and set the ci_metric id to null for the given system, for example:
update s_qos_data set ci_metric_id = NULL where robot = '<hostname>'
Restart the data_engine.
Restart the discovery_server to pick up the new niscache elements
Check for the metrics table information using a similar query such as the one below:
select * from cm_configuration_item_metric where ci_metric_id in (select ci_metric_id from s_qos_data where source like '%abc.def1%')
select * from cm_computer_system where name like '%abc.def1%'
The backend database should then be newly populated but it may take some time. Note that in some cases with large environments it can take over 8 hours as the process is currently sequential (FIFO).
When discovery is finished, you can actively check the discovery_server log and search for the IP/hostname.
Then check the UMP USM node and the metrics should be retrieved.
Note that the above assumes that all correlation settings in the discovery_server are set to true (enabled), e.g., vm_id and robot_device_id, etc., and that the java min and max memory settings are 2048 and 4096 respectively so the discovery_server can handle the load.
Other/Misc (origin cleanup)
select * from cm_computer_system where origin = '<old_bad_origin>'
update cm_computer_system set origin ='<new_origin>' where origin = '<old_bad_origin>'
select * from s_qos_data where origin = '<old_bad_origin>'
update s_qos_data set origin='<new_origin>' where origin = '<old_bad_origin>'
keywords: No metrics available found USM missing device system window intermittently discovery monitoring devices systems robots views display displays view