Moab Web Services > API Documentation > System Events
System Events
The broad category of system events may be broken down into two subcategories: events and notification conditions.
Events
Events are created by many components in the system, but most events originate from Moab Workload Manager and Moab Web Services. Events can be created via the MWS interface or by being placed on the message queue. The ZeroMQ™ message queue libraries were introduced in Moab and MWS 7.5.0. The message queue is critical to service lifecycle functionality (see "Service lifecycle" in the Moab Cloud Suite Installation Guide).
In a typical system, Moab will communicate events to MWS via a "private" message queue, and then MWS will replicate the events on the "public" message queue, or the message queue that is available to subscribers with the correct secret keys. In some cases, such as those related to the MWS service lifecycle, MWS uses events to determine activities or capabilities that are available.
A typical message on the message queue may look like the following (sent with a topic of system.moab):
Sample message on message queue
------------------------------------
{
"body" : {
"associatedObjects" : [
{
"id" : "Moab",
"type" : "scheduler"
}
],
"code" : 16777619,
"eventDate" : "2014-02-28T10:57:21.000-0700",
"message" : "A scheduler iteration is ending.",
"origin" : "MSysMainLoop.c, MSysMainLoop, line 959"
},
"messageId" : "843269550",
"messageType" : "event",
"senderId" : "mwm@mwm-server",
"sentDate" : "2014-02-28T10:57:21.000-0700",
"ttl" : 3000
}
Notification Conditions
Notification Conditions are related to an event, but differ in three distinct areas:
- Notification conditions are a persistent condition of the system or a component rather than a single occurrence.
- They are ongoing rather than reoccurring, which is why they are generated from NotificationConditions.
- They may be observed many times, but the condition is always the same.
- A good test for this is if something "is" wrong rather than something "went" wrong.
- Notification conditions can be acted on to result in a resolved state, mean the administrator or user can and must take actions to "fix" the condition or problem.
- Notification conditions contain state information based on administrator or user input, meaning that they contain information about the condition (similar to events), but also contain the "status" of the administrator's view of the notification, whether it is currently open, dismissed, or ignored.
In general, questions may be asked to ascertain whether an event or a notification condition is the right fit for an occurrence. These questions, along with some sample situations, are provided below.
- Is the occurrence the root cause of a potentially ongoing condition?
- A VM migration failed because the VM's state was unknown. The root cause was that the state was unknown, not that the VM migration failed. Therefore, VM migration failed would be an event, while the unknown state would be a notification condition.
- A VM service provision fails because there are no hypervisors that satisfy the requirements. This would be an event. Note that there may be a notification related to this failure, such as a service template requires a feature that does not exist on any hypervisors in the system, but this would be distinctly detected and managed from the provision failure event.
- A request to MWS failed because the connection between Moab and MongoDB was misconfigured. The failed request may be represented as an event, but a notification condition should exists that the connection between Moab and MongoDB was down.
- Can an administrator or user affect the outcome of the occurrence?
- The outcome of a VM migration failing is in the past and cannot be changed by the administrator. However, the outcome of a future VM migration may be changed when the administrator resolves the root problem (such as VM state is unknown).
Related Topics