You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/event-alarm-framework/event-alarm-framework.md
+7-8
Original file line number
Diff line number
Diff line change
@@ -233,9 +233,9 @@ EVENT table should support 40k/30-day records. Current active alarms are limited
233
233
### 1.2.1 Basic Approach
234
234
The feature involves new development.
235
235
Applications act as producers by writing to a table in redis app-db.
236
-
Eventd receives a new record in the table and process it:
237
-
It saves the processed entry in event history table; if the event has a state and if it is RAISED, record gets added to alarm table and system health is updated.
238
-
If the state is CLEARED, record is removed from ALARM table and system health is updated.
236
+
Eventd receives a new record in the table and processes it:
237
+
It saves the entry in event history table; if the event has a state and if it is RAISED, record gets added to alarm table and system health is updated.
238
+
If the received event state is CLEARED, record in the ALARM table is removed and system health is updated.
239
239
Both EVENT and ALARM tables are stored under state-db. For stats, EVENT_STATS and ALARM_STATS are maintained in state DB.
240
240
Eventd then informs logging API to format the log message and send the message to syslog.
241
241
@@ -260,7 +260,7 @@ There are three players in the event framework. Producers, which raises events;
260
260
261
261
Applications act as producers of events.
262
262
263
-
Event consumer class in eventd container receives and processess the event whenever a new one is produced.
263
+
Event consumer class in eventd container receives and processes the event whenever a new one is produced.
264
264
Event consumer manages received events, updates event history table and current alarm table and invokes logging API, which constructs message and sends it over to syslog.
265
265
266
266
Operator can chose to change properties of events with the help of event profile. Default
@@ -277,6 +277,7 @@ Application that need to raise an event, need to use event notifiy API ( LOG_EVE
277
277
This API is part of *libeventnotify* library that applications need to link.
278
278
279
279
For one-shot events, applications need to provide event-id (name of the event), source, dynamic message, and event state set to NOTIFY.
280
+
280
281
For alarms, applications need to provide event-id (name of the event), source, dynamic message, and event state (RAISE_ALARM / CLEAR_ALARM / ACK_ALARM).
281
282
282
283
The eventd maintains a static map of event-ids. Developers of events need to declare event-id
@@ -471,15 +472,13 @@ So, on certain platforms, system LED could not represent events on the system.
471
472
Another issue is: Currently pmon controls LED, and as eventd now tries to change the very same LED, this leads to conflicts.
472
473
A mechanism must exist for one of these to be master.
473
474
474
-
The proposed solution is to have a system health parameter in the DB and have pmon use this parameter in conjunction with existing logic to update system LED.
475
+
The proposed solution is to have a system health parameter in the DB populated by eventd and have pmon use this parameter in conjunction with existing logic to update system LED.
This is updated by eventd and pmon could use it to update LED accordingly.
482
-
483
482
#### 3.1.4.5 Event/Alarm flooding
484
483
There are scenarios when system enters a loop of a fault condition that makes application trigger events continuously. To avoid such
485
484
instances flood the EVENT or ALARM tables, eventd maintains a cache of last event/alarm. Every new event/alarm is compared against this cache entry
@@ -510,7 +509,7 @@ The framework will sanity check the user selected profile and merges it with def
510
509
511
510
The framework generates an event indicating that a new profile is in effect.
512
511
513
-
If there are any outstanding alarms in the current alarm table, the framework removes those records for which enable is set to false in the new profile. System health status updated accordingly.
512
+
If there are any outstanding alarms in the current alarm table, the framework removes those records for which enable is set to false in the new profile. System health status is updated accordingly.
514
513
515
514
Eventd starts using the merged map of characteristics for the all the newly generated events.
0 commit comments