In its most generic form, alerts are a construct intended to inform administrators of significant events within the NSX Advanced Load Balancer system. Once an alert is triggered, it can be used to notify an administrator through one or more notification actions. Alerts can trigger ControlScripts to alter the system configuration or communicate to remote systems.

Alert Scope

Alerts can be viewed in multiple places within the UI, including under Virtual Services, Pools, Service Engine, and All Alerts pages. Navigate to Operations > Alerts > All Alerts to view all current alerts, logged across the system. Alert lists under SEs, Virtual Services, and Pools include alerts specific to the context.

Alerts are transient and can exist or be true only for a defined period. After the configured alert expiry time lapses, the alert is removed. The underlying event or metric that triggered the alert still exists as a permanent log of what occurred.

Alert Workflow



Configuring custom alerts requires walking through the workflow to build the alert config (the alert’s trigger) based on one or more metrics from a list of more than 500 events and metrics. When the alert configuration’s conditions are met, the actions configured in the alert action are executed. The alert action can list the notifications to be generated and potentially call for further action, such as application autoscaling or execution of a ControlScript.

Alert Config

The Alert Config page is used to define the triggers that will generate an alert. The NSX Advanced Load Balancer has a number of canned alert configs, which are used to generate alerts in a default deployment.

Events trigger alerts to actively highlight important information. Default alerts are created through the Alert Config page. These alerts configs can be modified or disabled, but not deleted. Alert configs are triggers that determine whether or not an alert should be generated.

To create a new alert config:

  1. Navigate to Operations > Alerts > Alert Config.

  2. Provide basic information such as Name, Alert Configuration Status, and Description.

  3. Choose the conditions that must be true to trigger an alert. The source can be an event or a metric. If multiple conditions exist, then all conditions must be true.

  4. The following table lists details the input fields of the Conditions modal page:

Field Name

Description

Throttle Alert

The alert must only be triggered once within the specified time frame. A value of 0 indicates there will be no time-based throttling. The timer begins once the alert is triggered.

Source - Event

An event triggers the alert. See the Events List for a list and brief description of all events.

Object

The type of object to listen for - a virtual service, SE, or pool.

Starting with version 20.1.3, all object types are available to be selected (through the CLI/API only).

Instance

Choose from a list of objects, based on the previously defined object type.

Number of Occurrences

The event must be seen X many times before the alert condition is met.

Rolling Window

When unchecked, an alert is triggered when the Number of Occurrences is met. If the Number of Occurrences value is set to one, every occurrence will trigger the alert (the Throttle Alert can suppress any alerts beyond the first one). If the value for the Number of Occurrences is set to a higher number, say x, the alert is triggered every x times the event happens.

When the Rolling Window is checked, a corresponding Time Window field must be populated. If the number of Occurrences is true within the specified window of time, the alert is triggered. Once the time window expires, the Number of Occurrences is reset and the counter begins again.

Event Occurs

Name of the event that would trigger the alert.

Event Does Not Occur

This field is optional. When set, the selected event must not be true during the same time window as the event defined in the Event Occurs field.

Source - Metric

When chosen, Metrics trigger the alert. When the Source is set to Metric, a few different options are presented:

Metric Occurs: Select the desired metric.

Comparator: The metric entry is compared through the greater than or equals, equals, or less than or equals to the averaged entry in the Value field over the specified number of seconds.

Value: Enter the scalar portion of the metric. For example, to specify two milliseconds, two is the scalar and “milliseconds” is the unit of measure. After a selection is made in the Metric Occurs field, the controller auto-populates the unit portion of the Value field. The units of measurement for the various metrics are documented in the Metrics Query API.

Duration: Enter a value greater than 5 minutes. The period should be in the order of 10s of minutes.

Add New Metric Rule: Additional rules can be specified. When multiple rules exist, all of them must be true.

  1. Enter values for the following fields in the Action modal window:

    1. Alert Action: Alert action defines the type of notifications to generate or other tasks resulting from the triggered alert.

    2. Alert Expiry Time: The triggered alert will be visible in the web interface for this duration of time, after which it is deemed expired and deleted.

Notifications

Alerts can be sent to four notification destinations. The first is the local UI. These notifications show up as colored bell icons in the Controller UI to indicate that an alert has occurred. The other three notifications namely, email, syslog, and SNMP v2c traps can be configured in the Operations > Notifications page.

Notifications can be classified into Local notifications, SNMP TRAP, Syslog and Email.

For more information on notification types, see Types of Notifications.

ControlScript

ControlScripts are Python-based scripts, executed from the Controller. They can be used to alter the NSX Advanced Load Balancer configuration or communicate to remote systems (such as Email, Syslog, and/or SNMP servers).

For example, if it is detected that an IP address is sending a SYN flood attack, the alert action can notify administrators by email and also invoke a ControlScript that adds the offending client to a blocklist IP group, attached to a network security policy, for rate shaping or blocking attackers.