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 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.
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
The alert framework sends out two types of notifications:
Firing: The alert condition is currently manifesting.
Resolved: The alert condition is no longer manifesting.
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.
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:
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.