From ad7926365eb33ee811424c72c0009a0ddd351d09 Mon Sep 17 00:00:00 2001 From: Ruby Loo Date: Thu, 11 Aug 2016 23:09:12 -0400 Subject: [PATCH] Minor updates to metrics documentation This is a follow up to Ic08d4ff78b6fb614b474b956a32eac352a14262a. It enhances an example, fixes a spelling error, and modifies some sentences for better readability. Change-Id: Icfc89edd426ddee6a93be40c5b2f56d9d78fbd0c --- doc/source/metrics.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/source/metrics.rst b/doc/source/metrics.rst index baade79f4..8d960dcb5 100644 --- a/doc/source/metrics.rst +++ b/doc/source/metrics.rst @@ -26,18 +26,18 @@ ironic-lib every time. For example:: from ironic_lib import metrics_utils def my_method(): - with metrics_utils.get_metrics_logger(__name__).timer(): + with metrics_utils.get_metrics_logger(__name__).timer('my_method'): return _do_work() As a note, these metric collectors do work for custom HardwareManagers as -well, however, you may want to metric the portions of a method that determine -compatability separate from portions of a method that actually do work, in +well. However, you may want to metric the portions of a method that determine +compatibility separate from portions of a method that actually do work, in order to assure the metrics are relevant and useful on all hardware. Explicitly sending metrics ========================== A feature that may be particularly helpful for deployers writing custom -HardwareManagers is the ability to explicitly send metrics. As an example, +HardwareManagers is the ability to explicitly send metrics. For instance, you could add a cleaning step which would retrieve metrics about a device and ship them using the provided metrics library. For example::