Add more details to SDK MeterProvider and View

[reyang]

Follow up #1673
Fixes #466
Related issues #1116

Changes

• Added details to the MeterProvider SDK spec

Related oteps OTEP146

[jsuereth]

My concern here is the following:

• View is defined in the SDK as it's mostly a processing piepline thing, however it's really feeling like an APi thing
• I think there's a bifurcation of API that needs to happen as we specify between "How a user specified a view" and "The interface and processing of that view". I'm not sure I can tell where the line between the two is in this specification.
• Fundamentally, with Views, we're defining a sort of "query" language against metrics (prometheus rewrite rules e.g.). I think we can do something very simple to start with, but I know we'll get pushed this direction. We should set ourselves up for success there. i'd like to see more examples of "configuration" for views.

Do we have a prototype for these that I missed? (sorry the metric API meeting has been at a really inconvenient time for me in general).

[jsuereth]

From a 'raw level SDK' this seems fine, but as specified i think you NEED a helper method on top of this.

E.g. Can the user just glob-match on Version + Kind to get measurements based on Meter/Instrument-name?

I'm worried the way this language reads right now. I think it makes sense to tease apart "What SDK implementors of metric processors need" and "What SDK Users defining views need". does it make sense to split these two?

Effectively for users, your'e giving them a 'query' language to select metrics.
For the SDK, you're defining a data model "index" that needs to allow rapid processing.

i agree the 4 things you list are what belong on the index.

[cijothomas]

This is missing something to select "Aggregation". "Customize the aggregation" is a listed use-case.

[jsuereth]

I don't think this portion of the API needs to specify aggregation. Instead we do need to clarify if any selected instrument has its default aggregation removed, or if it still exists. It's unclear what would happen if I were, e.g. to do a "Select all" here for my metrics. Do they all get removed?

[jsuereth]

Based on discussion in the metrics API SiG, updating my comments as follows:

1. I think it needs to be more explicit when "default hint aggregation" is going to be used or overridden.
   • E.g. is the case that always when a selection criteria matches a metric, then the view overrides the default aggregation?
   • is there a control to specify "I want the default hint and this view is on top of it?
   • How would I know (as a user) that the "hint" API (and default aggregatio) is not used?
2. i think the selection criteria needs to be specified a little bit more clearly (and ideally with examples).
   • Do you allow partial label matching? (Right now it's just instrument
     • can you match just on the existence of Keys (not values)
   • Can I regex match? (on anything)
   • Were these all intended to be exact-match-only?
   • What about "versions" for InstrumentationLibrary/Meter?

[jmacd]

(partial review, thanks @reyang and sorry for the long delay)

[jkwatson]

I wonder if we should leave these out of the first pass. Otherwise, we need to figure out some standard way to figure out how to define the source of the information declaratively.

[jmacd]

What do you mean by "define the source of the information"?

[reyang]

I think having this would help us to move forward (once we have the skeleton of the spec, it is easier for others to come and contribute the "meat") 😄

[jkwatson]

I mean... how do you extract it from the context? Are you providing some sort of function on the context that would give you an attribute?

[jmacd]

My understanding is that the SDK via its MeasurementProcessor has access to the context for this purpose.

[jkwatson]

sure...but how do you define a view to do that work? how do you specify how to extract data from the context?

[jsuereth]

@yurishkuro this pr has enough approvals (and discussion during SiG) to merge.

[jmacd]

The recent changes look good and reflect the discussion in the last SIG meeting.

[reyang]

Discussed during the Metrics SIG meeting, I've removed the histogram details, we should be ready to merge the PR @jsuereth.