There is an issue with our current Metrics API breaking from the spec. The spec defines instruments to be identified by all their properties (instrumentation scope, name, unit, etc) while in the Erlang/Elixir API in order to allow use of Erlang macros and Elixir module attributes for referring to instruments only work off the name.
The differing possible APIs look like:
otel_counter:create(my_counter, #{...}),
otel_counter:add(my_counter, 1, #{}),Or, requiring the instrument so the full identity can be used to distinguish them:
Instrument = otel_counter:create(my_counter, #{...}),
otel_counter:add(Instrument, 1, #{}),The later means this instrument variable must be tracked by the instrumentation and passed to wherever recordings need to be made.
I don't think this tracking and passing around is something that isn't doable, but it is very different from what users expect from a metrics API because of their previous experience with prometheus and statsd.
I have played around with this a lot and spoken to a number of people over what is no years and am still up in the air on the best solution. Currently the API accepts only the atom name and that is used to find all Views that were matched against the instrument. The question is should it remain that way, instead require passing in the actual instrument or is there some third middle ground.
There is an issue with our current Metrics API breaking from the spec. The spec defines instruments to be identified by all their properties (instrumentation scope, name, unit, etc) while in the Erlang/Elixir API in order to allow use of Erlang macros and Elixir module attributes for referring to instruments only work off the name.
The differing possible APIs look like:
Or, requiring the instrument so the full identity can be used to distinguish them:
The later means this instrument variable must be tracked by the instrumentation and passed to wherever recordings need to be made.
I don't think this tracking and passing around is something that isn't doable, but it is very different from what users expect from a metrics API because of their previous experience with prometheus and statsd.
I have played around with this a lot and spoken to a number of people over what is no years and am still up in the air on the best solution. Currently the API accepts only the atom name and that is used to find all Views that were matched against the instrument. The question is should it remain that way, instead require passing in the actual instrument or is there some third middle ground.