SLM-SLA Reporting - Availability calculation method in SLM

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)
• DX Unified Infrastructure Management (Nimsoft / UIM)
• CA Unified Infrastructure Management SaaS (Nimsoft / UIM)
• Unified Infrastructure Management for Mainframe

Issue/Introduction

We are trying to create SLA server Availability report in SLM. We are expecting compliance of 99 % for device. In SLO creation, we are considering QOS_POWER_STATE qos for the device availability. However, We are providing expected value would be >= 99 for the device but the problem is that we are getting sample values either 0 or 1. How the default calculation will be achieve my compliance percentage? and what value should we provide to get the correct compliance for device availability for the selected period?

Environment

Release : 20.3

Component : UIM - SLA_ENGINE

Resolution

While creating the QOS constraint in SLO, the expected value should be set to 1 in this case, and the expected compliance at SLA/SLO should be set to 99. The actual compliance will be based on the formula - (Number of samples collected with value 1 during the compliance period)*100/Total number of samples collected during the compliance period.

Furthermore, UIM uses the RN tables for generating the SLA reports, so as long as we have the data in the RN tables you will able to populate those SLA reports.

You can choose to increase the retention policy days (raw data setting in the data_engine) , e.g., up to 60 days so you are able to see the current month and 30 days prior.

If you increase the raw data retention make sure you have:

1) MS SQL Server Standard 'Enterprise' Edition (not Standard), or if another DB, DB Table Partitioning is supported
2) Index maintenance disabled. Instead run a daily job to defrag select tables.
3) DB Partitioning is enabled in the data_engine

HN data is stored 'compressed' so it cannot be used for accurate compliance calculations for SLA/SLO purposes.

Raw data retention must be set high enough to populate the desired time period.

Additional Information

Indexes that require defragmentation (daily)

Here is a list of tables that you CAN run a daily index defrag job upon:

ALTER INDEX ALL ON CM_COMPUTER_SYSTEM REBUILD; 
ALTER INDEX ALL ON CM_DEVICE REBUILD; 
ALTER INDEX ALL ON CM_COMPUTER_SYSTEM_ATTR REBUILD; 
ALTER INDEX ALL ON CM_DEVICE_ATTRIBUTE REBUILD; 
ALTER INDEX ALL ON CM_CONFIGURATION_ITEM REBUILD; 
ALTER INDEX ALL ON CM_CONFIGURATION_ITEM_METRIC REBUILD; 
ALTER INDEX ALL ON CM_CONFIGURATION_ITEM_DEFINITION REBUILD; 
ALTER INDEX ALL ON CM_CONFIGURATION_ITEM_METRIC_DEFINITION REBUILD; 
ALTER INDEX ALL ON CM_NIMBUS_ROBOT REBUILD; 
ALTER INDEX ALL ON CM_DEVICE REBUILD; 
ALTER INDEX ALL ON CM_COMPUTER_SYSTEM_ORIGIN REBUILD; 
ALTER INDEX ALL ON CM_CONFIGURATION_ITEM_ATTRIBUTE REBUILD; 
ALTER INDEX ALL ON CM_RELATIONSHIP_CI_CI REBUILD; 
ALTER INDEX ALL ON CM_RELATIONSHIP_CI_CS REBUILD; 
ALTER INDEX ALL ON CM_RELATIONSHIP_CS_CI REBUILD; 
ALTER INDEX ALL ON CM_DISCOVERY_NETWORK REBUILD; 
ALTER INDEX ALL ON S_QOS_DATA REBUILD; 
ALTER INDEX ALL ON NAS_TRANSACTION_SUMMARY REBUILD; 
ALTER INDEX ALL ON NAS_ALARMS REBUILD; 
ALTER INDEX ALL ON NAS_TRANSACTION_LOG REBUILD;