ems (Event Management Service)

This article describes the Event Management Service (ems) probe available in CA Unified Infrastructure Management. You can use the ems probe to store and administer alarm messages in your CA UIM environment. The ems probe can also be used with the nas probe.
For information about deploying ems and configuring routing rules, see the topic ems Probe Deployment and Configuration.
Architecture Overview
The following diagram shows the basic architecture of the ems probe and its associated components:
EMS Architecture
EMS Architecture
As of ems v10.17, there is a change to the architecture and flow for ems and related probes. Previously, ems alarms were stored only in an embedded DB. From ems v10.17 they continue to be stored to the embedded DB, and are also synchronized to the following tables in the UIM database. 
ems 10.17 Architecture flow
ems 10.17 Architecture flow
How Alarms Flow to ems
  1. Probes generate legacy alarms that are intended for the nas probe.
  2. The Alarm Routing Service within the trellis probe receives and routes the legacy alarms.
  3. The ems probe converts legacy alarms into events.
  4. The Event Manager within ems either suppresses events or forwards them to the Alarm Manager. The actions that are taken by the Event Manager are defined in the event rules (
  5. The Alarm Manager manages the generated alarms. The actions that are taken by the Alarm Manager are defined in the alarm rules (
  6. Active (open) alarms are stored in memory and preserved across restarts with a persistent cache.
    1. (ems 9.00 or later) Copies of the open alarms are also exported to the UIM database. 
  7. Closed alarms and event transactions are persisted locally.
  8. The ems Alarm API provides access to the alarms in both the ems and nas probes.
  9. Optionally, enhanced lifecycle events are generated on any 
     subject. (ems 9.00 or later) The Action Manager processes these lifecycle events. The actions that are taken by the Action Manager are defined in the action manager rules (
    1. (ems 9.00 or later) If necessary, the Action Manager uses an embedded Scheduler module to generate any user-defined schedules. 
  10. A publishing interface streams events to the UIM message bus for interested subscribers.
ems and nas
The ems and nas probes can coexist in the same CA UIM installation. You can set up routing rules that route specific alarms to either ems or nas. For more information about configuring routing rules, see the article ems Probe Deployment and Configuration.
As of CA UIM 8.5.1, the nas_api_service is contained within the ems probe. Because of this update, the ems probe is now required to view alarm data in USM. Also, the ems probe is now deployed automatically as part of CA UIM installations or upgrades. No reconfiguration of the nas probes in your environment is required as a result of this change.
A version of the nas_api_service is still contained within the trellis probe to maintain backwards compatibility with pre-8.5.1 ticketing gateway probes.
The following diagram shows the nas_api_service differences between pre-8.5.1 and 8.5.1 CA UIM installations.
nas and ems Component Comparison
The following table compares the components available in nas with the equivalent components in ems.
alarm_enrichment probe
Event Manager
nas probe
Alarm Manager and Action Manager
nas alarm transaction log (NAS_TRANSACTION_LOG table)
Event and alarm transaction logs
nas active alarm table (NAS_Alarms)
  • Active alarms repository
  • (introduced in ems 9.00) ems_alarm
nas transaction summary table (NAS_TRANSACTION_SUMMARY)
Historic alarms repository
ems versions 8.47 or earlier do not write data to a database. Event and alarm transaction logs, active alarms, and historic alarms are written to the local file system.
As of ems version 9.00, open alarms are exported to the UIM database by default. Open ems alarms are stored in the ems_alarm table.
(ems or later) Note: 
The uim_alarm_view available in the UIM database is a union between the NAS_Alarms table and the ems_alarm table.
Events and Alarms
All messages sent to the nas probe are considered alarms (also known as "nas legacy alarms"). However, the ems probe uses separate constructs for alarms and events. A separation between events and alarms allows you to configure:
  1. A set of actions to take when an event arrives.
  2. A set of actions that determine when an alarm is created. 
  3. A set of actions for each step in the lifecycle of each alarm
The following table summarizes the difference between events and alarms in ems.
Analogous to unprocessed nas alarms
Analogous to processed nas alarms
Managed using the internal ems Event Manager
Managed using the ems internal Alarm Manager
ems Events
Events are records of incidents that occur at a particular moment in time. Events are similar to unprocessed nas alarm messages. Events are:
  • Typed
  • Immutable
  • Stateless
In ems, events are managed by the event manager and written to an event transaction log.
Legacy alarm messages that are sent from probes or the baseline_engine probe are converted to events by the Legacy Alarm Manager within the ems probe.
ems Alarms
Alarms are managed objects that represent a lifecycle of incidents over time. While the ems probe processes events at a single point in time, alarms go through a lifecycle that includes:
  1. The opening of the alarm
  2. An increase or decrease in the alarm severity.
  3. The reassignment of the alarm
  4. The closing of the alarm
In ems, an internal alarm manager generates alarms. Open or active alarms are maintained in an alarm repository. Closed alarms are moved to a historical repository. You can view and manage ems alarms in USM.
Event Flow in UIM
In previous versions of UIM, alarm messages from probes were sent across the message bus and intercepted by the alarm_enrichment probe. The alarm_enrichment probe would then rename the alarm messages "alarm2" and send them to the nas probe for further processing. The nas probe would then store the message information in the nas and UIM databases.
When using CA UIM with ems, the Alarm Routing Service is responsible for routing legacy alarm messages to ems, nas, or both. When the legacy alarm messages reach ems, a legacy alarm manager within ems converts the nas legacy alarms into events. The converted events are then sent to the event manager contained within the ems probe. The event manager processes the events and performs any necessary event enrichment. If event rules indicate that an event results in an alarm, the event manager sends the enriched event to the ems alarm manager. The ems events are stored locally in .csv files. If you are using ems version 9.00 or later, open ems events are also optionally stored in the UIM database. 
The ems Rule Catalogs
The ems probe uses several XML files, or 
 to define and act on events.
The Event Definition Catalog
The Event Definition Catalog defines the types of events that probes generate.
The Legacy Alarm Rule Catalog
The Legacy Alarm Rule catalog is used by the Legacy Alarm Manager to convert legacy nas alarms into ems events.
The Event Rule Catalog
The Event Rule Catalog contains the rules that are used to process events.
The Alarm Rule Catalog
The Alarm Rule Catalog manages ems alarms.
(ems 9.00 or Later) The Action Rule Catalog
The Action Rule Catalog manages the lifecycle of ems alarms, and supports scheduling actions.
Rule Processing
The processing flow for the rule catalogs is as follows:
  1. An event arrives over the UIM Message Bus.
  2. The correct rules to process the event are looked up in the Event Rule Catalog using an event type.
  3. The event is correlated using the correlation set in the rule.
  4. The correlated event is processed according to the rules.
  5. A separate rule instance is created for the combination of a correlated event and rule definition.
  6. Any actions that are associated with the rules are processed.
CA UIM provides a set of event definitions and rules that are ready to use. You can edit the Rule Catalog using either an XML or text editor to customize your rules.
Rule Instances
Each rule instance maintains its own state and can be traced individually. For example, if you have:
  • Two rules (R1 and R2) that are triggered by an event type (EC).
  • Two events with the event type EC, the first with correlation C1 and the second with correlation C2. 
Each event triggers rules R1 and R2. However, four separate rule instances are created because their correlations are different: 
  • (C1, R1)
  • (C1, R2)
  • (C2, R1)
  • (C2, R2)