Event Collection


Similar to usage collection, CPBM periodically can collect events from the cloud service and expose it to the end customer and operators from CPBM. While event log may be displayed in the resource UI of the service, CPBM offers a rich set of notification capabilities allow the end user to customize what events they would like to receive via one or more notification channels including email and SMS.

The EventCollector model is very similar to that of the UsageCollector. CPBM will periodically call the EventCollector to collect events in a normalized form for CPBM to store and operate upon. It is the EventCollector's responsibility to map events from the underlying cloud service to the normalized form prescribed by CPBM.

An implementation of the EventCollector SPI will be frequently (typically every few minutes) to collect events from the cloud service. Because it is being called frequently, EventCollectors should be fast as well as prudent in the set of events they expose. Typically, since CloudServices will be SSO enabled, local login events in the underlying service should, for example, be excluded. Otherwise, the event stream will get too noisy. Each call of the EventCollector will return an EventResultSet containing one batch of events.


The returned Event objects are enclosed in an EventResultSet to allow for batch operations. EventResultSet is defined as follows:
/**    * A result set returned for each run of the collector    */  public class EventResultSet {    /* The marker for the last record fetched. This is stored and passed back by CPBM        during the collection process to identify the last record fetched.    public String getMarker();    /* List of Event objects in this batch */    List<Event> getEvents();  }
The EventResultSet has the following elements:
  • marker: Marks the last record returned by the collector. This is an opaque handle that is passed back to the collector so it can continue collecting event data. This should never be null. When data is exhausted for a given run, the marker should return the input marker as the last marker as indication that there is no more data.
  • Event List: The returned list of Events. Calls to EventCollector should return Event in reasonable batch sizes. CPBM does not impose batch sizes except to offer guidance that this should be small to prevent memory overruns.


An Event is defined as follows:
public class Event {    enum Severity { CRITICAL, ALERT, INFO };    /* return the severity level */    public Severity getSeverity();      /* the time stamp of event generation */    public Date getCreatedAt();      /* Message code */    public String getCode();      /* handle of the user */    public String getUser();      /* Unique identifier of event in the Cloud service. Same format as the marker */    public String getId();      /* Event category as classified by the cloud service */    public String getCategory();      /* Dynamic attributes that represent the subject of this event */    Map<String, String> getAttributes();  }


The EventCollector SPI defines the interface connectors have to implement to support event collection. Note that this SPI is optional. It is defined as follows:
public interface EventCollector {    /* Returns a list of events collected from the Cloud Service. */    public EventResultSet collect(String startMarker, Date endDate);  }
The EventCollector is called periodically to collect event data from the cloud service. CPBM will schedule a job to collect event data at an operator defined frequency. In a given run, CPBM will repeatedly call the EventCollector until it exhausts all available data for the range specified between startMarker and endDate. When collect is called, the returned events list:
  • should start from after the startMarker and it must be generated on or before the passed endDate. For better performance, we recommend all implementations of EventCollector return usage data in small batches. The batch size should typically be under a hundred. Any subsequent call to EventCollector.collect() should return the next batch of Events. In case there is no Events left, return EventResultSet with the input startMarker as the marker and null events list. CPBM will continuously call EventCollector.collect() for a given endDate, until all data is exhausted for this time range.
  • In case of conflicting Event(i.e., duplicate id) CPBM will resolve the conflict by using the first record received.

The interaction between CPBM and Cloud Service for collecting events is shown the figure below

Figure 1. Event Collection Process

Have more questions? Submit a request


Adding comment, please wait....

Provide Feedback on Article:

Powered by Zendesk