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:
|If an incoming event||Then|
Is of an unknown or undefined class
Does not contain values for mandatory custom slots
Matches a predefined class, but contains unknown or undefined slots
Matches a predefined class and slot names, but the slot data type is incorrect
Example: Alphabetical string data in an integer slot
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.
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:
- 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: 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 information about BMC Helix Developer Tools, see .
- Classes for BMC Helix Intelligent Integrations connectors: The IIMonitorEvent class and its subclasses are used for ingesting events coming from third-party products such as Aternity, AppDynamics, and so on. When you add an integration using one of the BMC Helix Intelligent Integrations connectors, event data collected from those connectors are made available in BMC Helix Operations Management.
For information about BMC Helix Intelligent Integrations, see .
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.
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.
- Custom slots can be added under all the out-of-the-box classes except the base Event class.
- Out-of-the-box slots and custom slots cannot be deleted. You can only add new slots and update existing slots under custom 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
applicationslot is defined as a String in
MyCustomClass, then it cannot be defined as an Integer in
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.