diff --git a/metrics-exporter-prometheus/src/lib.rs b/metrics-exporter-prometheus/src/lib.rs index b374d54..b39f682 100644 --- a/metrics-exporter-prometheus/src/lib.rs +++ b/metrics-exporter-prometheus/src/lib.rs @@ -322,7 +322,7 @@ impl Inner { /// A Prometheus recorder. /// /// This recorder should be composed with other recorders or installed globally via -/// [`metrics::set_boxed_recorder`][set_boxed_recorder]. +/// [`metrics::set_boxed_recorder`]. /// /// pub struct PrometheusRecorder { @@ -379,8 +379,9 @@ impl PrometheusBuilder { /// By default, the quantiles will be set to: 0.0, 0.5, 0.9, 0.95, 0.99, 0.999, and 1.0. This means /// that all histograms will be exposed as Prometheus summaries. /// - /// If buckets are set (via [`set_buckets`] or [`set_buckets_for_metric`]) then all histograms will - /// be exposed as summaries instead. + /// If buckets are set (via [`set_buckets`][Self::set_buckets] or + /// [`set_buckets_for_metric`][Self::set_buckets_for_metric]) then all histograms will be exposed + /// as summaries instead. pub fn set_quantiles(mut self, quantiles: &[f64]) -> Self { self.quantiles = parse_quantiles(quantiles); self diff --git a/metrics-exporter-tcp/src/lib.rs b/metrics-exporter-tcp/src/lib.rs index 337cf9a..e782a81 100644 --- a/metrics-exporter-tcp/src/lib.rs +++ b/metrics-exporter-tcp/src/lib.rs @@ -23,7 +23,7 @@ //! `proto/event.proto`. //! //! # Usage -//! The TCP exporter can be constructed by creating a [`TcpBuilder], configuring it as needed, and +//! The TCP exporter can be constructed by creating a [`TcpBuilder`], configuring it as needed, and //! calling [`TcpBuilder::install`] to both spawn the TCP server as well as install the exporter //! globally. //! diff --git a/metrics-util/src/layers/mod.rs b/metrics-util/src/layers/mod.rs index 427f8e8..f461300 100644 --- a/metrics-util/src/layers/mod.rs +++ b/metrics-util/src/layers/mod.rs @@ -1,4 +1,4 @@ -//! Layers are composable helpers that can be "layered" on top of an existing `Recorder` to enhancne +//! Layers are composable helpers that can be "layered" on top of an existing `Recorder` to enhance //! or alter its behavior as desired, without having to change the recorder implementation itself. //! //! As well, [`Stack`] can be used to easily compose multiple layers together and provides a diff --git a/metrics/src/common.rs b/metrics/src/common.rs index ddaff04..043d8ff 100644 --- a/metrics/src/common.rs +++ b/metrics/src/common.rs @@ -114,8 +114,8 @@ impl Unit { /// Gets the canonical string label for the given unit. /// - /// For example, the canonical label for Seconds` would be `s`, while for `Nanoseconds, it would - /// be `ns`. + /// For example, the canonical label for `Seconds` would be `s`, while for `Nanoseconds`, + /// it would be `ns`. /// /// Not all units have a meaningful display label and so may be empty. pub fn as_canonical_label(&self) -> &str { diff --git a/metrics/src/label.rs b/metrics/src/label.rs index 7619706..696eace 100644 --- a/metrics/src/label.rs +++ b/metrics/src/label.rs @@ -8,7 +8,7 @@ use alloc::vec::Vec; /// of when an where a metric are emitted. /// /// For example, in a web service, you might wish to label metrics with the user ID responsible for -/// the request currently being processed, or the request path being processedd. If a codepath +/// the request currently being processed, or the request path being processed. If a codepath /// branched internally -- for example, an optimized path and a fallback path -- you may wish to /// add a label that tracks which codepath was taken. #[derive(PartialEq, Eq, Hash, Clone, Debug)] diff --git a/metrics/src/lib.rs b/metrics/src/lib.rs index f38efde..36e7a98 100644 --- a/metrics/src/lib.rs +++ b/metrics/src/lib.rs @@ -14,14 +14,12 @@ //! - [`register_gauge!`] and [`gauge!`] for gauges //! - [`register_histogram!`] and [`histogram!`] for histograms //! -//! There is also an [`increment!`] macro, which is shorthand for incrementing a counter by one. -//! //! In order to register or emit a metric, you need a way to record these events, which is where //! [`Recorder`] comes into play. //! //! ## Recording //! The [`Recorder`] trait defines the interface between the registration/emission macros, and -//! exporters, which is we refer to concrete implementations of [`Recorder`]. The trait defines +//! exporters, which is how we refer to concrete implementations of [`Recorder`]. The trait defines //! what the exporters are doing -- recording -- but ultimately exporters are sending data from your //! application to somewhere else: whether it be a third-party service or logging via standard out. //! It's "exporting" the metric data somewhere else besides your application.