open-telemetry
/
opentelemetry.io
mirror of https://github.com/open-telemetry/opentelemetry.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update metrics overview page (#2493)

This commit is contained in:
Georg Pirklbauer 2023-03-13 15:32:36 +01:00 committed by GitHub
parent d086d4d912
commit d9acfd25ea
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 26 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
content/en/docs/concepts/signals/metrics.md
View File

@ -14,22 +14,36 @@ indicators impact user experience or the business. Collected data can be used to
alert of an outage or trigger scheduling decisions to scale up a deployment alert of an outage or trigger scheduling decisions to scale up a deployment
automatically upon high demand. automatically upon high demand.
OpenTelemetry defines three _metric instruments_ today: OpenTelemetry defines six _metric instruments_ today which can be created
through the OpenTelemetry API:
- **counter**: a value that is summed over time -- you can think of this like an - **Counter**: A value that accumulates over time -- you can think of this like
odometer on a car; it only ever goes up. an odometer on a car; it only ever goes up.
- **measure**: a value that is aggregated over time. This is more akin to the - **Asynchronous Counter**: Same as the **Counter**, but is collected once for
trip odometer on a car, it represents a value over some defined range. each export. Could be used if you don't have access to the continous
- **observer**: captures a current set of values at a particular point in time, increments, but only to the aggregated value.
like a fuel gauge in a vehicle. - **UpDownCounter**: A value that accumulates over time, but can also go down
again. An example could be a queue length, it will increase and decrease with
the number of work items in the queue.
- **Asynchronous UpDownCounter**: Same as the **UpDownCounter**, but is
collected once for each export. Could be used if you don't have access to the
continous 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?)
In addition to the three metric instruments, the concept of _aggregations_ is an In addition to the metric instruments, the concept of _aggregations_ is an
important one to understand. An aggregation is a technique whereby a large important one to understand. An aggregation is a technique whereby a large
number of measurements are combined into either exact or estimated statistics number of measurements are combined into either exact or estimated statistics
about metric events that took place during a time window. The OpenTelemetry API about metric events that took place during a time window. The OTLP protocol
itself does not allow you to specify these aggregations, but provides some transports such aggreagated metrics. The OpenTelemetry API provides a default
default ones. In general, the OpenTelemetry SDK provides for common aggregations aggregation for each instrument which can be overridden using the Views API. The
(such as sum, count, last value, and histograms) that are supported by OpenTelemetry project aims to provide default aggregations that are supported by
visualizers and telemetry backends. visualizers and telemetry backends.
Unlike request tracing, which is intended to capture request lifecycles and Unlike request tracing, which is intended to capture request lifecycles and