diff --git a/doc/admin-guide-cloud-rst/source/objectstorage-monitoring.rst b/doc/admin-guide-cloud-rst/source/objectstorage-monitoring.rst index 6ed516d356..bd9fa48701 100644 --- a/doc/admin-guide-cloud-rst/source/objectstorage-monitoring.rst +++ b/doc/admin-guide-cloud-rst/source/objectstorage-monitoring.rst @@ -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 diff --git a/doc/admin-guide-cloud/section_object-storage-monitoring.xml b/doc/admin-guide-cloud/section_object-storage-monitoring.xml index d67c8d5d0e..105770c297 100644 --- a/doc/admin-guide-cloud/section_object-storage-monitoring.xml +++ b/doc/admin-guide-cloud/section_object-storage-monitoring.xml @@ -212,7 +212,7 @@ log_statsd_default_sample_rate = 1 update_stats(self, metric, amount, sample_rate=1) 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 increment(self, metric, sample_rate=1) Increments the given - counter metric by one. + counter 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 took the supplied number of + 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 + record a timing meter whose value is "now" minus an existing timestamp. diff --git a/doc/arch-design/compute_focus/section_architecture_compute_focus.xml b/doc/arch-design/compute_focus/section_architecture_compute_focus.xml index ad5b7a05f9..14188f056e 100644 --- a/doc/arch-design/compute_focus/section_architecture_compute_focus.xml +++ b/doc/arch-design/compute_focus/section_architecture_compute_focus.xml @@ -201,7 +201,7 @@ 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. diff --git a/doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml b/doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml index 83efce04f7..800f560b45 100644 --- a/doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml +++ b/doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml @@ -71,7 +71,7 @@ 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: diff --git a/doc/arch-design/generalpurpose/section_architecture_general_purpose.xml b/doc/arch-design/generalpurpose/section_architecture_general_purpose.xml index bfa470b674..dd63da4aab 100644 --- a/doc/arch-design/generalpurpose/section_architecture_general_purpose.xml +++ b/doc/arch-design/generalpurpose/section_architecture_general_purpose.xml @@ -174,7 +174,7 @@ 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. @@ -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 diff --git a/doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml b/doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml index f345dd2a0f..06b6d60da4 100644 --- a/doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml +++ b/doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml @@ -56,7 +56,7 @@ Monitoring OpenStack clouds require appropriate monitoring platforms to ensure errors are caught and managed appropriately. Specific - metrics that are critically important to monitor include: + meters that are critically important to monitor include: diff --git a/doc/arch-design/hybrid/section_tech_considerations_hybrid.xml b/doc/arch-design/hybrid/section_tech_considerations_hybrid.xml index 5d158c081f..449988abec 100644 --- a/doc/arch-design/hybrid/section_tech_considerations_hybrid.xml +++ b/doc/arch-design/hybrid/section_tech_considerations_hybrid.xml @@ -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. + might not use the same meter or even the same oversubscription rates. 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 diff --git a/doc/arch-design/introduction/section_methodology.xml b/doc/arch-design/introduction/section_methodology.xml index 05efa444ca..c8e3f6f1e6 100644 --- a/doc/arch-design/introduction/section_methodology.xml +++ b/doc/arch-design/introduction/section_methodology.xml @@ -60,7 +60,7 @@ Use the appropriate tools for the development effort. - Create better and more test metrics and test harnesses to + Create better and more test meters and test harnesses to support continuous and integrated development, test processes and automation. @@ -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. @@ -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 diff --git a/doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml b/doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml index 7a082d0dda..721d896b30 100644 --- a/doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml +++ b/doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml @@ -78,8 +78,8 @@ 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 diff --git a/doc/arch-design/storage_focus/section_architecture_storage_focus.xml b/doc/arch-design/storage_focus/section_architecture_storage_focus.xml index 92e79d04ef..9ef1588a3e 100644 --- a/doc/arch-design/storage_focus/section_architecture_storage_focus.xml +++ b/doc/arch-design/storage_focus/section_architecture_storage_focus.xml @@ -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. - This metric is related to scalability. + This meter is related to scalability. diff --git a/doc/common/samples/ceilometer.conf b/doc/common/samples/ceilometer.conf index 10fba3f447..33fc1f02d0 100644 --- a/doc/common/samples/ceilometer.conf +++ b/doc/common/samples/ceilometer.conf @@ -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 diff --git a/doc/config-reference/block-storage/drivers/vmware-vmdk-driver.xml b/doc/config-reference/block-storage/drivers/vmware-vmdk-driver.xml index 2b6339c268..dee3c0ef8a 100644 --- a/doc/config-reference/block-storage/drivers/vmware-vmdk-driver.xml +++ b/doc/config-reference/block-storage/drivers/vmware-vmdk-driver.xml @@ -409,7 +409,7 @@ lowest space utilization, where space utilization is defined by the (1-freespace/totalspace) - metric. + meters. These actions reduce the number of volume migrations while attaching the volume to instances. The volume must be migrated if the ESX host for the diff --git a/doc/config-reference/compute/section_compute-scheduler.xml b/doc/config-reference/compute/section_compute-scheduler.xml index 8ca96eec5d..8b8ecf7eb6 100644 --- a/doc/config-reference/compute/section_compute-scheduler.xml +++ b/doc/config-reference/compute/section_compute-scheduler.xml @@ -659,9 +659,9 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-
MetricsFilter - Filters hosts based on metrics + Filters hosts based on meters weight_setting. 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.
@@ -886,13 +886,13 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e- [metrics] weight_multiplier - Multiplier for weighting metrics. Use a + Multiplier for weighting meters. Use a floating-point value. [metrics] weight_setting - Determines how metrics are weighted. Use a + Determines how meters are weighted. Use a comma-separated list of metricName=ratio. For example: "name1=1.0, name2=-1.0" results in: name1.value * 1.0 + name2.value * @@ -902,7 +902,7 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e- [metrics] required - Specifies how to treat unavailable metrics: + Specifies how to treat unavailable meters: 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 MetricFilter to filter out hosts with unavailable - metrics. + meters. False—Treated as a @@ -925,7 +925,7 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e- [metrics] weight_of_unavailable If is set to False, - and any one of the metrics set by + and any one of the meters set by is unavailable, the diff --git a/doc/glossary/glossary-terms.xml b/doc/glossary/glossary-terms.xml index 5d6d8b0c93..cf905891f5 100644 --- a/doc/glossary/glossary-terms.xml +++ b/doc/glossary/glossary-terms.xml @@ -444,7 +444,7 @@ 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. @@ -7118,7 +7118,7 @@ - An Object Storage component that collects metrics. + An Object Storage component that collects meters. @@ -8365,7 +8365,7 @@ 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. diff --git a/doc/install-guide/section_ceilometer-cinder.xml b/doc/install-guide/section_ceilometer-cinder.xml index 3b6a5c2a5f..51767d957e 100644 --- a/doc/install-guide/section_ceilometer-cinder.xml +++ b/doc/install-guide/section_ceilometer-cinder.xml @@ -35,7 +35,7 @@ notification_driver = messagingv2 Use the cinder-volume-usage-audit command to - retrieve metrics on demand. For more information, see + retrieve meters on demand. For more information, see Block Storage audit script setup to get notifications. diff --git a/doc/install-guide/section_ceilometer-nova.xml b/doc/install-guide/section_ceilometer-nova.xml index 9d60e247c6..077e87de65 100644 --- a/doc/install-guide/section_ceilometer-nova.xml +++ b/doc/install-guide/section_ceilometer-nova.xml @@ -7,7 +7,7 @@ Configure the Compute service Telemetry uses a combination of notifications and an agent to - collect Compute metrics. Perform these steps on each compute node. + collect Compute meters. Perform these steps on each compute node. To install and configure the agent diff --git a/doc/install-guide/section_swift-storage-node.xml b/doc/install-guide/section_swift-storage-node.xml index 2e93c42127..6ff8d10135 100644 --- a/doc/install-guide/section_swift-storage-node.xml +++ b/doc/install-guide/section_swift-storage-node.xml @@ -228,7 +228,7 @@ pipeline = healthcheck recon account-server In the [filter:recon] section, configure - the recon (metrics) cache directory: + the recon (meters) cache directory: [filter:recon] ... recon_cache_path = /var/cache/swift @@ -270,7 +270,7 @@ pipeline = healthcheck recon container-server In the [filter:recon] section, configure - the recon (metrics) cache directory: + the recon (meters) cache directory: [filter:recon] ... recon_cache_path = /var/cache/swift @@ -312,7 +312,7 @@ pipeline = healthcheck recon object-server In the [filter:recon] section, configure - the recon (metrics) cache and lock directories: + the recon (meters) cache and lock directories: [filter:recon] ... recon_cache_path = /var/cache/swift diff --git a/doc/user-guide-admin/source/dashboard_manage_instances.rst b/doc/user-guide-admin/source/dashboard_manage_instances.rst index 432588f500..f58bfbb070 100644 --- a/doc/user-guide-admin/source/dashboard_manage_instances.rst +++ b/doc/user-guide-admin/source/dashboard_manage_instances.rst @@ -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 diff --git a/doc/user-guide-admin/source/dashboard_view_cloud_resources.rst b/doc/user-guide-admin/source/dashboard_view_cloud_resources.rst index f4b63b0f96..ca7d11d892 100644 --- a/doc/user-guide-admin/source/dashboard_view_cloud_resources.rst +++ b/doc/user-guide-admin/source/dashboard_view_cloud_resources.rst @@ -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). diff --git a/doc/user-guide/source/dashboard_launch_instances.rst b/doc/user-guide/source/dashboard_launch_instances.rst index 5653831205..50275e55fd 100644 --- a/doc/user-guide/source/dashboard_launch_instances.rst +++ b/doc/user-guide/source/dashboard_launch_instances.rst @@ -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`.