Alarm counts differ in USM depending on view
search cancel

Alarm counts differ in USM depending on view

book

Article ID: 33945

calendar_today

Updated On:

Products

DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

Alarm counts differ in USM depending on view

Environment

Release: UIM 8.2
Component: UIMNAS

Cause

NA

Resolution

Steps:

1. Obtain from Support and download two packages, nas v4,72 and the hotfix (USM 8.2 HF4)

2. Drag and drop them into the primary hub's local Archive

3. From there, drag and drop the nas

4. Then drag and drop the usm package

5. Cold start (Deactivate-Activate) the nas

6. When the wasp is up, restart the usm webapp from the wasp GUI

7. Delete any alarms that are out of sync


Follow the Article:

"Nas alarm counts are not in sync between UMP USM and the Infrastructure Manager alarm subconsole"


https://na4.salesforce.com/articles/TroubleshootingObj/Nas-alarm-counts-are-not-in-sync-between-UMP-USM-and-the-Infrastructure-Manager-alarm-subconsole?popup=true


That should be it and from there on you should no longer have any significant alarm count discrepancies between the nas and USM.


Note on Custom probe alarms


Custom probes need to use the latest SDK/APIs so that the CI data is set in order for them to be associated with the device in the USM tree view. If using LUA and the nsa not that the API has NOT been updated with functions to set the CI information.


That said, Perl is and java provides this ability. Probably DotNet and C# also. If it is supported by the probe framework SDK, it should have the CI functionality.


If you see any delays in getting alarms or alarm delay issues in general try this and see if it helps:


Edit the dashboard_engine via Raw Configure:


alarm_processor_batch_delay = 100

alarm_processor_batch_size = 2000


If this doesn't help -- or if it makes the problem even worse - try this:


alarm_processor_batch_delay = 400

alarm_processor_batch_size = 2000


If it seems to make the problem better, but still not perfect, try:


alarm_processor_batch_delay = 50

alarm_processor_batch_size = 2000


Sometimes you have to tweak these numbers a little bit to find the "sweet spot".


This could indicate database performance issues, and the index fragmentation as well as general health/disk IO speed/etc of the database server and/or NAS_ALARMS, NAS_TRANSACTION_LOG and NAS_TRANSACTION_SUMMARY tables should be investigated by a DBA.