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
A view is comprised of selection criteria (i.e. instrument type, instrument name, meter name, meter version, meter schema url) and a configuration for the resulting metric stream (name, description, attribute keys, aggregation, and exemplar reservoir).
The spec has a section which describes how to process measurements from an instrument given views. However, its not clear how an SDK should behave when more than one view applies AND there is not a name conflict.
For example, suppose I register two views, which each select all instruments of type "counter", and where the first sets the description to be "the first description", and where the second sets the description to be "the second description". What should happen when a counter instrument is registered and matches both of these?
The SDK could pick the description from one of the views (e.g. "the first description") and let the user know about the conflict with a diagnostic log. Or, it could say that each distinct view that matches an instrument produces a distinct metric stream on export. I.e. each counter produces two metric streams - one with description "the first description", the other with description "the second description".
What about if the two views don't have conflicting configuration? Suppose two views each select all instruments of type "counter", and the first sets the description to be "the first description", and the second sets the attribute keys to be [foo, bar]. These views don't conflict and could arguably be merged. Should the behavior of the SDK change multiple views selecting the same instrument are compatible?
This comment seems to suggest that views have an implied ordering, and that the first matched view has highest priority. This implies a user should register views from most specific to least specific. If this is correct, I think some additional clarification would be helpful for both implementers and users.
The text was updated successfully, but these errors were encountered:
Upon further time spent reading / implementing the view spec, I now believe its sufficiently clear how the SDK should behave when multiple views select the same instrument. The spec says:
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).
Each view that matches an instrument results in a distinct metric stream. As a consequence, its very easy to get into an "identity conflict" scenario when an instrument matches multiple views: If one of the matched views doesn't change the name, a conflict is guaranteed.
A view is comprised of selection criteria (i.e. instrument type, instrument name, meter name, meter version, meter schema url) and a configuration for the resulting metric stream (name, description, attribute keys, aggregation, and exemplar reservoir).
The spec has a section which describes how to process measurements from an instrument given views. However, its not clear how an SDK should behave when more than one view applies AND there is not a name conflict.
For example, suppose I register two views, which each select all instruments of type "counter", and where the first sets the description to be "the first description", and where the second sets the description to be "the second description". What should happen when a counter instrument is registered and matches both of these?
The SDK could pick the description from one of the views (e.g. "the first description") and let the user know about the conflict with a diagnostic log. Or, it could say that each distinct view that matches an instrument produces a distinct metric stream on export. I.e. each counter produces two metric streams - one with description "the first description", the other with description "the second description".
What about if the two views don't have conflicting configuration? Suppose two views each select all instruments of type "counter", and the first sets the description to be "the first description", and the second sets the attribute keys to be
[foo, bar]
. These views don't conflict and could arguably be merged. Should the behavior of the SDK change multiple views selecting the same instrument are compatible?This comment seems to suggest that views have an implied ordering, and that the first matched view has highest priority. This implies a user should register views from most specific to least specific. If this is correct, I think some additional clarification would be helpful for both implementers and users.
The text was updated successfully, but these errors were encountered: