QOS data for monitor free space on datastore from vmware probe fails to be submitted to SLM database
search cancel

QOS data for monitor free space on datastore from vmware probe fails to be submitted to SLM database

book

Article ID: 8487

calendar_today

Updated On:

Products

DX Unified Infrastructure Management (Nimsoft / UIM) CA Unified Infrastructure Management On-Premise (Nimsoft / UIM) CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

Datastore

  • Monitor :Free (in % of Capacity)
  • QOS Name : QOS_DS_DISK_FREE
  • This monitor indicates the free space on this datastore , in percent of capacity

The vmware probe is successfully submitting QoS messages (for example as observed via Dr Nimbus) for QOS_DS_DISK_FREE monitor but the data is not persisting in the SLM database.

In addition, the data_engine log entries indicate that the message was rejected due to a conflict in the samplemax missing for the qos_definition (at loglevel 3).

Example as seen in data_engine logs provided 

Line 74082: Oct 17 11:25:10:912 [47800] de: HandleMessage: Insert Data - nimid: MJ13532687-55913 (2017-10-17 11:25:05) table_id: 0 value= 99.28 time: 2017-10-17 11:25:04 qos=QOS_DS_DISK_FREE source=xxxxx target=xxxxxxx_LOCAL/Free (in % of Capacity) 

Line 74175: Oct 17 11:25:10:917 [47800] de: QoSInsert::CheckDataIntegrity - message dropped; samplemax is missing. qos=QOS_DS_DISK_FREE source=xxxxx target=xxxxxxx/Free (in % of Capacity)

Environment

  • UIM 8.5x
  • vmware 6.6x or higher

Cause

  • This problem is occurring because initially you were collecting QOS_DS_DISK_FREE metrics with a vmvware probe version earlier than 5.x. 
  • The 'hasmax' value was removed from the vmware probe for the QOS_DS_DISK_FREE QoS metric in the initial 5.x release, as having it in there was considered a defect. 
  • If you had never collected this metric with an earlier release of the vmware probe, there would have been no problem, but if you did, you run into the problem where the data_engine drops this QoS since upgrading to vmware 6.6x.

Resolution

To avoid running into this problem with future deployments of the vmware probe remove “hasmax / samplemax” from definition table, raw data table and historical data table in the backend database. 


Steps to remove "hasmax / samplemax" from the tables in the backend database: 

Please take a backup of the concerned tables before the change 

1. Update the S_QOS_DEFINITION so that the data_engine will accept the correct formats:

UPDATE S_QOS_DEFINITION SET hasmax = 0 WHERE name = 'QOS_DS_DISK_FREE';

2. Delete the “samplemax” column from the RN_QOS_DATA_xxxx , HN_QOS_DATA_xxxx  and DN_QOS_DATA_xxxx associated with the QOS_DS_DISK_FREE QoS metrics. 


For raw data: 

ALTER TABLE RN_QOS_DATA_xxxx DROP COLUMN "samplemax"; 

For historical data: 

ALTER TABLE HN_QOS_DATA_xxxx DROP COLUMN "samplemax"; 

For daily data: 

ALTER TABLE DN_QOS_DATA_xxxx DROP COLUMN "samplemax";


For example, if in your environment the QOS_DS_DISK_FREE is stored in RN_QOS_DATA_0500 /HN_QOS_DATA_0500/DN_QOS_DATA_0500 tables you can use the queries shown below:

ALTER TABLE RN_QOS_DATA_0600 DROP COLUMN "samplemax"; 

ALTER TABLE HN_QOS_DATA_0600 DROP COLUMN "samplemax"; 

ALTER TABLE DN_QOS_DATA_0600 DROP COLUMN "samplemax";


3. Restart the data_engine so the change to the QOS definition is recognized.