Consider allowing a simpler API for histogram default buckets

[dashpole]

Context

This is feedback from a Go prototype of the Instrument Advice API:

• Tracking issue: Ensure the advice API can be added to the metric SDK opentelemetry-go#4162
• Prototypes: Prototype for the advice api opentelemetry-go#4341, [POC] Histogram Boundry Hints opentelemetry-go#4340

Feedback

When prototyping in Go, "Advice" itself seemed unnecessary for allowing histogram bucket boundaries to be configured on histogram instruments. The simplest, cleanest API was to make bucket boundary configuration a "top-level" configuration option exclusive to histograms, rather than nested within an "Advice" concept.

The ask in this issue is to at least allow API implementations to exclude the notion of Advice, and instead allow directly configuring the subfields of Advice on the instruments they apply to.

cc @jack-berg @MrAlias @MadVikingGod

[MrAlias]

"When prototyping in Go, 'Advice' itself seemed unnecessary for allowing histogram bucket boundaries to be configured on histogram instruments" should be "When prototyping in Go, 'Advice' itself seemed unnecessary for allowing histogram bucket boundaries to be configured on anything but histogram instruments", right?

[dashpole]

I meant to say that configuring buckets directly, rather than nested inside of advice, was simpler. I.e. advice was not necessary for allowing buckets to be configured on histograms.

Your statement is also correct that histogram bucket boundary configuration didn't make sense to include as options for non-histogram instruments.

[MrAlias]

I meant to say that configuring buckets directly, rather than nested inside of advice, was simpler. I.e. advice was not necessary for allowing buckets to be configured on histograms.

Your statement is also correct that histogram bucket boundary configuration didn't make sense to include as options for non-histogram instruments.

Gotcha 👍

[trask]

just fyi, I've added this to the spec meeting agenda for discussion since it's potentially a blocker for #3391 which is a blocker for HTTP semconv stability

[jmacd]

The ask in this issue is to at least allow API implementations to exclude the notion of Advice, and instead allow directly configuring the subfields of Advice on the instruments they apply to.

This seems reasonable.

[dashpole]

Notes from the SIG meeting:

• We are OK loosening language around how the parameter is passed.
• We need to ensure that it is still clear to users that the parameter can be ignored by SDKs.