You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: specification/metrics/sdk.md
+90
Original file line number
Diff line number
Diff line change
@@ -255,6 +255,79 @@ active span](../trace/api.md#context-interaction)).
255
255
+------------------+
256
256
```
257
257
258
+
## Exemplars
259
+
260
+
An [Exemplar](./datamodel.md#exemplars) is a recorded measurement that exposes
261
+
the following pieces of information:
262
+
263
+
- The `value` that was recorded.
264
+
- The `time` the measurement was seen.
265
+
- The set of [Attributes](../common/common.md#attributes) associated with the measurement not already included in a metric data point.
266
+
- The associated [trace id and span id](../trace/api.md#retrieving-the-traceid-and-spanid) of the active parent [Span within Context](../trace/api.md#determining-the-parent-span-from-a-context) of the measurement.
267
+
268
+
A Metric SDK MUST provide a mechanism to sample `Exemplar`s from measurements.
269
+
270
+
A Metric SDK MUST allow `Exemplar` sampling to be disabled. In this instance the SDK SHOULD not have memory overhead related to exemplar sampling.
271
+
272
+
A Metric SDK MUST sample `Exemplar`s only from measurements within the context of a sampled trace BY DEFAULT.
273
+
274
+
<!-- TODO: The wording of this is completely dependend on the Aggreagor specification. -->
275
+
A Metric SDK MUST allow exemplar sampling to leverage the configuration of a metric aggregator. For example,
276
+
Exemplar sampling of histograms should be able to leverage bucket boundaries.
277
+
278
+
<!-- Note: I'm fine dropping these interfaces for the first release. -->
279
+
A Metric SDK SHOULD provide extensible hooks for Exemplar sampling, specifically:
280
+
281
+
-`ExemplarFilter`: filter which measurements can become exemplars
282
+
-`ExemplarReservoir`: determine how to store exemplars.
283
+
284
+
### Exemplar Filter
285
+
286
+
The `ExemplarFilter` interface MUST provide a method to determine if a
287
+
measurement should be sampled.
288
+
289
+
This interface SHOULD have access to:
290
+
291
+
- The value of the measurement.
292
+
- The `Attributes` of the measurment.
293
+
- the `Context` of the measuremnt.
294
+
- The timestamp of the measurement.
295
+
296
+
See [Defaults and Configuration](#defaults-and-configuration) for built-in
297
+
filters.
298
+
299
+
### Exemplar Reservoir
300
+
301
+
The `ExemplarReservoir` interface MUST provide a method to offer measurements
302
+
to the reservoir and another to collect accumulated Exemplars.
303
+
304
+
The "offer" method SHOULD accept measurements, including:
305
+
306
+
- value
307
+
-`Attributes`
308
+
-`Context`
309
+
- timestamp
310
+
311
+
The "offer" method SHOULD have the ability to pull associated trace and span
312
+
information without needing to record full context. In other words, current
313
+
span context and baggage can be inspected at this point.
314
+
315
+
The "offer" method does not need to store all measurements it is given and
316
+
MAY further sample beyond the `ExemplarFilter`.
317
+
318
+
The "collect" method MUST return accumulated `Exemplar`s.
319
+
320
+
These `Exemplar`s MUST have their attributes filtered by an aggregator
321
+
(or after the aggregator) when generating final Metric data points to ensure a
322
+
complete view of the attributes from the original measurement. This does not
323
+
need to be part of the `ExemplarReservoir` interface, but SDKs may choose to
324
+
include it.
325
+
326
+
<!-- Note: ok to remove this, but it's not a hard requirement.-->
327
+
The `ExemplarReservoir` SHOULD avoid allocations when sampling exemplars.
328
+
329
+
<!-- TODO: Should we propose default/simple implementations? -->
330
+
258
331
## MetricExporter
259
332
260
333
`MetricExporter` defines the interface that protocol-specific exporters MUST
@@ -308,3 +381,20 @@ Push Metric Exporter sends the data on its own schedule. Here are some examples:
308
381
Pull Metric Exporter reacts to the metrics scrapers and reports the data
309
382
passively. This pattern has been widely adopted by
310
383
[Prometheus](https://prometheus.io/).
384
+
385
+
## Defaults and Configuration
386
+
387
+
And SDK MUST provide the following configuration parameters for Exemplar
0 commit comments