HPE Aruba Networking 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 HPE Aruba Networking 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 HPE Aruba NetworkingHPE Aruba Networking 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 HPE Aruba Networking 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 your HPE Aruba Networking Central account has MSP mode 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.

Acknowledging Alerts

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 in HPE Aruba Networking Central:

Web UI

1. Go to Alerts
2. Acknowledge all or acknowledge individual alerts from the list of Open Alerts

REST API

1. Get list of alerts with the List Notification API. This will return all open alerts and their id.
   API Endpoint: /central/v1/notifications
   API Method: GET
   Base URL: https://apigw-prod2.central.arubanetworks.com
   (Replace the Base URL with correct API Gateway)
   Request Header: 'Content-Type': 'application/json'; 'Authorization': 'Bearer <access-token>'

   📘

   Note

   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.

   Sample Response

   {
     "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
2. Using the id noted above, you can acknowledge the alert using Acknowledge Notification API
   API Endpoint: /central/v1/notifications/{id}
   API Method: POST
   API Parameters: 'notification_id': '<id>' Base URL: https://apigw-prod2.central.arubanetworks.com
   (Replace the Base URL with correct API Gateway)
   Request Header: 'Content-Type': 'application/json'; 'Authorization': 'Bearer <access-token>'

{
  "acknowledged": true
}

🚧

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.

If you would like to acknowledge multiple alerts with one API call, you can do so, with the Acknowledge Notifications by ID List API. This is an async operation.