Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copyedits of Concepts > Signals > Metrics #3194

Merged
merged 1 commit into from
Aug 17, 2023
Merged

Copyedits of Concepts > Signals > Metrics #3194

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 23 additions & 19 deletions content/en/docs/concepts/signals/metrics.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,10 +3,10 @@ title: Metrics
weight: 2
---

A **metric** is a **measurement** about a service, captured at runtime.
Logically, the moment of capturing one of these measurements is known as a
**metric event** which consists not only of the measurement itself, but the time
that it was captured and associated metadata.
A **metric** is a **measurement** of a service captured at runtime. The moment
of capturing a measurements is known as a **metric event**, which consists not
only of the measurement itself, but also the time at which it was captured and
associated metadata.

Application and request metrics are important indicators of availability and
performance. Custom metrics can provide insights into how availability
Expand All @@ -28,8 +28,9 @@ initialized for you.

## Meter

A Meter creates _metric instruments_, capturing measurements about a service at
runtime. Meters are created from Meter Providers.
A Meter creates [metric instruments](#metric-instruments), capturing
measurements about a service at runtime. Meters are created from Meter
Providers.

## Metric Exporter

Expand All @@ -39,14 +40,19 @@ open source or vendor backend of your choice.

## Metric Instruments

In OpenTelemetry measurements are captured by **metric instruments**. Such a
metric instrument is defined by a name, a kind, an optional unit and an optional
description. The name, unit and description of such an instrument are chosen by
the developer or defined via
In OpenTelemetry measurements are captured by **metric instruments**. A metric
instrument is defined by:

- Name
- Kind
- Unit (optional)
- Description (optional)

The name, unit, and description are chosen by the developer or defined via
[semantic conventions](/docs/specs/otel/metrics/semantic_conventions/) for
common ones like request or process metrics.
common ones like request and process metrics.

The instrument type is one of the following six:
The instrument kind is one of the following:

- **Counter**: A value that accumulates over time -- you can think of this like
an odometer on a car; it only ever goes up.
Expand All @@ -60,13 +66,11 @@ The instrument type is one of the following six:
collected once for each export. Could be used if you don't have access to the
continuous changes, but only to the aggregated value (e.g., current queue
size).
- **(Asynchronous) Gauge**: Measures a current value at the time it is read. An
example would be the fuel gauge in a vehicle. Gauges are _always_
asynchronous.
- **Histogram**: A histogram is a client-side aggregation of values, e.g.,
request latencies. A histogram is likely a good choice if you have a lot of
values, and are not interested in every individual value, but a statistic
about these values (e.g., How many requests take fewer than 1s?)
- **Gauge**: Measures a current value at the time it is read. An example would
be the fuel gauge in a vehicle. Gauges are asynchronous.
- **Histogram**: A client-side aggregation of values, such as request latencies.
A histogram is a good choice if you are interested value statistics. For
example: How many requests take fewer than 1s?

## Aggregation

Expand Down