Jump to: navigation, search

Ceilometer/blueprints/Ceilometer-specify-event-api

< Ceilometer‎ | blueprints
Revision as of 01:41, 25 May 2013 by Roland Hochmuth (talk | contribs) (Compute (Nova))

Stacky to Ceilometer Mapping

This section describe the proposed mapping from StackTach/Stacky to Ceilometer. This section was derived from reviewing the stacktack/urls.py and output from the stacky cli. Note, not all commands have a mapping yet, so a few more details need to be filled in.

StackTach Stacky Ceilometer Description
deployments stacky deployments NA Lists the environment names, such as rnd-a
events stacky events GET /v2/event_types/ Returns a list of all the event types.
hosts stacky hosts GET /v2/hosts/ Returns a list of all hosts.
uuids stacky uuid c0c0e50b-cdee-4fe9-9e4c-95ce6cf3fd94 GET /v2/events/ Returns a list of all events.
timings stacky timings compute.instance.create GET /v2/meters/(meter_id)/ Returns statistics for meters.
timings/instance_uuid Returns meters for instance ID.
summary stacky summary GET /v2/meters/statistics/ Lists the statistics, such as num, min, max, and avg for meters
requests stacky request req-0809cdd8-21f3-46c3-8803-4a2d9aa45436 GET /v2/events/ Lists the events associated with the specified resuest ID.
reports
reports/id
show/event_id stacky show 1562333 GET /v2/events/(event_id)/ Returns the details for the specified event ID.
watch/deployment_id
kpi/project_id
kpi/tenant_id

Measurements

