This topic contains the following sections:
Importing new events
The process consists of the following steps:
- Develop or configure an ETL that populates the dataset EVDAT by navigating to the Administration> ETL & SYSTEM TASKS > Add > Add ETL section of the Helix Capacity Optimization Console.
- Run the ETL.
- Configure the Event Manager to manage the new events.
- Run the Event Manager and check its results.
For steps 1 and 2, refer to Maintaining ETL tasks. For steps 3 and 4, refer to Managing events and associating them to metrics.
The lifecycle of a BMC Helix Capacity Optimization event is represented by the following key statuses:
- PENDING: The event is created and awaiting to be processed.
- INTERVENT: The first intervention on this event (for example, an incident that needs to be solved).
- RESOLUTION: The event is resolved (that is, closed).
This is a generic status set, whose purpose is not to describe in detail the transitions of the event, but only to identify significant transitions for event analysis and reporting.
According to these transitions, the following measured times are defined:
- Event pending time: Total time in pending status, even if the pending status has been reached more than one time.
- Event resolution time: Total time elapsed from start to resolution.
- Event intervent time: Total time elapsed from start to first intervention.
An ETL can load events that are traced in different ways:
- STATELESS: The event has not traversed the expected workflow (for example, pending-intervent-resolution). The only meaningful time stamp for this event is "instantaneous", and it is called EVENTS. Transition times (pending, resolution, intervent) are meaningless. Usually, this represents a planned maintenance or similar situation.
- STATE SUMMARY: The event has traversed the expected workflow (for example, pending-intervent-resolution) and was imported when closed. In this case, all defined times (pending, resolution, intervent) are calculated by the ETL and imported. EVENTS, INTERVENTTS, and RESOLUTIONS are used to represent all status timestamps. transitions.
- STATE TRANSITION: The event is traversing the expected workflow (for example, pending-intervent-resolution) but is still being processed. In this case, the STTRTS column indicates the status transition timestamp of the transition that a record is reporting, and the STTRSTA indicates the new status (PENDING,INTERVENT,RESOLVED). Based on transition records, the event is processed by BMC Helix Capacity Optimization calculating meaningful transition times.
The event tracing type is automatically detected based on the following policies:
- The event is STATELESS if the row has only EVENTS.
- The event is STATESUMMARY if the row has both EVENTS and RESOLUTIONS.
- The event is STATETRANSITION if the row has STTRTS, STTRSTA and status specific time stamps.
The following figure shows STATETRANSITION events status changes and the dataset columns to populate in order to enable status transitions:
Event Tracking Overview
The ETL must ensure different lookups:
- The lookup of the event itself, for which the DS_EVENTID column is used, which is important to avoid duplicates and to recognize the transitions of a specific event in STATETRANSITION mode.
- The lookup of a system, workload or time series with which the event must be associated (optional).
In particular, the second lookup type is important if the event is an incident that must be associated with the affected system. In this case, the ETL that imports the event is usually not responsible for creating or importing data about the system itself. However, the event will be automatically associated with the correct system, as that the ETL populates the column DS_SYSNM in the dataset using the correct lookup name of the system.
An Event Manager rule can be used to enable automatic association even if the lookup between the two data sources (events and monitoring) is slightly different.
The EVDAT dataset
Timestamp of the event or transition (YYYY-MM-DD HH:MI:SS).
Event intervention timestamp
Intervention timestamp of the event (YYYY-MM-DD HH:MI:SS).
Event resolution timestamp
Resolution timestamp of the event (YYYY-MM-DD HH:MI:SS).
Event pending timestamp
Pending timestamp of the event (YYYY-MM-DD HH:MI:SS).
Event identifier in the data source
Event unique identifier in the data source.
System name in the data source
The name of the system with which the event is associated, as in the data source.
Workload name in the data source
The name of the workload with which the event is associated, as in the data source.
Location name in the data source
The name of the location with which the event is associated, as in the data source.
Resource name in the data source
The name of the resource with which the event is associated, as in the data source.
Sub-resource name in the data source
The name of the sub-resource with which the event is associated, as in the data source.
Type of the event (see CKB:note)
Count of occurrencies
Count of occurrences
Event intervention time
Event intervention time, in seconds
Event pending time
Event pending time, in seconds
Event resolution time
Event resolution time, in seconds
Event class as classified in the data source
A classification label used in the data source to classify the event; can be more detailed compared to the event type.
A measurement of the service unavailability caused by this event; for example, 100% means that the incident has caused a total unavailability.
State transition status
State transition status
State transition timestamp
State transition time of the event (YYYY-MM-DD HH:MI:SS)
Automatic column, generated interpreting other columns according to tracing policies explained above.
EVENTTYPEID must be one of the available event types:
- 1 = Unplanned incident
- 2 = Planned generic
- 3 = Planned maintenance
- 4 = Planned change
- 5 = Unplanned problem
- 6 = Unplanned error
- 7 = Unknown
For a general introduction to macro-events and what they are used for in BMC Helix Capacity Optimization, see Events.
Log in or register to comment.