Skip to content

Commit 7c83af6

Browse files
committed
First cut at exemplar spec.
1 parent d3619c5 commit 7c83af6

File tree

1 file changed

+90
-0
lines changed

1 file changed

+90
-0
lines changed

specification/metrics/sdk.md

+90
Original file line numberDiff line numberDiff line change
@@ -255,6 +255,79 @@ active span](../trace/api.md#context-interaction)).
255255
+------------------+
256256
```
257257

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+
258331
## MetricExporter
259332

260333
`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:
308381
Pull Metric Exporter reacts to the metrics scrapers and reports the data
309382
passively. This pattern has been widely adopted by
310383
[Prometheus](https://prometheus.io/).
384+
385+
## Defaults and Configuration
386+
387+
And SDK MUST provide the following configuration parameters for Exemplar
388+
sampling:
389+
390+
<!-- TODO: reservoir config?-->
391+
392+
| Name | Description | Default | Notes |
393+
|-----------------|---------|-------------|---------|
394+
| `OTEL_METRICS_EXEMPLAR_FILTER` | Filter for which measurements can become Exemplars. | `"WITH_SAMPLED_TRACE"` | |
395+
396+
Known values for `OTEL_METRICS_EXEMPLAR_FILTER` are:
397+
398+
- `"NONE"`: No measurements are eligble for exemplar sampling.
399+
- `"ALL"`: All measurements are eligible for exemplar sampling.
400+
- `"WITH_SAMPLED_TRACE"`: Only allow measurements with a sampled parent span in context.

0 commit comments

Comments
 (0)