Event classification and formatting

Data collected from various sources are classified based on event classes and then formatted and represented as events. An event is a specific instance of an event class. 

Raw events contain information such as source, location, time stamp, and other important information about the event. This information is represented by event slots (name=value pairs). Every event class has a set of associated slots that can be used for processing events.

How are raw events ingested?

BMC Helix Operations Management  accepts and processes an incoming event if it matches the predefined event class definition. When an event is collected, the product compares the incoming event to the class definitions to determine the event type and to validate the event. In the event processing stage, as part of the event classification:

• Raw events with mandatory slot information are accepted. Events are deduplicated based on the out-of-the-box dedup slots. Topology is established between events in BMC Helix Operations Management  and service models in BMC Helix AIOps  based on the topology facets, and other factors. All this processing occurs based on slot facets.   
• Raw event data is stored in the form of name=value pairs with the appropriate data types based on the slot data types. 

The following image illustrates at a high-level how an event is ingested:

If an incoming event does not match the class definition,  BMC Helix Operations Management  performs these actions:

After an event is ingested, you can update the missing or incorrect details by running the API endpoint for updating an event.

How are events classified?

Event classes can be defined based on the event origin and usage. An event class can be subdivided into several subclasses to classify event information at a more detailed level. 

For example, one class of event might be Microsoft Windows operating system events. That event class can have several subclasses: application events, security events, and system events. Each subclass represents a common type of event that occurs, such as a network logon, that contains varying data values, such as a time stamp and the name of the host on which the logon occurred. The varying data values from a source event are stored in data fields called slots. 

The following image illustrates the hierarchy of the event classes described in the example:

Events flow through phases based on certain built-in rules. These rules specify which events are selected for processing and then determine how they are processed. The capability of dividing event classes at a detailed level allows the product to apply these built-in rules at a granular level and process the events. 

Events can also be processed after they are ingested by using event policies. To understand the order in which policies are evaluated and processed, see Event policy types and evaluation order.  

What are the types of event classes?

Event classes can be categorized into:

• Out-of-the-box classes: These event classes are available by default with  BMC Helix Operations Management :
  • Alarm event class
  • Anomaly event class
  • Event base event class
  • Incident Info event class
  • MonitorEvent event class
  • Patrol Event event class
  • Self-monitoring Event event class
    
    
• Custom classes: These classes can be defined to create new classifications of events in  BMC Helix Operations Management .
  For more information about creating custom classes and custom slots, see Managing events with REST APIs.
  
  
• Classes for BMC Helix Developer Tools  connectors: (applicable only if you are using  BMC Helix AIOps ) These classes are used for ingesting events coming from third-party products such as Dynatrace, SolarWinds, and so on. When you add an integration using one of the BMC Helix Developer Tools  connectors, event data collected from those connectors is made available in  BMC Helix Operations Management . However, note that events coming from TrueSight Operations Management  are generated as Alarm events.
  For more information, see  Integrating by using BMC Helix Developer Tools .

How does event class inheritance work?

The out-of-the-box event class definitions are organized in a multilevel hierarchical system where a superclass (or parent class) can be assigned subclasses (or child classes). Subclasses automatically derive definitions from the superclass. This behavior is called inheritance.

The following image represents the multilevel hierarchical system: 

The base Event class is an out-of-the-box superclass. Therefore, the base Event class definitions are inherited by all the other out-of-the-box subclasses. The MonitorEvent class available under the base Event class contains a set of common purpose slots that can be used across all the subclasses. 

A subclass inherits all the slot definitions of the superclass. A subclass can also contain additional new slot definitions (or custom slots) of its own and slot definitions that override a superclass slot definition. However, when a subclass slot overrides a superclass slot definition, it cannot have a data type that is different from the inherited slot, only different slot values. Custom classes can be defined under the base Event class and under the MonitorEvent class. Custom classes can have multiple subclasses. 

This multilevel hierarchical structure of classes provides the following advantages:

• Eliminates the need to create multiple blackout and event policies for each class separately. 
• Allows you to define multiple custom classes. Custom classes can be defined under any class, including other custom classes. 
• Allows you to define common custom slots that can be inherited across all the subclasses.