|
13 | 13 | - [Meter provider](#meter-provider)
|
14 | 14 | * [Obtaining a Meter](#obtaining-a-meter)
|
15 | 15 | * [Global Meter provider](#global-meter-provider)
|
16 |
| - + [Get the global MeterProvider](#get-the-global-metricprovider) |
17 |
| - + [Set the global MeterProvider](#set-the-global-metricprovider) |
| 16 | + + [Get the global MeterProvider](#get-the-global-meterprovider) |
| 17 | + + [Set the global MeterProvider](#set-the-global-meterprovider) |
18 | 18 | - [Instrument properties](#instrument-properties)
|
19 | 19 | * [Instrument naming requirements](#instrument-naming-requirements)
|
20 | 20 | * [Synchronous and asynchronous instruments compared](#synchronous-and-asynchronous-instruments-compared)
|
|
32 | 32 | * [Constructors](#constructors)
|
33 | 33 | - [Sets of labels](#sets-of-labels)
|
34 | 34 | * [Label performance](#label-performance)
|
35 |
| - * [Missing label keys](#missing-label-keys) |
36 | 35 | * [Option: Ordered labels](#option-ordered-labels)
|
37 | 36 | - [Synchronous instrument details](#synchronous-instrument-details)
|
38 | 37 | * [Synchronous calling conventions](#synchronous-calling-conventions)
|
@@ -82,14 +81,13 @@ understand their meaning. Standard implementations perform
|
82 | 81 | aggregation corresponding to the default interpretation for each kind
|
83 | 82 | of metric event.
|
84 | 83 |
|
85 |
| -Monitoring and alerting systems commonly use the data provided through |
86 |
| -metric events, after applying various [aggregations](#aggregations) |
87 |
| -and converting into various [exposition formats](#exposition-formats). |
88 |
| -However, we find that there are many other uses for metric events, |
89 |
| -such as to record aggregated or raw measurements in tracing and |
90 |
| -logging systems. For this reason, [OpenTelemetry requires a |
91 |
| -separation of the API from the SDK](../library-guidelines.md#requirements), |
92 |
| -so that different SDKs can be configured at run time. |
| 84 | +Monitoring and alerting systems commonly use the data provided through metric |
| 85 | +events, after applying various [aggregations](#aggregations) and converting into |
| 86 | +various exposition formats. However, we find that there are many other uses for |
| 87 | +metric events, such as to record aggregated or raw measurements in tracing and |
| 88 | +logging systems. For this reason, [OpenTelemetry requires a separation of the |
| 89 | +API from the SDK](../library-guidelines.md#requirements), so that different SDKs |
| 90 | +can be configured at run time. |
93 | 91 |
|
94 | 92 | ### Measurements
|
95 | 93 |
|
@@ -215,13 +213,13 @@ provider interface, or other language-specific support. Note that it
|
215 | 213 | is not necessary to use the global instance: multiple instances of the
|
216 | 214 | OpenTelemetry SDK may run simultaneously.
|
217 | 215 |
|
218 |
| -As an obligatory step, the API requires the caller to provide the name |
219 |
| -of the instrumenting library (optionally, the version) when obtaining |
220 |
| -a `Meter` implementation. The library name is meant to be used for |
221 |
| -identifying instrumentation produced from that library, for such |
222 |
| -purposes as disabling instrumentation, configuring aggregation, and |
223 |
| -applying sampling policies. See the specification on [obtaining a |
224 |
| -Tracer](../trace/api.md#obtaining-a-tracer) for more details. |
| 216 | +As an obligatory step, the API requires the caller to provide the name of the |
| 217 | +instrumenting library (optionally, the version) when obtaining a `Meter` |
| 218 | +implementation. The library name is meant to be used for identifying |
| 219 | +instrumentation produced from that library, for such purposes as disabling |
| 220 | +instrumentation, configuring aggregation, and applying sampling policies. See |
| 221 | +the specification on [TracerProvider](../trace/api.md#tracerprovider) for more |
| 222 | +details. |
225 | 223 |
|
226 | 224 | ### Aggregations
|
227 | 225 |
|
|
0 commit comments