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.


Comments

11-03-2015 11:57 AM

FANTASTIC idea.
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.