replace 'metrics' with 'meters' wherever it makes sense
Replaced 'metrics' with 'meters' in all contexts, excluding the metric system or where the term is used as name. Change-Id: If4c32dfe92c28a2079a485a6aec1d61c7b9999a1 Closes-Bug: #1446518
This commit is contained in:
Thomas Kaergel
parent
80deace154
commit
b0337e125c
@ -166,22 +166,22 @@ in ``self.logger``, has these new methods:
|
||||
Controller object is determined and instantiated for the request.
|
||||
|
||||
- ``update_stats(self, metric, amount, sample_rate=1)`` Increments the supplied
|
||||
metric by the given amount. This is used when you need to add or
|
||||
meter by the given amount. This is used when you need to add or
|
||||
subtract more that one from a counter, like incrementing
|
||||
"suffix.hashes" by the number of computed hashes in the object
|
||||
replicator.
|
||||
|
||||
- ``increment(self, metric, sample_rate=1)`` Increments the given counter
|
||||
metric by one.
|
||||
meter by one.
|
||||
|
||||
- ``decrement(self, metric, sample_rate=1)`` Lowers the given counter
|
||||
metric by one.
|
||||
meter by one.
|
||||
|
||||
- ``timing(self, metric, timing_ms, sample_rate=1)`` Record that the given metric
|
||||
- ``timing(self, metric, timing_ms, sample_rate=1)`` Record that the given meter
|
||||
took the supplied number of milliseconds.
|
||||
|
||||
- ``timing_since(self, metric, orig_time, sample_rate=1)`` Convenience method to record
|
||||
a timing metric whose value is "now" minus an existing timestamp.
|
||||
a timing meter whose value is "now" minus an existing timestamp.
|
||||
|
||||
Note that these logging methods may safely be called anywhere you have a
|
||||
logger object. If StatsD logging has not been configured, the methods
|
||||
|
||||
@ -212,7 +212,7 @@ log_statsd_default_sample_rate = 1</literallayout>
|
||||
<listitem>
|
||||
<para><code>update_stats(self, metric, amount,
|
||||
sample_rate=1)</code> Increments the supplied
|
||||
metric by the given amount. This is used when you
|
||||
meter by the given amount. This is used when you
|
||||
need to add or subtract more that one from a
|
||||
counter, like incrementing "suffix.hashes" by the
|
||||
number of computed hashes in the object
|
||||
@ -221,23 +221,23 @@ log_statsd_default_sample_rate = 1</literallayout>
|
||||
<listitem>
|
||||
<para><code>increment(self, metric,
|
||||
sample_rate=1)</code> Increments the given
|
||||
counter metric by one.</para>
|
||||
counter meter by one.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><code>decrement(self, metric,
|
||||
sample_rate=1)</code> Lowers the given counter
|
||||
metric by one.</para>
|
||||
meter by one.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><code>timing(self, metric, timing_ms,
|
||||
sample_rate=1)</code> Record that the given
|
||||
metric took the supplied number of
|
||||
meter took the supplied number of
|
||||
milliseconds.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><code>timing_since(self, metric, orig_time,
|
||||
sample_rate=1)</code> Convenience method to
|
||||
record a timing metric whose value is "now" minus
|
||||
record a timing meter whose value is "now" minus
|
||||
an existing timestamp.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
@ -201,7 +201,7 @@
|
||||
<para>Expandability refers to the overall ability of
|
||||
a storage solution to grow. A solution that expands to 50 PB is
|
||||
more expandable than a solution that only scales to 10PB.
|
||||
Note that this metric is related to, but different
|
||||
Note that this meter is related to, but different
|
||||
from, scalability, which is a measure of the solution's
|
||||
performance as it expands.</para>
|
||||
</listitem>
|
||||
|
||||
@ -71,7 +71,7 @@
|
||||
<para>OpenStack clouds require appropriate monitoring platforms that
|
||||
help to catch and manage errors adequately. Consider leveraging any
|
||||
existing monitoring systems to see if they are able to
|
||||
effectively monitor an OpenStack environment. Specific metrics that
|
||||
effectively monitor an OpenStack environment. Specific meters that
|
||||
are critically important to capture include:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
|
||||
@ -174,7 +174,7 @@
|
||||
<para>Sizing is an important
|
||||
consideration for a general purpose OpenStack cloud.
|
||||
The expected or anticipated number of instances that
|
||||
each hypervisor can host is a common metric used in
|
||||
each hypervisor can host is a common meter used in
|
||||
sizing the deployment. The selected server hardware
|
||||
needs to support the expected or anticipated instance
|
||||
density.</para>
|
||||
@ -288,7 +288,7 @@
|
||||
storage solutions with general purpose OpenStack
|
||||
cloud. A storage solution that expands
|
||||
to 50 PB is considered more expandable than a
|
||||
solution that only scales to 10 PB. This metric is
|
||||
solution that only scales to 10 PB. This meter is
|
||||
related to, but different, from scalability, which is a
|
||||
measure of the solution's performance as it expands. For example, the storage
|
||||
architecture for a cloud that is intended for a development
|
||||
|
||||
@ -56,7 +56,7 @@
|
||||
<title>Monitoring</title>
|
||||
<para>OpenStack clouds require appropriate monitoring platforms to
|
||||
ensure errors are caught and managed appropriately. Specific
|
||||
metrics that are critically important to monitor include:</para>
|
||||
meters that are critically important to monitor include:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
|
||||
@ -73,7 +73,7 @@
|
||||
experiences an unexpected increase in popularity. It is possible
|
||||
to define application requirements in terms of vCPU, RAM, bandwidth
|
||||
or other resources and plan appropriately. However, other clouds
|
||||
might not use the same metric or even the same oversubscription rates.</para>
|
||||
might not use the same meter or even the same oversubscription rates.</para>
|
||||
<para>Oversubscription is a method to emulate more capacity than
|
||||
may physically be present. For example, a physical
|
||||
hypervisor node with 32 GB RAM may host 24
|
||||
|
||||
@ -60,7 +60,7 @@
|
||||
<para>Use the appropriate tools for the development effort.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Create better and more test metrics and test harnesses to
|
||||
<para>Create better and more test meters and test harnesses to
|
||||
support continuous and integrated development, test processes
|
||||
and automation.</para>
|
||||
</listitem>
|
||||
@ -80,7 +80,7 @@
|
||||
cloud for the company's E-commerce website. This goal means planning for
|
||||
applications that will support thousands of sessions per second,
|
||||
variable workloads, and lots of complex and changing data. By
|
||||
identifying the key metrics, such as number of concurrent transactions
|
||||
identifying the key meters, such as number of concurrent transactions
|
||||
per second, size of database, and so on, it is possible to then build a
|
||||
method for testing the assumptions.</para>
|
||||
<formalpara>
|
||||
@ -91,7 +91,7 @@
|
||||
trajectory. If the organization is not ready to commit to an
|
||||
application or applications that can be used to develop user
|
||||
requirements, it needs to create requirements to build valid
|
||||
test harnesses and develop usable metrics. Once the metrics
|
||||
test harnesses and develop usable meters. Once the meters
|
||||
are established, as requirements change, it is easier to
|
||||
respond to the changes quickly without having to worry overly
|
||||
much about setting the exact requirements in advance. Think of
|
||||
|
||||
@ -78,8 +78,8 @@
|
||||
<para>An important consideration in running at massive scale is
|
||||
projecting growth and utilization trends in order to plan capital
|
||||
expenditures for the short and long term. Gather utilization
|
||||
metrics for compute, network, and storage, along with historical
|
||||
records of these metrics. While securing major
|
||||
meters for compute, network, and storage, along with historical
|
||||
records of these meters. While securing major
|
||||
anchor tenants can lead to rapid jumps in the utilization
|
||||
rates of all resources, the steady adoption of the cloud
|
||||
inside an organization or by consumers in a public
|
||||
|
||||
@ -64,7 +64,7 @@
|
||||
to grow. A storage solution that expands to 50 PB is
|
||||
more expandable than a solution that only scales to 10 PB.</para>
|
||||
<note>
|
||||
<para>This metric is related to scalability.
|
||||
<para>This meter is related to scalability.
|
||||
</para>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
@ -310,7 +310,7 @@
|
||||
#rest_notifier_max_retries = 0
|
||||
|
||||
# Period of evaluation cycle, should be >= than configured pipeline
|
||||
# interval for collection of underlying metrics. (integer value)
|
||||
# interval for collection of underlying meters. (integer value)
|
||||
# Deprecated group/name - [alarm]/threshold_evaluation_interval
|
||||
#evaluation_interval = 60
|
||||
|
||||
|
||||
@ -409,7 +409,7 @@
|
||||
lowest space utilization, where space utilization is
|
||||
defined by the
|
||||
<literal>(1-freespace/totalspace)</literal>
|
||||
metric.</para>
|
||||
meters.</para>
|
||||
<para>These actions reduce the number of volume migrations
|
||||
while attaching the volume to instances.</para>
|
||||
<para>The volume must be migrated if the ESX host for the
|
||||
|
||||
@ -659,9 +659,9 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-
|
||||
</section>
|
||||
<section xml:id="metricsfilter">
|
||||
<title>MetricsFilter</title>
|
||||
<para>Filters hosts based on metrics
|
||||
<para>Filters hosts based on meters
|
||||
<literal>weight_setting</literal>. Only hosts with the
|
||||
available metrics are passed so that the metrics weigher
|
||||
available meters are passed so that the metrics weigher
|
||||
will not fail due to these hosts.
|
||||
</para>
|
||||
</section>
|
||||
@ -886,13 +886,13 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-
|
||||
<tr valign="top">
|
||||
<td>[metrics]</td>
|
||||
<td><literal>weight_multiplier</literal></td>
|
||||
<td>Multiplier for weighting metrics. Use a
|
||||
<td>Multiplier for weighting meters. Use a
|
||||
floating-point value.</td>
|
||||
</tr>
|
||||
<tr valign="top">
|
||||
<td>[metrics]</td>
|
||||
<td><literal>weight_setting</literal></td>
|
||||
<td>Determines how metrics are weighted. Use a
|
||||
<td>Determines how meters are weighted. Use a
|
||||
comma-separated list of metricName=ratio. For
|
||||
example: "name1=1.0, name2=-1.0" results in:
|
||||
<literal>name1.value * 1.0 + name2.value *
|
||||
@ -902,7 +902,7 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-
|
||||
<tr valign="top">
|
||||
<td>[metrics]</td>
|
||||
<td><literal>required</literal></td>
|
||||
<td><para>Specifies how to treat unavailable metrics:<itemizedlist>
|
||||
<td><para>Specifies how to treat unavailable meters:<itemizedlist>
|
||||
<listitem>
|
||||
<para>True—Raises an
|
||||
exception. To avoid the raised
|
||||
@ -910,7 +910,7 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-
|
||||
scheduler filter
|
||||
<literal>MetricFilter</literal> to
|
||||
filter out hosts with unavailable
|
||||
metrics.</para>
|
||||
meters.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False—Treated as a
|
||||
@ -925,7 +925,7 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-
|
||||
<td>[metrics]</td>
|
||||
<td><literal>weight_of_unavailable</literal></td>
|
||||
<td>If <option>required</option> is set to False,
|
||||
and any one of the metrics set by
|
||||
and any one of the meters set by
|
||||
<option>weight_setting</option> is
|
||||
unavailable, the
|
||||
<option>weight_of_unavailable</option>
|
||||
|
||||
@ -444,7 +444,7 @@
|
||||
<glossdef>
|
||||
<para>The daemon, worker, or service that a client communicates with
|
||||
to access an API. API endpoints can provide any number of services,
|
||||
such as authentication, sales data, performance metrics, Compute VM
|
||||
such as authentication, sales data, performance meters, Compute VM
|
||||
commands, census data, and so on.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
@ -7118,7 +7118,7 @@
|
||||
</indexterm>
|
||||
|
||||
<glossdef>
|
||||
<para>An Object Storage component that collects metrics.</para>
|
||||
<para>An Object Storage component that collects meters.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
@ -8365,7 +8365,7 @@
|
||||
|
||||
<glossdef>
|
||||
<para>A Compute component that, along with the notification system,
|
||||
collects metrics and usage information. This information can be used
|
||||
collects meters and usage information. This information can be used
|
||||
for billing.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
@ -35,7 +35,7 @@ notification_driver = messagingv2</programlisting>
|
||||
</step>
|
||||
<step>
|
||||
<para>Use the <command>cinder-volume-usage-audit</command> command to
|
||||
retrieve metrics on demand. For more information, see
|
||||
retrieve meters on demand. For more information, see
|
||||
<link xlink:href="http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-cinder-audit-script.html"
|
||||
><citetitle>Block Storage audit script setup to get notifications</citetitle></link>.</para>
|
||||
</step>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Configure the Compute service</title>
|
||||
<para>Telemetry uses a combination of notifications and an agent to
|
||||
collect Compute metrics. Perform these steps on each compute node.</para>
|
||||
collect Compute meters. Perform these steps on each compute node.</para>
|
||||
<procedure>
|
||||
<title>To install and configure the agent</title>
|
||||
<step>
|
||||
|
||||
@ -228,7 +228,7 @@ pipeline = healthcheck recon account-server</programlisting>
|
||||
</step>
|
||||
<step>
|
||||
<para>In the <literal>[filter:recon]</literal> section, configure
|
||||
the recon (metrics) cache directory:</para>
|
||||
the recon (meters) cache directory:</para>
|
||||
<programlisting language="ini">[filter:recon]
|
||||
...
|
||||
recon_cache_path = /var/cache/swift</programlisting>
|
||||
@ -270,7 +270,7 @@ pipeline = healthcheck recon container-server</programlisting>
|
||||
</step>
|
||||
<step>
|
||||
<para>In the <literal>[filter:recon]</literal> section, configure
|
||||
the recon (metrics) cache directory:</para>
|
||||
the recon (meters) cache directory:</para>
|
||||
<programlisting language="ini">[filter:recon]
|
||||
...
|
||||
recon_cache_path = /var/cache/swift</programlisting>
|
||||
@ -312,7 +312,7 @@ pipeline = healthcheck recon object-server</programlisting>
|
||||
</step>
|
||||
<step>
|
||||
<para>In the <literal>[filter:recon]</literal> section, configure
|
||||
the recon (metrics) cache and lock directories:</para>
|
||||
the recon (meters) cache and lock directories:</para>
|
||||
<programlisting language="ini">[filter:recon]
|
||||
...
|
||||
recon_cache_path = /var/cache/swift
|
||||
|
||||
@ -57,7 +57,7 @@ Track usage
|
||||
|
||||
Use the Overview category to track usage of instances for each project.
|
||||
|
||||
You can track costs per month by showing metrics like number of VCPUs,
|
||||
You can track costs per month by showing meters like number of VCPUs,
|
||||
disks, RAM, and uptime of all your instances.
|
||||
|
||||
#. Log in to the dashboard and choose the admin project from the CURRENT
|
||||
|
||||
@ -39,5 +39,5 @@ View resource statistics
|
||||
networks, subnets, routers, ports, and floating IPs, per tenant (project).
|
||||
|
||||
* :guilabel:`Stats` tab to view a multi-series line chart with user-defined
|
||||
metrics. You group by project, define the value type (min, max, avg, or sum),
|
||||
meters. You group by project, define the value type (min, max, avg, or sum),
|
||||
and specify the time period (or even use a calendar to define a date range).
|
||||
|
||||
@ -185,7 +185,7 @@ Track usage for instances
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can track usage for instances for each project. You can track costs
|
||||
per month by showing metrics like number of vCPUs, disks, RAM, and
|
||||
per month by showing meters like number of vCPUs, disks, RAM, and
|
||||
uptime for all your instances.
|
||||
|
||||
#. Log in to the dashboard, choose a project, and click :guilabel:`Overview`.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user