- changes in the UIM monitoring environment
If the device data is from the snmpcollector probe, you may have to force a rediscovery to get the probe to start collecting the metrics/data again.
"Run Vendor Certification Test" for the device(s), and see if data is being returned and then execute the "Query discovery server" option from the Discovery node of the snmpcollector probe configuration page to force the probe to rediscover the configured devices.
Also open the data_engine probe using Raw Configure and make sure that it has this setting:
...and that it is set to yes, then cold start (Deactivate-Activate), the data_engine probe.
Wait until another poll/interval completes and check USM metric data again.
It is not unusual for metric IDs for probe profiles to change on a robot. This causes numerous issues for correlation within USM due to a mismatched ci_metric_id between S_QOS_DATA and CM_CONFIGURATION_ITEM_METRIC.
This setting automatically synchronizes the data between S_QOS_DATA and the CI_ tables. The update_metric_id setting instructs data_engine to update metric_id when it is changed. The S_QOS_DATA "ci_metric_id" column can become outdated and can cause data to no longer be displayed in USM; this setting helps address this issue.
By default, the key is set to no, or not present in the data_engine configuration until data_engine v9.02 or higher.
Every metric is stored in a table called S_QOS_DATA which acts like a metadata index, with a corresponding value called "ci_metric_id" which is used by USM (through a relatively complex series of JOIN queries) to determine which metrics belong with which devices.
The ci_metric_id is generated by the probe/robots when a metric is enabled and is sent as part of the header for every QOS Metric that is transmitted across the message bus.There are a few things that can cause this ci_metric_id to change but for the most part, a ci_metric_id is a non-changing identifier.
One of the things that CAN cause the ci_metric_id to change is making certain changes to a profile - for example, changing from IP to hostname or vice versa. Renaming a robot is another.
When the ci_metric_id changes on a metric this can cause a break in the chain of JOIN queries that allow USM to display the metric. So we need to update S_QOS_DATA to ensure the ci_metric_id field is changed to match the new ID that is calculated at the probe/robot level. This is not very common, as mentioned, but one fairly common cause of it is the snmpcollector probe as many customers find they have to experiment with different profiles/settings when they're in the process of learning the probe.
By default, data_engine will not change the ci_metric_id when it changes on the robots; its a design nuance that existed for a very long time, however, and rather than just outright change the behavior, the development team decided to add the update_metric_id config key, so customers would not be caught unaware by changes being made to the database that they didn't expect to be made.
However, this has no impact on any metrics for which the ci_metric_id already matches the robot/probe metric ID. It only impacts metrics where there is a mismatch - and by definition, if a metric has a mismatch, that means it's not being displayed in USM properly, and fixing the mismatch will cause the data to be displayed. So in other words, there is no negative impact expected, and only a positive one - metrics which were not showing before will now be displayed (and this may even happen for metrics you didn't even know were missing.)