Update oslo.metrics spec
Clarify on exposition format and information schema as well as fixing typos. Change-Id: Ia777b889f608ad03c522def0b9faed45fb3d5f92
This commit is contained in:
Witek Bedyk
parent
71fe65ff6f
commit
1a097223e3
|
|
@ -7,7 +7,7 @@ This is a proposal to create a new library to collect metrics of oslo libraries.
|
|||
Proposed library mission
|
||||
=========================
|
||||
|
||||
The mission of oslo.metrics is exposing internal metrics infomation of oslo
|
||||
The mission of oslo.metrics is exposing internal metrics information of oslo
|
||||
libraries. OpenStack processes create a connection to other middleware using
|
||||
oslo library, e.g. oslo.messaging to connect another OpenStack process and
|
||||
oslo.db to connect DB. The oslo.messaging creates its own RPC protocol over the
|
||||
|
|
@ -18,7 +18,7 @@ admin and operator to monitor usage of oslo libraries is the goal of
|
|||
oslo.metrics.
|
||||
|
||||
The oslo.metrics supports metrics of the oslo.messaging's RPC as first goal.
|
||||
The metrics infomation of the RPC doesn't appear anywhere. For example, when
|
||||
The metrics information of the RPC doesn't appear anywhere. For example, when
|
||||
a user calls the Create New Instance API to Nova, there is no infomation about
|
||||
how many RPC calls are made, which RPC targets are used, and etc. And for another
|
||||
case, if operator adds 10 compute nodes to their OpenStack cluster, how may RPC
|
||||
|
|
@ -27,9 +27,9 @@ will be increased, and etc.
|
|||
Consuming projects
|
||||
==================
|
||||
|
||||
There are two type of cosumers. One is the OpenStack services, which use
|
||||
There are two type of consumers. One is the OpenStack services, which use
|
||||
oslo.messaging as its internal communication. Another is Monitoring systems,
|
||||
which consume the metcis exposed by the oslo.metrics.
|
||||
which consume the metrics exposed by the oslo.metrics.
|
||||
|
||||
Alternatives library
|
||||
====================
|
||||
|
|
@ -39,12 +39,12 @@ oslo.messaging can be a one of alternatives. However, the notification is
|
|||
also implemented over the RabbitMQ. It makes cross reference in the metrics
|
||||
so it's not good idea to do.
|
||||
|
||||
The rpc_monitor is also another alternatives. This library focuses on
|
||||
collecting oslo.messaging metrics, and exposes its metrics to Prometheus.
|
||||
The rpc_monitor has not been developed long time. And the oslo.metrics will
|
||||
support multi type of monioring system as an official library. So it's difficult
|
||||
to use the rpc_monitor itself. However, the goal of rpc_monitor is similar to
|
||||
the oslo.metrics's first goal. When implementing the oslo.metrics the Prometheus
|
||||
The rpc_monitor is also another alternatives. This library focuses on collecting
|
||||
oslo.messaging metrics, and exposes its metrics to Prometheus. The rpc_monitor
|
||||
has not been developed long time. And the oslo.metrics will support multi type
|
||||
of monitoring system as an official library. So it's difficult to use the
|
||||
rpc_monitor itself. However, the goal of rpc_monitor is similar to the
|
||||
oslo.metrics's first goal. When implementing the oslo.metrics the Prometheus
|
||||
support, it's better to consult the rpc_monitor's implementation.
|
||||
|
||||
Proposed adoption model/plan
|
||||
|
|
@ -56,7 +56,7 @@ The existing oslo libraries send original metrics information through
|
|||
a unix socket, then the oslo.metrics gathers the metrics information
|
||||
and exposes the data.
|
||||
|
||||
The oslo.metrics listens to unix sockets to recieve metrics data from
|
||||
The oslo.metrics listens to unix sockets to receive metrics data from
|
||||
each of the OpenStack processes. The reason oslo.metrics uses the socket
|
||||
is to collect messaging metrics information from multiple processes which
|
||||
runs on the same node. One metrics process represents one node or one
|
||||
|
|
@ -70,20 +70,24 @@ library.
|
|||
|
||||
If we have a control server, then both Neutron-Server and Nova-API running
|
||||
in the controller would share their metrics to one unix socket which can
|
||||
get data from other Openstack processes as well. The Unix Socket running
|
||||
in one Node would handle all openstack processes of that node
|
||||
get data from other OpenStack processes as well. The Unix Socket running
|
||||
in one Node would handle all OpenStack processes of that node
|
||||
|
||||
The oslo.messaging sends the RPC information one by one to oslo.metrics
|
||||
with oslo.metrics's format. All information sent by oslo.messaging are
|
||||
put together into one metrics data in oslo.metrics. Then oslo.metrics
|
||||
exposes the one data to any monitoring system.
|
||||
|
||||
The monitoring system is really depending on operator. So oslo.metrics
|
||||
exposes the data by common format. For example, Prometheus takes PULL
|
||||
approach to get a metrics. To support Prometheus, oslo.metrics exposes
|
||||
the metrics data over HTTP.
|
||||
The monitoring system is really depending on operator. So oslo.metrics exposes
|
||||
the data by common format. The de facto standard is `the Prometheus exposition
|
||||
format
|
||||
<https://prometheus.io/docs/instrumenting/exposition_formats/#text-based-format>`_.
|
||||
We decide to use this format and expose the metrics on the HTTP endpoint. It
|
||||
allows integration with most monitoring systems, like e.g. Prometheus or
|
||||
Monasca.
|
||||
|
||||
The data oslo.messaging sends to the oslo.metrics includes:
|
||||
The data oslo.messaging sends to the oslo.metrics includes but is not limited
|
||||
to:
|
||||
|
||||
* topic
|
||||
* namespace
|
||||
|
|
@ -93,9 +97,15 @@ The data oslo.messaging sends to the oslo.metrics includes:
|
|||
* timeout
|
||||
* type of call: call or cast
|
||||
* timestamp of the call
|
||||
* project_id
|
||||
|
||||
Hostname are added by oslo.metrics side.
|
||||
|
||||
.. note::
|
||||
|
||||
The actual information schema is WIP and can be changed during the
|
||||
implementation.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
+--------------+ +--------------+ +-------------+
|
||||
|
|
@ -121,13 +131,13 @@ Reviewer activity
|
|||
For the changes in oslo.messaging, the support from oslo.messaging core is needed.
|
||||
For the oslo.metrics, the member of Large Scale SIG could review the patches.
|
||||
|
||||
Perfomance Impact
|
||||
Performance Impact
|
||||
=================
|
||||
|
||||
The oslo.metrics requests oslo.messaing to send another information. This may
|
||||
cause a perfomance impact to the RPC request. After implementing first spec,
|
||||
this library should be tested how much the additional informaion sending cause
|
||||
perfomance impact.
|
||||
cause a performance impact to the RPC request. After implementing first spec,
|
||||
this library should be tested how much the additional information sending cause
|
||||
performance impact.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
|
@ -146,7 +156,7 @@ Work Items
|
|||
* Create a new library named oslo.metrics
|
||||
* The implementation includes unit tests and functional tests as well as its codes
|
||||
* Change oslo.messaging to support metrics sending
|
||||
* Investigation of perfomance impact of oslo.messaging RPC
|
||||
* Investigation of performance impact of oslo.messaging RPC
|
||||
|
||||
References
|
||||
==========
|
||||
|
|
@ -170,4 +180,3 @@ Revision History
|
|||
This work is licensed under a Creative Commons Attribution 3.0
|
||||
Unported License.
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue