From 7279f216c172d6e37572a05457c0c5f769372a9c Mon Sep 17 00:00:00 2001 From: jack-berg <34418638+jack-berg@users.noreply.github.com> Date: Wed, 13 Apr 2022 14:54:44 -0500 Subject: [PATCH] Clarify view conflicts (#2462) --- CHANGELOG.md | 3 +++ specification/metrics/sdk.md | 19 ++++++++++++------- 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 170abe2fc4c..4a4ba583f0f 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -13,6 +13,9 @@ release. ### Metrics +- Clarify SDK behavior when view conflicts are present + ([#2462](https://github.com/open-telemetry/opentelemetry-specification/pull/2462)). + ### Logs ### Resource diff --git a/specification/metrics/sdk.md b/specification/metrics/sdk.md index 5f587cdb666..e040fabeece 100644 --- a/specification/metrics/sdk.md +++ b/specification/metrics/sdk.md @@ -195,8 +195,10 @@ In order to avoid conflicts, views which specify a name SHOULD have an instrument selector that selects at most one instrument. For the registration mechanism described above, where selection is provided via configuration, the SDK SHOULD NOT allow Views with a specified name to be declared with instrument -selectors that may select more than one instrument (e.g. wild card instrument name) -in the same Meter. +selectors that may select more than one instrument (e.g. wild card instrument +name) in the same Meter. For this and other cases where registering a view will +cause a conflict, SDKs MAY fail fast in accordance with +initialization [error handling principles](../error-handling.md#basic-error-handling-principles). The SDK SHOULD use the following logic to determine how to process Measurements made with an Instrument: @@ -209,11 +211,14 @@ made with an Instrument: * If the `MeterProvider` has one or more `View`(s) registered: * For each View, if the Instrument could match the instrument selection criteria: - * Try to apply the View configuration. If there is an error or a conflict - (e.g. the View requires to export the metrics using a certain name, but - the name is already used by another View), provide a way to let the user - know (e.g. expose - [self-diagnostics logs](../error-handling.md#self-diagnostics)). + * Try to apply the View configuration. If applying the View results + in [conflicting metric identities](./datamodel.md#opentelemetry-protocol-data-model-producer-recommendations) + the implementation SHOULD apply the View and emit a warning. If it is not + possible to apply the View without producing semantic errors (e.g. the + View sets an asynchronous instrument to use + the [Explicit bucket histogram aggregation](#explicit-bucket-histogram-aggregation)) + the implementation SHOULD emit a warning and proceed as if the View did + not exist. * If the Instrument could not match with any of the registered `View`(s), the SDK SHOULD enable the instrument using the default aggregation and temporality. Users can configure match-all Views using [Drop aggregation](#drop-aggregation)