This is often caused by some issue with the S_QOS_SNAPSHOT table.
The query to populate metrics only shows those metrics which have been collected within the past 24 hours (as this is the default for a new metric view) and this is determined by querying S_QOS_SNAPSHOT which contains the most recent samplevalues for all QoS in the database.
There are a few things to check here:
1. Validate if the suspect UIM instance only has a few robots and small number of metrics being collected.
2. Run the query below to confirm if the data_engine is populating current QOS data into the S_QOS_SNAPSHOT table
select max(sampletime) from S_QOS_SNAPSHOT
In this scenario the output showed a time stamp from several days back
3. Check the hub_bulk_size key on the data_engine.cfg and confirm if value is set to a high value, example 2000.
4. Revert the hub_bulk_size key value to a lower value, 20 or 50.
Wait several poll cycles and validate if the Select query in Step 2 now returns a current day/time
Check Metrics in OC and now metrics being collected should be displayed
Note: The hub_bulk_size key should be set to 1750 for UIM Instances that meet the sizes in the below link:
If this is not the issue, you should set the loglevel on data_engine to level 3 or higher and also add/change the following keys in data_engine.cfg:
log_lsv_rows = 1
lsv_sleep = 3
In most cases, lsv_sleep is already present and set to 3, but if it is missing, you should add it.
log_lsv_rows is likely present and set to 0 already, so you need to flip this to "1" to enable logging of the process that updates S_QOS_SNAPSHOT table.
Watch the data_engine.log and every 3 seconds you should see an attempt to update the table. If there is any issue with the database or the table itself it will be revealed here.
NOTE: If the above does not help, try restarting the primary HUB robot (if that's possible).