Configuring system event notifications using the CLI

Use the commands in this topic to customize system event notifications for each user and to configure which events trigger notifications.

Important
You cannot view most Central Management System high availability (HA) events as described in this topic, and cannot configure which of those events trigger notifications. For a list of the HA events and their severity, see the Central Management System High Availability Guide.

Viewing system events

You can view all system events, or the system events that are currently enabled to trigger notifications, ordered by their severity.

To view all system events:

Go to CLI configuration mode:

hostname > enable
hostname # configure terminal

View the events:

hostname (config) # email notify event ?

To view enabled system events and their severity:

View the events by severity:
```
hostname > show email events
```

Enabling email notification

To enable receiving of email notifications:

hostname > enable email

Configuring system event notifications for each user

To configure system event notifications for each user:

Go to CLI configuration mode:

hostname > enable
hostname # configure terminal

View the current configuration:
```
hostname (config) # show email
```

Specify the severity of events for which each user should receive notifications.

To receive "info" events:

hostname (config) # email notify recipient <emailAddress> class info

To stop receiving "info" events:

hostname (config) # no email notify recipient <emailAddress> class info

To receive "failure" events:

hostname (config) # email notify recipient <emailAddress> class failure

To stop receiving "failure" events:

hostname (config) # no email notify recipient <emailAddress> class failure

Specify the notification format:

To receive detailed notifications:

hostname (config) # email notify recipient <emailAddress> detail

To receive summarized notifications:

hostname (config) # no email notify recipient <emailAddress> detail

Specify the scan event (aborted, started, stopped, error (example: when continuous scan fails for any reason), paused or unmounted):
```
hostname (config) # email notify recipient <emailAddress> scan-details
```

Configuring which events trigger notifications

To configure which events trigger notifications:

Go to CLI configuration mode:

hostname > enable
hostname # configure terminal

View the current configuration as described in Viewing system events .

To enable an event:

hostname (config) # email notify event <event>

To disable an event:

hostname (config) # no email notify event <event>

Verify your changes:
```
hostname (config) # show email events
```
Save your changes:
```
hostname (config) # write memory
```

Examples

This example stops admin@acme.com from receiving "info" notifications and changes the message format to a summary.

hostname (config) # show email
...
Email notification recipients:
  admin@acme.com (all events, in detail)
  operator@acme.com (failure events only, in detail)
  user3@acme.com (all events, in detail)
...
hostname (config) # no email notify recipient admin@acme.com info
hostname (config) # no email notify recipient admin@acme.com detail
hostname (config) # show email
...
Email notification recipients:
  admin@acme.com (failure events only, summarized)
  operator@acme.com (failure events only, in detail)    
  user3@acme.com (all events, in detail)

This example disables log file rotations from triggering event notifications:

hostname (config) # no email notify event syslog-rotation

This example disables DOP (depth of processing) overloads from triggering event notifications:

hostname (config) # no email notify event avc-overload

The avc-overload event is an "info" level event that is generated for DOP overloads. DOP overloads occur when there is CPU contention for an MVX engine. If an overload occurs often, it can affect email and file analysis and potentially result in false negatives. If an appliance consistently has less than 30% DOP, it is overloaded. This may not be an issue if an overload happens for only a few minutes a week, but if there are overloads for several hours of every work day, the MVX engine should be allotted more CPU time.