Jump to: navigation, search


< Monasca
Revision as of 15:57, 30 January 2015 by Roland Hochmuth (talk | contribs) (Events API)


Events processing in Monasca will be capable of receiving receiving incoming events, transforming them, storing them and processing them. The processing consists of defining filters on events and grouping them together based on fields in the event. Fire and expire conditions can be defined that results in notifications being invoked, similar to how actions are defined for alarm definitions.

An example use case is to send OpenStack "instance" events to the API. A transform on the events would be defined that reduces the number of supplied fields to a more meaningful number and normalizes the data.

Events API


  • POST /v2.0/events: Publish an event.
  • GET /v2.0/events/{event_id}: Get an event with the specific event ID.
  • GET /v2.0/events: List events.


  • POST /v2.0/transforms: POST a transform
  • GET /v2.0/transforms: List transform
  • GET /v2.0/transforms/{transform_id}
  • DELETE /v2.0/transforms/{transform_id}


  • POST /v2.0/pipeline: Creates a pipeline with the following parameters in the JSON body
    • name (string(255), required) - A unique name of the pipeline. Note, the name must be unique.
    • description (string(255), optional) - A description of a pipeline
    • match_by - Criteria to match on
    • distinguish_by - Criteria to distinguish events on. For example, "instance_id".
    • expires - Time in milliseconds that a pipeline expires and the expire actions are invoked.
    • fire_actions ([string(50)], optional) - Array of notification method IDs that are invoked when the pipeline fires.
    • expire_actions ([string(50)], optional) - Array of notification method IDs that are invoked when the pipeline expires.
  • GET /v2.0/pipelines
  • GET /v2.0/pipelines/{pipeline_id}
  • DELETE /v2.0/pipelines/{pipeline_id}

Transformation Engine

Consumes events from Kafka, transforms them, and publishes to Kafka.

Event Engine

Consumes transformed events from Kafka, and uses the Winchester pipeline to process them.


No changes required.


  • Add Support for multi-tenancy
  • Dynamically update pipelines.
  • Add and delete pipeline definitions at run-time. Currently, the Winchester pipelines needs to be created at start-up time.
    • Supply pipeline definitions in methods, not yaml files. Winchester currently reads the pipeline configuration information from yaml files at start-up time.
  • Create pipeline handler that publishes notification events such that the Notification Engine can consume them.

Notification Engine

Needs to be able to consume general events from the Threshold Engine or Winchester Pipeline Handler.

Threshold Engine

Update to generate more general alarm state transition events.


  • Initialize Winchester schemas
  • Initialize Monasca transforms and pipeline schemas.


Look into creating a demo of a pipeline handler using Iron.IO.