• The feature creates a database of event IDs and the corresponding actions as configured through CLI. When an event occurs, the event is matched in the database with the existing event ID, severity, and log pattern. If the event matches with the existing event in the database, it triggers a corresponding action automatically. If there is no match with the database, then no action is taken.

• Configurable parameters for an event are event ID, severity, and log pattern, which are matched with the incoming log. In order to be unique, the recommendation is to have all these parameters configured for an event. Configuring the event ID is mandatory, while severity and pattern are optional. No manual configuration of severity applies the default severity of all (0-6).

• Duplicate event configuration with the same value for event ID, severity, and log pattern as an existing event with a new event name is not allowed and displays an error.

• The feature facilitates the configuration of one action for multiple events.

• Place the action script file in the path /usr/local/etc. A warning message is displayed if the script file is not in the path, but the configuration is accepted.

• The execution count or the trigger count per policy is stored and maintained. When a policy is cleared, the event and the action associated with the policy get cleared. When an action is associated with multiple policies, the action associated with the cleared policy is removed, and the same action associated with other policies remains.

• This feature consumes a certain amount of CPU performance because it matches the logs recorded by the system with every configured event. Hence, a maximum number of 50 events, actions, and policies is configurable.

• The command line shell (cmlsh) uses a locking mechanism. Follow the recommendation when a user or script file gets into the configure mode:

• Disable the event manager feature while executing manual configuration in the system. This prevents the Python script from interfering with the manual configuration. After executing the manual configuration, enable the event manager feature.

• There is a possibility of multiple Python scripts executing simultaneously. In order to sequence the configure mode execution, the Python script has the logic to wait for 45 seconds in the configure mode. This prevents the Python script from exiting without executing the commands if another script is still in configure mode.

• If the script fails to execute, the event manager does not record such failures.

• When the feature is neither enabled nor disabled, the event, action, or policy configuration displays an error.

• The event manager displays an error if an event is edited when associated with a policy.

• The event manager exercises priority-based selection of policies for any incoming logs. When there are more actions associated with the same event with different event IDs, severity levels, and pattern, the priority sequence is as follows:

• The solution supports the validation of event-id against configurable event-ids. It displays an error if the entered event-id is not supported.

• To create an event, define the event name ( E1), type (syslog), event ID (IFMGR_IF_UP), and optional parameters of severity (0) and pattern (“xe5”).

• To create an action, save the python script in the /usr/local/etc path and define the action name (A1), the type (script) and the type value (ifup.py).