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:

event flow.png

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:

example subclasses_new hierarchy.png

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:


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: 

EventClassDiagram232.png

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. 

Best practice

You can add common purpose slots under any event class (except the read-only base Event class) and have the child classes inherit those slots. Although adding common slots under any class is possible, we recommend that you use the MonitorEvent class for adding common purpose slots.

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. 

Notes

  • Custom slots can be added under all the out-of-the-box classes except the base Event class. 
  • You can add, update, and delete event slots of custom classes. You can also delete custom event slots of out-of-the-box classes.
  • The out-of-the-box event classes can be updated but not deleted. However, the base Event class can neither be updated nor deleted. It is a read-only class.
  • Creating event class slots with the same name but different data types across multiple custom classes are not supported.
    For example, if the application slot is defined as a String in MyCustomClass, then it cannot be defined as an Integer in MyOtherClass.

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.