Alarms

Alarms

Within MobiledgeX’s platform, an alarm is triggered by abnormal system behavior (an event) or unexpected result.

Alarms are classified into one of four severity levels of severity based on the component's performance's nature and impact.

  • Critical: Requires immediate attention and reflects conditions that may affect an appliance's performance or signal the loss of a broad category of service. An example would be a network failure taking an entire cloudlet offline.
  • Major: Indicates conditions that should be addressed within 24 hours of the notification. An example would be an unexpected traffic class error.
  • Minor: Denotes performance that may be addressed at your convenience. An example would be a user that has not changed their account’s default password or a degraded disk.
  • Warning: Signifies conditions that may develop into an issue over time. For example, a software version mismatch.

Alerts

Alerts provide notifications of alarms that constitute an irregular performance so that issues can be proactively mitigated. For all Critical and Major alerts, a notification will be sent to the user. The notification will be sent either through Slack or email, depending on the preferred delivery method configured by the user. When the issue or condition is resolved, an additional notification is sent to the user indicating that the issue has been fixed.

Severity levels

Alert subscriptions can be filtered based on a severity level. Currently, you can select one of three severity levels.

  • Info: Normal operational messages that require no action.
  • Warning: May indicate that an error will occur if action is not taken
  • Error: Error conditions

Alert notifications

The alert framework sends out two types of notifications:

  • Firing: The alert condition is currently manifesting.
  • Resolved: The alert condition is no longer manifesting.

AlertManager

The AlertManager is a global component of the MobiledgeX’s product and is responsible for distributing alerts to application owners. Alarms are consolidated at the regional level, where each regional controller receives alarms via a notification.

The image below illustrates the AlertManager workflow. A user can create an alert receiver and set up their preferred notification method through the Edge-Cloud Console. Once an alert receiver is created, the receiver is pushed to the MobiledgeX Platform. When an alarm is triggered, the Alert Manager within the platform sends an alert notification to the user for mitigation. Currently, alert notifications are sent only for application instance(s) that are down-AppInstDown.

Alert Receiver Workflow
Alert Receiver Workflow

Alert Management

The MobiledgeX platform provides a flexible alerting interface that includes the following:

  • RBAC support for users, roles, and organizations that control access to alerts. Any users having the ability to view a resource [that generates an alert] can create or delete an alert receiver for the resource. However, since alerts are raised and cleared by the platform, users cannot create custom alerts.

  • Flexibility to manage the delivery of alerts to different “alert receivers” based on user configuration. We currently support the delivery of alerts to your Slack or email account.

Alert Receiver Types

Alerts may be generated from multiple components within the environment, such as app instances or clusters. For example, an alert notification will be sent if an application instance goes down, or if you has anomalies due to the health check for a particular application.

There are several different alert receivers you can set up to receive a notification about your application instance. For example, if you want to receive notification with a specific application instance, you can specify the appname, app-org, and appvers. You can also monitor all of the application instances associated to a particular application from all the cloudlets by, again, specifying the appname, app-org, appvers.

To receive notification about all the application instances that are running on a particular cluster, specify cluster and cluster-org.

Here's an example of what an alert receiver setup may look like for an application instance:

name: DevOrgReceiver2  
type: email  
severity: errors  
user: mexadmin  
email: [email protected]  
appinst:  
  appkey:  
      organization: DevOrg  
      name: DevOrg SDK Demo  
      version: "1.0"  
    clusterinstkey:
      clusterkey:  
        name: AppCluster  
      cloudletkey:  
        organization: mexdev  
        name: localtest  
      organization: DevOrg  

Alert Receiver and MobiledgeX APIs

Alert Receivers are designed to be configurable via the MobiledgeX APIs, directly and through the mcctl utility program, providing flexibility for users integrating with their existing monitoring systems.

Action API Route
Create an Alert Receiver api/v1/auth/alertreceiver/create
Delete an Alert Receiver api/v1/auth/alertreceiver/delete
Show all Alert Receivers api/v1/auth/alertreceiver/show

For detailed AlertReceiver API examples, please refer to the MCCTL Reference Guide.

To set up alert receivers and notification methods through the console

While you can use the mcctl tool and the commands provided to set up your alerts and notification preferences, we recommend using the Edge-Cloud Console to set up your alert receivers for ease-of-use.

  1. Navigate to the Alert Receivers sub-menu and click the + plus sign. The Create Receiver screen opens.

Create Alert Receiver screen
Create Alert Receiver screen

  1. Additional fields appear depending on your selections. Populate all the required fields.

Additional Alert Receiver fields
Additional Alert Receiver fields

  1. Your new Alert Receiver will appear on the Alert Receivers page.

Alert Receiver screen
Alert Receiver screen

When you click the Alert icon, information about the alert is displayed.

Information about Alerts
Information about Alerts