Creating MCS Alarm Policies in DX UIM 23.4 based on Alarm Thresholds from pre 23.4 releases

Products

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

Issue/Introduction

In UIM 20.4.x, alarm thresholds could be configured in the profile section of MCS when policy_mode_enabled = false is set in the 'timed' section of the MCS probe in 20.4.x setup.

After upgrading to 23.4.x from 20.4.x, this functionality is removed. It is no longer possible to view or modify Alarm thresholds in the profile section of MCS UI.

Upgrading to UIM 23.4 does not automatically convert these profile thresholds to alarm policies, so the alarm policies will need to be created to manage the thresholds.

In 20.4, if we configure the thresholds in the MCS UI profile section, the <alarms> section is present in the plugin_metric.cfg after the profile is deployed. We need to manually extract the alarm threshold values configured in 20.4.x from the existing thresholds, and then manually create the Alarm Profiles. This can either be done prior to upgrading or after.

Environment

DX UIM 20.4.x upgraded to 23.4.x

Resolution

Note:

It’s always safe to take the backup of all plugin_metric.cfg files before start making any changes, so that they can be used for troubleshooting if something does not work as expected.
First validate the steps in Dev/Preprod, only then execute at Production.

The alarm policies can be created by performing the following steps:

Import the Dashboard Designer content to see all the profiles ( eg: profileId=2) created in 20.4 (Note that there are two dashboards; one for group profiles and the other for device profiles).
1. Login to the OC as an administrator.
2. Navigate to Dashboard, Dashboard Designer.
3. Create a new dashboard
4. Select Import
5. Import the MCS+Alarm+Configurations.zip file which is attached to this article.
6. Select one of the imported dashboards and then Click Open
7. When it opens, select the Dashboard menu and choose the Live View option. The data should load within 15-30 seconds.
8. When the dashboard is loading, you can see the Last Update field (may be at the bottom or top of the dashboard). If there is no date, the data is not loaded yet. (See Step 1k below if you need to increase the timeout values). Also note in the top right, where you can switch to the other dashboard. In the screenshot below, you currently see the Group profiles dashboard and the link to switch to the device profiles dashboard.
9. Also the Group Dashboard has a filter with the group name and the profile name. The Device Dashboard only lists the profile name
10. The data can be exported to .csv using the export button in the top right:
11. If the dashboards do not load within 15-30 seconds, you can increase the timeout values in the OC wasp raw configuration.
  In the /webapps/dashboard/timeouts section of raw configure, update the following keys:
  1. dataSession changed from 10000 ->100000
  2. dashboardDS changed from 30000 -> 100000
  3. sqlDS changed from 10000 -> 100000
Using the data from the dashboard in Step 1, create new alarm policies in disable mode based on profiles and their threshold configurations listed in dashboard viewer.
This is done in the Alarm policies section in the Alarm management section. The steps below show how to create these policies in a disabled status. They will be enabled later after the old thresholds are removed.
1. Click Add in the Alarm Management -> AlarmPolicies section of OC
2. Give a meaningful alarm policy name that can be recognized later. We can give multiple metrics in a single alarm policy. For easy identification, you can have one alarm policy for each group and template combination.
  Then, click Add Condition.
  Eg: Alarm policy1 has group1 with metrics from the memory monitor template. Alarm policy2 has group1 with metrics from SQL server template.
3. In the windows that pops up, select the type (for our example, we're creating a group alarm policy).
4. Then select the intended group:
5. Choose the metric:
6. Set the thresholds as found in the imported Dashboard
7. Set the TOT settings
8. Create customer alarm message.
9. When completed, click 'Save and Disable' in the bottom right corner
10. You can confirm that these policies are deployed to the robot by reviewing the plugin_metric.cfg file. You will see the <policy_[policyId]> tag with sections for metrics and thresholds inside that tag. The number of sections under the <policy_[policyId]> tag depend upon the conditions of the policy.
Repeat the steps 2a-2j above for each Group and Device threshold profile to create the Alarm Policies.
Configure MCS to use the intended settings for alarm policies:
Edit the key policy_mode_enabled = true in the timed section of the MCS probe-> raw config. Allow the probe to restart.
Redeploy the profiles by updating the profile status to 'modified' in the db for the Profiles which you have created new Alarm policies in the second step, by using the dashboard.
This will remote the old threshold profiles.
```
Update SSRV2Profile set status='modified' where profileId in (1,2,3,4....)
```
Note:-
It is recommended to test the update a single group profile by using a simplified version of the query. Instead of multiple profiles at a time, you can use a single profile so that you can easily verify completion before updating in all groups at once.
```
Update SSRV2Profile set status='modified' where profileId in (1)
```
Validate the update statements are complete:
1. Allow MCS to process the update in Step 5 and wait for all the profiles status to become “OK” from the “Modified.” When these profiles have updated to status = 'ok', it is ok to proceed.
  We can verify the status by running below query in the db.
```
select status,* from SSRV2Profile  where  profileId in (1,2,3,4....)
```
2. Confirm that the changes have occurred on the robot:
  1. Check the profile section in the plugin_metric.cfg file, and profile content is displayed without the <alarms> section.
  2. Once profile content without <alarms> section is verified in the plugin_metric.cfg file of a couple of sample robots, then proceed with step 7 below.
    Note:-
    Once the profiles are redeployed in policy_mode_enabled=true , the <alarms> section will be erased and alarms will no longer be raised until the new alarm policies are created and deployed on respective groups.
    If policy_mode_enabled=true, the <alarms> section will be removed for existing profiles in plugin_metric.cfg when they are either updated to 'modified' state through sql query or updated from the UI.
    When the existing profiles (previously created when policy_mode_enabled=false is set) are not updated or redeployed, the alarms are generated based on the alarms section in the profile of the plugin_metric.cfg.
Enable newly created Alarm policies in OC by clicking the "Enabled" toggle switch in the top right.

This step must be done for each new alarm policy. Once enabled, policies are redeployed and then the alarms may be generated.