Adds a note about not splitting UpDownCounter timeseries

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.