Update event-alarm-framework.md

Author: spenugondaa

doc/event-alarm-framework/event-alarm-framework.md

@@ -33,7 +33,7 @@ Event and Alarm Framework
         * [3.1.4.6 Eventd continuous restart](#3146-event-continuous-restart)
       * [3.1.5 Event Profile](#315-event-profile)
       * [3.1.6 CLI](#316-cli)
-      * [3.1.7 Event History Table and Current Alarm Table](#317-event-history-table-and-current-alarm-table)
+      * [3.1.7 Event Table and Alarm Table](#317-event-table-and-alarm-table)
       * [3.1.8 Pull Model](#318-pull-model)
       * [3.1.9 Supporting third party containers](#319-supporting-third-party-containers)
     * [3.2 DB Changes](#32-db-changes)
@@ -103,14 +103,14 @@ Such a change has an important metric called *severity* to indicate how critical
 
 Both events and alarms get recorded in a new DB called EVENT DB in a new redis instance.
 
-1.  Event History Table
+1.  Event Table
 
-    All events get recorded in the event history table, by name, "EVENT". EVENT table contains history of all events generated by the system.
+    All events get recorded in the event table, by name, "EVENT". EVENT table contains history of all events generated by the system.
     This table is persisted across system restarts of any kind, including restore to factory defaults and SW upgrades and downgrades.
 
-2. Current Alarm Table
+2. Alarm Table
 
-   All events with an action field of *RAISE* get recorded in a table, by name, "ALARM" in addition to getting recorded in Event History Table ( only events corresponding to an alarm has action field ).
+   All events with an action field of *RAISE* get recorded in a table, by name, "ALARM" in addition to getting recorded in Event Table ( only events corresponding to an alarm has action field ).
    When an application that raised the alarm clears it ( by sending an event with action *CLEAR* ), the alarm record is removed from ALARM table.
    An user acknowledging a particular alarm will NOT remove that alarm record from this table; only when application clears it, the alarm is removed from ALARM table.
 
@@ -237,7 +237,7 @@ Application owners need to identify various conditions that would be of interest
 The feature involves new development.
 Applications act as producers by writing to a table with the help of event notify library.
 Eventd reads new record in the table and processes it:
-It saves the entry in event history table; if the event has an action and if it is *RAISE*, record gets added to alarm table, severity counter in ALARM_STATS is increased.
+It saves the entry in event table; if the event has an action and if it is *RAISE*, record gets added to alarm table, severity counter in ALARM_STATS is increased.
 If the received event action is *CLEAR*, record in the ALARM table is removed and severity counter in ALARM_STATS of that alarm is reduced by 1.
 If eventd receives an event with action *ACKNOWLEDGE* from mgmt-framework, severity counter in ALARM_STATS is reduced by 1.
 If eventd receives an event with action *UNACKNOWLEDGE* from mgmt-framework, severity counter in ALARM_STATS is increased by 1.
@@ -270,15 +270,15 @@ There are three players in the event framework. Producers, which raises events;
 Applications act as producers of events.
 
 Event consumer class in eventd container receives and processes the received event. 
-Event consumer manages received events, updates event history table, current alarm table, event_stats table and alarm_stats tables and invokes logging API, which constructs message and sends it over to syslog. 
+Event consumer manages received events, updates event table, alarm table, event_stats table and alarm_stats tables and invokes logging API, which constructs message and sends it over to syslog. 
 
 Operator can chose to change properties of events with the help of event profile. Default
 event profile is available at */etc/evprofile/default.json*. User can download the default event profile,
 modify and upload it back to the switch to apply it. 
 
 Through event profile, user can change severity of any event and also can enable/disable a event.
 
-Through CLI, REST or gNMI, event history table and current alarm table can be retrieved using various filters.
+Through CLI, REST or gNMI, event table and alarm table can be retrieved using various filters.
 
 ### 3.1.1 Event Producers
 Application that need to raise an event, need to use event notifiy API ( LOG_EVENT ).
@@ -385,7 +385,7 @@ As mentioned above, static information contains severity, static message and eve
 If the enable flag is set to false, event consumer ignores the event by logging a debug message.
 If the flag is set to true, it continues to process the event as follows:
 - Generate new sequence-id for the event
-- Write the event to Event History Table
+- Write the event to Event Table
 - It verifies if the event corresponds to an alarm - by checking the *action* field. If so, alarm consumer API is invoked for the event for further processing.
     - If action is RAISE_ALARM, add the record to ALARM table
     - If action is CLEAR_ALARM, remove the entry from ALARM table
@@ -403,7 +403,7 @@ Severity INFORMATIONAL is not applicable to alarms.
 Every new event should have a unique sequential ID. The sequence-id is persistent and continues to grow until 2 exp 64.
 
 ### 3.1.3 Alarm Consumer
-The alarm consume method on receiving the event record, verifies the event action. If it is RAISE_ALARM, it adds the record to Current Alarm Table.
+The alarm consume method on receiving the event record, verifies the event action. If it is RAISE_ALARM, it adds the record to Alarm Table.
 The counter in ALARM_STATS corresponding to the severity of the incoming alarm is increased by 1.
 
 Eventd maintains a lookup map of *sequence-id* and pair of *event-id* and *resource* fields.
@@ -632,7 +632,7 @@ The framework will sanity check the user selected profile and merges it map of e
 
 After a successful sanity check, the framework generates an event indicating that a new profile is in effect. 
 
-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. 
+If there are any outstanding alarms in the alarm table, the framework removes those records for which enable is set to false in the new profile. 
 Severity counters in ALARM_STATS are reduced accordingly.
 
 Eventd starts using the merged map of characteristics for the all the newly generated events. A CUSTOM_EVPROFILE_CHANGE event is generated.
@@ -666,9 +666,9 @@ The rpc callback needs to access DB with the given set of sequence ids.
 
 The gNMI server (gnoi_client.go, gnoi.go, sonic_proto, transl_utils.go) need to be extended to support the RPC to support similar operations for gNMI.
 
-### 3.1.7 Event History Table and Current Alarm Table
-The Event History Table (EVENT) and Current Alarm List Table (ALARM) stored in EVENT_DB. 
-The size of Event History Table is 40k records or 30 days worth of events which ever hits earlier.
+### 3.1.7 Event Table and Alarm Table
+The Event Table (EVENT) and Alarm List Table (ALARM) stored in EVENT_DB. 
+The size of Event Table is 40k records or 30 days worth of events which ever hits earlier.
 A manifest file will be created with parameters to specify the number and number of days limits for
 eventd to read and enforce them.
 
@@ -743,7 +743,7 @@ acked           : Total alarms acknowledged {uint64}
 8) "0"
 127.0.0.1:6379[6]>
 ```
-Current Alarm Table will not have any limits as it only contains the snapshot of the alarms during the current run.
+Alarm Table will not have any limits as it only contains the snapshot of the alarms during the current run.
 
 Contents of an alarm record. In this case, the alarm was raised temperature crossed a threshold.
 ```
@@ -811,7 +811,7 @@ informational             : Number of alarms of severity 'informational' {uint64
 
 ```
 ### 3.1.8 Pull Model
-All NBIs - CLI, REST and gNMI - can pull contents of current alarm table and event history table.
+All NBIs - CLI, REST and gNMI - can pull contents of alarm table and event table.
 The following filters are supported:
 - ALL ( pulls all alarms)
 - Severity.
@@ -839,7 +839,7 @@ Approach 1 is preferred.
 A new instance, redis4, is created and EVENT DB uses the new instance.
 The following tables uses Event DB.
 Table EVENTPUBSUB is used for applications to write events and for eventd to access and process them.
-Event History Table (EVENT) and Current Alarm Table (ALARM) are used to house events and alarms respectively.
+Event Table (EVENT) and Alarm Table (ALARM) are used to house events and alarms respectively.
 To maintain various statistics of events, these two tables are used : EVENT_STATS and ALARM_STATS.
 
 EVPROFILE table is used by mgmt-framework to communicate name of the custom event profile when configured through NBI. 
@@ -1009,11 +1009,11 @@ sonic# event profile <profile-name>
 The command takes name of specified file, validates it for its syntax and values; merges it with its internal static map of events *static_event_map*.
 
 ```
-sonic# clear event history
+sonic# clear event
 ```
-This command clears all the records in the event history table. All the event stats are cleared. 
+This command clears all the records in the event table. All the event stats are cleared. 
 The command will not affect alarm table or alarm statistics.
-Eventd generates an event informing that event history table is cleared. 
+Eventd generates an event informing that event table is cleared. 
 
 #### 3.3.2.2 Configuration Commands
 ```
@@ -1238,9 +1238,9 @@ When eventd is restarted, events and alarms raised by applications will be waiti
 When eventd eventually comes back up, it reads those records in the queue.
 
 # 6 Scalability
-In this feature, scalability applies to Event History Table (EVENT). As it is persistent and it records every event generated on the system, to protect
+In this feature, scalability applies to Event Table (EVENT). As it is persistent and it records every event generated on the system, to protect
 against it growing indefinitely, user can limit its size through a manifest file.
-By default, the size of Event History Table is set to 40k events or events for 30 days - after which, older records are discarded to make way for new records.
+By default, the size of Event Table is set to 40k events or events for 30 days - after which, older records are discarded to make way for new records.
 
 # 7 Showtech support
 The techsupport bundle is upgraded to include output of "show event recent 60min” and “show alarm all”.