This section describes the list of new meters to be added to support StackTach capabilities by extending the table defined at [Measurements](http://docs.openstack.org/developer/ceilometer/measurements.html).

Compute (Nova)

Name Type Unit Resource Origin Note
compute.instance.create.start Cumulative ns inst ID notification Number of create start notifications
compute.instance.create.end Cumulative ns inst ID notification Number of create end notifications
compute.instance.create Cumulative ns inst ID notification Total time to create instances
  • Probably a new meter will be added for each event type.
  • Additionally, a new meter will be added for events that have start/end pairs.
  • Note, that it will probably be the case that all events have at least one meter associated with it, such as in the case of a counter. However, events are not meters. Events may have more than one meter associated with it, and event pairs, as in the case of start/end pairs, may introduce additional events.
  • TBD: Complete the list of events based on the notificactions.

Resources

GET /v2/resources/

Returns the definitions of all the resources. There are no new changes required for StackTach integration.

GET /v2/resources/(resource_id)/

Returns the details for the specified resource_id. There are no new changes required for StackTach integration.

Hosts

This is a new api section for StackTach integration.

GET /v2/hosts/

Returns a list of all hosts. This is new for StackTach integration.

To simulate the Stack command "./stacky hosts" the http request "GET /v2/hosts" is invoked.

""Parameters:""

  • None
    • Return type:**
  • list(Host) - List of hosts.
  1. Events

This is a new api section for StackTach integration. The main goals of this section are for querying events.

    1. GET /v2/event_types/

Returns a list of all the event types. Examples of event types are as follows:

  • compute.instance.create.start
  • compute.instance.create.end
    • Return type:**
  • list(EventType) - List of event types. Do we really need a EventType or can we just return list(String).

To simulate the stacky command "./stacky.py events" the http request GET "/v2/event_types/" will return the list of event types.

    1. GET /v2/events/

Returns a list of all the events based on the query filter. Examples of events are as follows:

  • compute.instance.create.start
  • compute.instance.create.end

Using this query all the events for a specific resource, user, project, request ID, host, or time range can be requested.

To simulate the Stacky command "./stacky.py uuid c0c0e50b-cdee-4fe9-9e4c-95ce6cf3fd94" the http request "GET /v2/events" with a query filter of

``` {

   "field": "resource_id",
   "op": "eq",
   "value": "bd9431c1-8d69-4ad3-803a-8d4a6b89fd36"

} ``` can be used.

To simulate the Stack commane "./stacky.py request req-0809cdd8-21f3-46c3-8803-4a2d9aa45436" the http request "GET /v2/events" with a query filter of

``` {

   "field": "request_id",
   "op": "eq",
   "value": "req-0809cdd8-21f3-46c3-8803-4a2d9aa45436"

} ```

can be used.

    • Parameters:**
  • q (list(Query)) - Filter rules for the event names to be returned. By specifying different query filters all the queries that StackTach supports can be replicated. For example, to get all the events associated with a specific resource ID the following query filter can be defined:

``` {

   "field": "resource_id",
   "op": "eq",
   "value": "bd9431c1-8d69-4ad3-803a-8d4a6b89fd36"

} ```

    • Return type:**
  • list(Events) - List of events.
    1. GET /v2/events/(event_id)/

Returns detailed information about the specified event.

TBD. Fill in the details of an event.

To simulate the stacky command "./stacky.py show 1562333" the http request "GET /v2/events/1562333" can be used."

    1. GET /v2/events/traits/

Returns a list of all traits for events. Examples of traits include the following:

  • resource_id
  • project_id
  • user_id
  • request_id
  • host
  • event_type
  • timestamp


    1. GET /v2/events/(event_type)/traits/

Return a list of all traits given the specified event type.

  1. Meters
    1. GET /v2/meters/

Returns all known meters, … There are no new changes required for StackStack


    1. GET /v2/meters/statistics/

Returns statistics for meters. This is a new command for addressing StackTach integration.

    • Parameters:**
  • q (list(Query)) - Filter rules for the event names to be returned. By specifying different query filters all the queries that StackTach supports can be replicated. For example, to get all the events associated with a specific resource ID the following query filter can be defined:

``` {

   "field": "hostname",
   "op": "eq",
   "value": "hostname.domain"

} ```

    • Return type:**
  • list(Statistics) - List of statistics.

To simulate the stacky command "./stacky.py summary" the http request "GET v2/meters/statistics" can be used. This can be further refined by using query filters.

    1. GET /v2/meters/(meter_id)/

Returns the samples for the specified meter. There are no new changes required for StackTach integration.

To simulate the Stacky command "./stacky.py timings compute.instance.create" the http request "GET /v2/events" with a query filter of

``` {

   "field": "event_type",
   "op": "eq",
   "value": "compute.instance.create"

}

If no query filter is specified a list of all meters will be returned for resources for which the specfied meter_id is valid.

    1. GET /v2/meters/(meter_id)/statistics/

Returns the statistics for the specified meter, such as min, max, avg. There are no new changes required for StackTach integration.

    • Parameters:**
  • q (list(Query)) - Filter rules for the event names to be returned. By specifying different query filters all the queries that StackTach supports can be replicated. For example, to get all the events associated with a specific resource ID the following query filter can be defined:

``` {

   "field": "hostname",
   "op": "eq",
   "value": "hostname.com.com"

} ```

    • Return type:**
  • list(Statistics) - List of statistics.


  1. Samples and Statistics
    1. Meter

One category of measurements.

    • request_id:** An optional field that specifies the request ID if valid.
    1. Sample

A single measurement for a given meter and resource.

    • request_id:** An optional field that specifies the request ID if valid.
    1. Statistics

Computed statistics for a query.

    • request_id:** An optional field that specifies the request ID if valid.
  1. Filtering Queries

There are no changes required for StackTach integration. The queries need to support the following fieldes for StackTach integration:

  • resource_id
  • project_id
  • user_id
  • host
  • timestamp

Several additional fields to address StackTach integration are as follows:

  • request_id
  • event_type


  1. Hosts
    1. Host

A desription of a host. TBD

  • Do we really need a Host or should we just use a String.
  1. Events

This section is new for the StackTack integration.

    1. EventType

A decription of an event type. TBD.

  • Do we really need a EventType or should we just use a String.
    1. Event

A description of an event. Need to specify all the details of an Event. Note, events will can be very specific. For example VM lifecycle events have Task State, Build State, ...