Merge branch 'main' into gcp-cloud-run-service-version

specification/logs/bridge-api.md

@@ -111,9 +111,7 @@ The `Logger` MUST provide functions to:
 
 #### Emit a LogRecord
 
-`LogRecord`s encapsulate the fields identified in the [`LogRecord`
-data model](data-model.md#log-and-event-record-definition) and are emitted to the processing pipeline using
-this API.
+The effect of calling this API is to emit a `LogRecord` to the processing pipeline.
 
 The API MUST accept the following parameters:
 

specification/metrics/semantic_conventions/README.md

@@ -18,6 +18,7 @@ linkTitle: Semantic Conventions
   * [Instrument Naming](#instrument-naming)
   * [Instrument Units](#instrument-units)
   * [Instrument Types](#instrument-types)
+  * [Consistent UpDownCounter timeseries](#consistent-updowncounter-timeseries)
 
 <!-- tocstop -->
 
@@ -205,3 +206,12 @@ like `Counter` or `UpDownCounter`. However, compliant implementations MAY use th
 like `Asynchronous Counter` or `Asynchronous UpDownCounter`.
 Whether implementations choose the synchronous type or the asynchronous equivalent is considered to be an
 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.