Adds a note about not splitting UpDownCounter timeseries (#3367)

This commit is contained in:
Trask Stalnaker 2023-04-18 09:14:04 -07:00 committed by GitHub
parent bb42c33451
commit bce030702e
1 changed files with 10 additions and 0 deletions

View File

@ -18,6 +18,7 @@ linkTitle: Semantic Conventions
* [Instrument Naming](#instrument-naming) * [Instrument Naming](#instrument-naming)
* [Instrument Units](#instrument-units) * [Instrument Units](#instrument-units)
* [Instrument Types](#instrument-types) * [Instrument Types](#instrument-types)
* [Consistent UpDownCounter timeseries](#consistent-updowncounter-timeseries)
<!-- tocstop --> <!-- tocstop -->
@ -205,3 +206,12 @@ like `Counter` or `UpDownCounter`. However, compliant implementations MAY use th
like `Asynchronous Counter` or `Asynchronous UpDownCounter`. like `Asynchronous Counter` or `Asynchronous UpDownCounter`.
Whether implementations choose the synchronous type or the asynchronous equivalent is considered to be an Whether implementations choose the synchronous type or the asynchronous equivalent is considered to be an
implementation detail. Both choices are compliant with this specification. implementation detail. Both choices are compliant with this specification.
### Consistent UpDownCounter timeseries
When recording `UpDownCounter` metrics, the same attribute values used to record an increment SHOULD be used to record
any associated decrement, otherwise those increments and decrements will end up as different timeseries.
For example, if you are tracking `active_requests` with an `UpDownCounter`, and you are incrementing it each time a
request starts and decrementing it each time a request ends, then any attributes which are not yet available when
incrementing the counter at request start should not be used when decrementing the counter at request end.