MCS alarm policy not deployed in 23.4 CU1
search cancel

MCS alarm policy not deployed in 23.4 CU1

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

For some reason, the alarm policy that is not deployed was associated to a 'poller' (see poller attrbute in table), in the database that does not exist anymore. The customer could see this in the sql output.
 

Environment

  • DX UIM 23.4 CU1

Resolution

  • 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.

Queries we ran to work on and 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
To workaround this issue we deleted the existing alarm policy/conditions and recreated them.

Then we checked in the _plugin_metric.cfg on the given robot (controller) and saw that the alarm policy had been added.