Merge "Replace 'metrics' with 'meters' in option and doc"
This commit is contained in:
commit
6c70765a4f
@ -40,7 +40,7 @@ OPTS = [
|
||||
default=60,
|
||||
help='Period of evaluation cycle, should'
|
||||
' be >= than configured pipeline interval for'
|
||||
' collection of underlying metrics.',
|
||||
' collection of underlying meters.',
|
||||
deprecated_opts=[cfg.DeprecatedOpt(
|
||||
'threshold_evaluation_interval', group='alarm')]),
|
||||
]
|
||||
|
@ -22,7 +22,7 @@
|
||||
Existing meters
|
||||
===============
|
||||
|
||||
For the list of existing metrics see the tables under the
|
||||
For the list of existing meters see the tables under the
|
||||
`Measurements page`_ of Ceilometer in the Cloud Administrator Guide.
|
||||
|
||||
.. _Measurements page: http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-measurements.html
|
||||
|
@ -12,14 +12,14 @@ single source to transform events into billable items which we
|
||||
label as "metering".
|
||||
|
||||
As the project started to come to life, collecting an
|
||||
`increasing number of metrics`_ across multiple projects, the OpenStack
|
||||
`increasing number of meters`_ across multiple projects, the OpenStack
|
||||
community started to realize that a secondary goal could be added to
|
||||
Ceilometer: become a standard way to collect metric, regardless of the
|
||||
Ceilometer: become a standard way to collect meter, regardless of the
|
||||
purpose of the collection. For example, Ceilometer can now publish information
|
||||
for monitoring, debugging and graphing tools in addition or in parallel to the
|
||||
metering backend. We labelled this effort as "multi-publisher".
|
||||
|
||||
.. _increasing number of metrics: http://docs.openstack.org/developer/ceilometer/measurements.html
|
||||
.. _increasing number of meters: http://docs.openstack.org/developer/ceilometer/measurements.html
|
||||
|
||||
Most recently, as the Heat project started to come to
|
||||
life, it soon became clear that the OpenStack project needed a tool to watch
|
||||
|
@ -30,8 +30,8 @@ Polling agent might be run either on central cloud management nodes or on the
|
||||
compute nodes (where direct hypervisor polling is quite logical).
|
||||
|
||||
The agent running on each compute node polls for compute resources
|
||||
usage. Each metric collected is tagged with the resource ID (such as
|
||||
an instance) and the owner, including tenant and user IDs. The metrics
|
||||
usage. Each meter collected is tagged with the resource ID (such as
|
||||
an instance) and the owner, including tenant and user IDs. The meters
|
||||
are then reported to the collector via the message bus. More detailed
|
||||
information follows.
|
||||
|
||||
@ -136,7 +136,7 @@ generates the appropriate sample objects to be sent to the collector.
|
||||
Adding new plugins
|
||||
------------------
|
||||
|
||||
Although we have described a list of the metrics Ceilometer should
|
||||
Although we have described a list of the meters Ceilometer should
|
||||
collect, we cannot predict all of the ways deployers will want to
|
||||
measure the resources their customers use. This means that Ceilometer
|
||||
needs to be easy to extend and configure so it can be tuned for each
|
||||
|
@ -313,7 +313,7 @@ Functional examples
|
||||
+++++++++++++++++++
|
||||
|
||||
The examples below are meant to help you understand how to query the
|
||||
Ceilometer API to build custom metrics report. The query parameters should
|
||||
Ceilometer API to build custom meters report. The query parameters should
|
||||
be encoded using one of the above methods, e.g. as the URL parameters or
|
||||
as JSON encoded data passed to the GET request.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user