Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more details to SDK MeterProvider and View #1730

Merged
merged 29 commits into from
Jul 27, 2021

Conversation

reyang
Copy link
Member

@reyang reyang commented May 28, 2021

Follow up #1673
Fixes #466
Related issues #1116

Changes

  • Added details to the MeterProvider SDK spec

Related oteps OTEP146

@reyang reyang requested review from a team May 28, 2021 20:54
@reyang reyang added area:sdk Related to the SDK spec:metrics Related to the specification/metrics directory labels May 28, 2021
specification/metrics/sdk.md Outdated Show resolved Hide resolved
specification/metrics/sdk.md Outdated Show resolved Hide resolved
Copy link
Contributor

@jsuereth jsuereth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

specification/metrics/sdk.md Outdated Show resolved Hide resolved
specification/metrics/sdk.md Outdated Show resolved Hide resolved
specification/metrics/sdk.md Show resolved Hide resolved
The MeterProvider MUST provide a way to register Views, and here are the
inputs:

* The Instrument selection criteria (required), which MUST cover:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

specification/metrics/sdk.md Outdated Show resolved Hide resolved
specification/metrics/sdk.md Outdated Show resolved Hide resolved
@jsuereth
Copy link
Contributor

jsuereth commented Jun 6, 2021

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?

@reyang reyang mentioned this pull request Jun 10, 2021
Copy link
Contributor

@jmacd jmacd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

specification/metrics/sdk.md Outdated Show resolved Hide resolved
specification/metrics/sdk.md Outdated Show resolved Hide resolved
specification/metrics/sdk.md Outdated Show resolved Hide resolved
specification/metrics/sdk.md Show resolved Hide resolved
specification/metrics/sdk.md Outdated Show resolved Hide resolved
specification/metrics/sdk.md Outdated Show resolved Hide resolved
Comment on lines +116 to +118
* The `extra dimensions` which come from Baggage/Context (optional). If not
provided, no extra dimension will be used. Please note that this only
applies to [synchronous Instruments](./api.md#synchronous-instrument).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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") 😄

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@jsuereth
Copy link
Contributor

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

Co-authored-by: John Watson <jkwatson@gmail.com>
@yurishkuro yurishkuro removed their assignment Jul 26, 2021
Copy link
Contributor

@jmacd jmacd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@reyang
Copy link
Member Author

reyang commented Jul 27, 2021

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

@jsuereth jsuereth merged commit 872ff29 into open-telemetry:main Jul 27, 2021
@reyang reyang deleted the reyang/metrics-sdk-view branch July 27, 2021 17:26
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this pull request Oct 31, 2024
* Add View API

* fix link

* address comments

* provide one example

* update wording

* polish wording

* update wording

* mention histogram bucket in the view aggregation

* resolve comments based on discussion during the SIG meeting

* fix typo

* update the spec based on discussion during the SIG meeting

* add more diagrams

* update the spec based on the discussion during Metrics SIG meeting

* minor tweak diagram

* address review comment

* update the default histogram buckets

* remove pipeline from this PR

* address comments regarding error handling

* Update specification/metrics/sdk.md

Co-authored-by: John Watson <jkwatson@gmail.com>

* adjust wording

* add instrument type and clarify the selection criteria

* update the view selection logic

* update the view selection logic

* fix broken link

* update the TODO part by removing the details

Co-authored-by: John Watson <jkwatson@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:sdk Related to the SDK spec:metrics Related to the specification/metrics directory
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Metrics: Scope the Views API