Aruba Central, has the ability to report all types of alerts and events that occur in your network pertaining to device provisioning, configuration, and user management. You can enable and configure these alerts in the Alerts & Events pane in the Network Operations app within Aruba Central. While configuring these Alerts & Events, users have the option to enable Webhooks as a delivery method for when these alerts/events occur. This can be extremely useful when building automated event-driven workflows or integrating with other third-party applications.

📘

For more information regarding Alerts & Events as well as how to configure them, visit the Alerts & Events help documentation for Aruba Central.

When an Alert is configured to notify the user via Webhook, the alert is sent out as a JSON formatted string within an HTTP POST. The data in this JSON string contains information regarding the type of alert, the alerts priority, as well as other details and identifiers. There are several fields within the returned JSON, to see a sample of each Alert's returned JSON and its fields you can refer to the guides below:

• User Alerts
• Connectivity Alerts
• Access Point Alerts
• Switch Alerts
• Gateway Alerts

Here are just some of the available fields:

Webhooks Retry Policy

While creating or editing a Webhook, you can specify a retry policy for Alerts & Events sent by Aruba Central. You can use select one of three options:

• None - No retries needed
• Important - Up to 5 retries over 6 minutes
• Critical - Up to 5 retires over 32 hours

MSP mode Webhook configuration

When you're Aruba Central account has MSP enabled, you can globally configure alerts for all tenants under the account. If done so, all same alerts are configured for all tenants. This can be overridden by entering the tenant level and configuring more alerts for that particular tenant.

For example: If you have configured three Access Point alerts at the MSP level, then three Access Point alerts get configured for all the tenants. Let now assume you want to add two more alerts for one of those tenants; you can go and configure those two alerts at that tenant level. Therefore, you will have five alerts configured for a particular tenant. Any alert configured directly at the tenant level will always override the alert configured at the MSP level.

Alert State

When you receive a new alert that is forwarded to the configured Webhook, there exists a field titled state in the JSON string which denotes the state of the alert received. When the alert is new, the value will be Open. Certain alerts will automatically send a Webhook notification for the same incident but with the state set to Close to show that the original alert has been resolved. For example, the "Switch Disconnected" alert sends a notification to the Webhook when the switch initially disconnects with state: Open and a unique identifier. When the switch reconnects, the Webhook will receive another "Switch Disconnected" alert matching the original unique identifier with state: Close.

When an alert is acknowledged, no notification is sent to the Webhook and the state of the alert will be state: Open but a new field will exist in the payload titled acknowledged and it's value will be set to true.

To close the state of any alert (if not done automatically), you'll need to acknowledge the alert. Acknowledging an alert can be done using two methods:

1. Through Aruba Central Web UI:

• Go to Alerts
• Acknowledge all or acknowledge individual alerts from the list of Open Alerts

2. Through REST API

• Use List Notifications API to get all open alerts and their id
  API Endpoint: '/central/v1/notifications'
  Request Method: GET
  Request Headers:
  'Content-Type': 'application/json'; 'Authorization': 'Bearer <access-token>'
  Response Payload:

📘

If an alert is acknowledged, the List Notifications API will provide you a timestamp when the alert was acknowledged and the user who acknowledged it.

{
  "count": 1,
  "total": 84,
  "notifications": [
    {
      "id": "2",
      "severity": "Major",
      "settings_id": "AWLTCw983zA1xiLvI9DF",
      "timestamp": 1523958870,
      "group_name": "IAP 5GHz",
      "labels": [
        "dual_5GHz"
      ],
      "type": "AP disconnected",
      "acknowledged": true,
      "description": "AP with Name IAP_345_1 and MAC address c8:b5:ad:c3:b2:02 disconnected",
      "state": "Open",
      "acknowledged_by": "user1",
      "acknowledged_timestamp": 1523958870,
      "created_timestamp": 1523958870
    }
  ]
}

Note the id of the open alert your wish to close

• Use Acknowledge Notification API to acknowledge the alert using the noted id
  API Endpoint: '/central/v1/notifications/<id>''
  Request Method: POST
  Request Parameters:
  'notification_id': '<id>'
  Request Headers:
  'Content-Type': 'application/json'; 'Authorization': 'Bearer <access-token>'
  Request Payload:

{
  "acknowledged": true
}

• To acknowledge multiple alerts, use Acknowledge Notifications by ID List API

API Endpoint: '/central/v1/notiifications/<id>''
Request Method: POST
Request Headers:
'Content-Type': 'application/json'; 'Authorization': 'Bearer <access-token>'
Request Payload:

[
  "AWLTBOek6s45xx3BBzLAI",
  "AWLT32wqak6s2rcX3BBzL",
  "AWLTBOek621vfs2rcX3BB"
]

🚧

For auto-generated alerts like the above example of "Switch Disconnected", if the device comes back online and an alert with state as Close is generated, the List Notifications API will only return the alert with the state: Close when device reconnects and not the original alert. If the device has not reconnected, it will show the "Switch Disconnected" alert with state: Open.