MCS alarm policy not deployed in 23.4
search cancel

MCS alarm policy not deployed in 23.4

book

Article ID: 374450

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

MCS Alarm Policies are not deployed, the policy exist but it's not deployed to the target systems. 
 
For some reason, the alarm policy that is not deployed is associated to a 'poller' (see poller attrbute in table), in the database that does not exist anymore. This can't be observed in the sql output.
 

Environment

DX UIM 23.4 CU1 / CU2 / CU3

Cause

Non-Reproducible issue.

Resolution

Notes:

  • cs_id and poller SHOULD be the same if the probe is a local probe not a remote probe.
  • remote probes, cs_id and poller id should be different.
  • The 'poller' is the source (monitoring device).
  • 90% of the policies within the customer's environment are Group policies.
  • The 'id' attribute is a group id. If the ancestor policy value is null, then that means its a group policy. 
  • The children are listed below the group 'id' e.g., 2365 and other numeric values.
  • It normally takes 4-6 mins minimum. for policy status to update/sync.

The example queries below can be used to debug the alarm policy not being deployed to the robot:

select * from SSRV2PolicyTargetStatus
where cs_id!= poller

To backup the table you can run:
select * into SSRV2PolicyTargetStatus_bkup from SSRV2PolicyTargetStatus

select * from cm_computer_system
where cs_id in (44749,43647,43828)

select * from Policy

select * from SSRV2PolicyTargetStatus
where cs_id!= poller and policy_id = 96 

 

Workaround/Resolution:

To workaround the issue, delete the existing alarm policy/conditions and recreate them from scratch. 

Check in the _plugin_metric.cfg on the target robot (spooler CTRL+B to pull out the file from IM) and check that the alarm policy had been added.