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

Return type of callback functions for Asynchronous Instruments #1732

Open
jonatan-ivanov opened this issue May 28, 2021 · 2 comments
Open

Return type of callback functions for Asynchronous Instruments #1732

jonatan-ivanov opened this issue May 28, 2021 · 2 comments
Labels
area:api Cross language API specification issue release:after-ga Not required before GA release, and not going to work on before GA spec:metrics Related to the specification/metrics directory

Comments

@jonatan-ivanov
Copy link
Member

Right now, the Metrics API Docs says:

The callback function is responsible for reporting the Measurements.

Measurements encapsulate two things:

  • A value (result of your measurement)
  • Attributes (dimensions)

This means that if the users have a function that provides a value (provided by a library/language sdk/etc.), they can't just simply use it but they have to wrap it in another function that enhances the original one and adds the attributes.
This can result in sub-optimal user experience and API usability by forcing the users to write a bunch of boilerplate.

Can we come up with a solution (additional functionality) to improve this so that the users can register a simple function that only provides the value and if they want define the attributes separately?

For example:

With "static" attributes:

void createObservableCounter(String name, Supplier<? extends Number> valueProvider, Attributes... attributes);

You can call it like this
(the sensor instance has a getTemperature method that returns a Double and it is registered as the callback):

meter.createObservableCounter("room.temperature", sensor::getTemperature, Attributes.of("room", "living-room"));

With "dynamic" attributes:

void createObservableCounter(String name, Supplier<T> valueProvider, Function<T, Iterable<Attributes>> attributesProvider);

You can call it like this (the sensor instance has a getTemperature method that returns a TemperatureResult instance that will be passed to the attributesProvider which will provide the Attributes based on the result):

meter.createObservableCounter("room.temperature", sensor::getTemperature, t -> Attributes.of("room", r.name()));
@jonatan-ivanov jonatan-ivanov added the spec:metrics Related to the specification/metrics directory label May 28, 2021
@jonatan-ivanov
Copy link
Member Author

/cc: @reyang @jmacd @jkwatson

@arminru arminru added the area:api Cross language API specification issue label May 31, 2021
@reyang reyang added this to the Metrics API/SDK Feature Freeze milestone Jun 10, 2021
@reyang
Copy link
Member

reyang commented Oct 14, 2021

Discussed during 10/14/2021 #210 Metrics SIG Meeting, we haven't seen many demands and this is one possible way among many other ways to provide simpler API for specific scenarios. Move this out of the initial stable release scope.

If anyone interested in this addition, please reply here and describe your usage scenario.

@reyang reyang removed this from the Metrics API/SDK Feature Freeze milestone Oct 14, 2021
@reyang reyang added the release:after-ga Not required before GA release, and not going to work on before GA label Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:api Cross language API specification issue release:after-ga Not required before GA release, and not going to work on before GA spec:metrics Related to the specification/metrics directory
Projects
None yet
Development

No branches or pull requests

3 participants