Alarm counts differ in USM depending on view
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.