Conditions for saving alarms to the Reporting DB

[MARUBUN SUPPORT]

Hi Team.

Our customer has the following questions.

I would appreciate some advice on how to solve this question.

[Product]

Spectrum 23.3

RHEL7.2

[Questions]

This question is related to the following question.

I would appreciate it if you could give me some advice.

 

• Records in the alarminfo table in the Reporting database

https://community.broadcom.com/question/records-in-the-alarminfo-table-in-the-reporting-database

• Records in the alarminfo table in the Reporting database

https://community.broadcom.com/discussion/number-of-important-alarms-and-number-of-important-events-do-not-match

 

"Records in the alarminfo table in the Reporting database" answered that the number of records in the alaerminfo table on the Reporting DB does not match the number of records in the Archive Manager's DDM database (the number of alarms displayed on the OneClick console).

 

Please let me know if there are any conditions for alarms to be stored in the Reporting DB.

End users are concerned about the difference between alarms that are stored in the Reporting DB and those that are not.

 

 

Best Regards,

Marubun Corporation

[MARUBUN SUPPORT]

Hi everyone,

Could someone please give me some advice on my question? 
I would be very grateful for any advice.

Best Regards,
Marubun Support

[Sandeep Kumar Mazwar]

Hi @MARUBUN SUPPORT,

If there are event filters used then event count will mismatch between DDM and reporting DB. Below document explains how to setup event filter and the path to access the event filter file to validate the same:

https://techdocs.broadcom.com/us/en/ca-enterprise-software/it-operations-management/spectrum/23-3/installing-and-upgrading/install-report-manager/maintenance-and-troubleshooting/define-event-filters-for-event-reports.html

Also, worth checking the event sync status, 

OneClick -> Administration -> Report Manager -> SPECTRUM Status

Event count will not match if you run the query at the same time in DDM and Reporting DB, as the event sync in reporting DB takes time.

Thanks!

Sandeep

[MARUBUN SUPPORT]

Hi Sandeep Kumar Mazwar-san,

 

Thank you for your answer.

I have a question about the answer below.

I would be very grateful if you could give me an answer or advice.

 

> If there are event filters used then event count will mismatch between DDM and reporting DB. 

Users believe that the number of events will match if "an event filter is not set" or "the event filter is removed and displayed" (ignoring the effects of synchronization described below).

Please let me know if this understanding is correct.

 

> Event count will not match if you run the query at the same time in DDM and Reporting DB, as the event sync in reporting DB takes time.

The user believes that "(disregarding the effects of this answer) the number of events will match, but there are differences in the parts that are not synchronized."

Please let me know if this understanding is correct.

 

 

Best Regards

Marubun Support

[Catalin Farcasanu]

Well, first of all, the DDMDb stores events up to default 45 days. SRM, on the other hand, extends this period (I believe this defaults to 90 days), for all events that are sent over to Reporting Database.

Alarms that are displayed on the OC are those that are active at the time you are looking at the console. In the reporting database you could see also alarms that are not active at this time, but were active at some point in the past. 

All alarms are stored in the SRM DB. On the other hand, not all events are sent to the both Archive Manager and Report Manager. So make a clear distinction between events and alarms. 

The events are stored just for statistic analysis: most common events that show up, devices with most events and so on. Traditionally events are purged from the SRM, due to increased storage required and the low benefits of reports.

The alarms have different actions that are followed on the SRM: acknowledgement, assignment, ticket creation, clearing, time active. Alarms and their corresponding action history are not purged ever from the SRM, unless the use chose to re-initialize the database. These don't occupy that much space in the database.