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.