Idea Details

UMP Missing Metrics

Last activity 11-03-2015 11:57 AM
David LeDeaux's profile image
09-16-2015 06:52 PM

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 typically results in a support call, where the standard procedure is to run a SQL UPDATE query to set the ci_metric_id to NULL in S_QOS_DATA.  After that, the data_engine is restarted and data_engine updates the value upon receiving the next matching QOS message.


We have a probe which is already responsible for updating S_QOS_DATA on incoming data.


qos_processor currently subscribes to QOS_MESSAGE messages and updates origin values in the S_QOS_DATA table to ensure that robots that have moved from one hub to another are up to date with respect to origins.


Because qos_processor already listens to the same messages that contain a metric ID and already updates the table that contains the metric ID, it would add minimal overhead to ask qos_processor to touch the ci_metric_id field as well.


11-03-2015 11:57 AM

One of the reoccurring issues we see in Support is the mismatch of data that David mentioned.

Using existing architecture (qos_processor) to correct this functionality is an excellent idea.