Configuring opentelemetry in a package

[dennis-tra]

I'm writing a go package that I want to instrument with opentelemetry. More specifically, I want to be able to do tracing with Jaeger and collect metrics via prometheus, but I don't want to make this decision for the users of the package. Further, if users aren't interested in either, that's fine, too.

Now I'm wondering what the best practice is to initialize opentelemetry and what configuration parameters I should expose to package users.

Some things I have considered:

1. Use the global MeterProvider/TracerProvider. The challenge I ran into is that I need to register custom views to configure custom histogram buckets. I couldn't find a way to attach those with an already initialized MeterProvider.
2. Expose a configuration option that allows to pass in a MeterProvider/TracerProvider. The user would still have to make sure to register the custom views, meh.
3. Expose a configuration option to inject a list of meter/tracer provider options and initialize both providers in my package. What's the best practice then with regards to configuring resources? What should I configure?
4. Something else?

I would appreciate some guidance here. I'm sure there are already packages that do what I'm also trying to do, so a pointer to a particularly good example would also be great.

Edit: BTW this issue isn't a bug. There just wasn't an option to ask a general question. If there's a better place to ask questions like this, feel free to redirect me.

[dmathieu]

What most instrumentations do is default on the global providers, but allow overriding those values, usually using functional options.

For example, the net/http instrumentation has a NewMiddleware method, which takes a list of functional options.
Two of those options allow setting providers, one for the tracer and one for the meter.
When parsing the passed options, if no tracer/meter were passed, the global ones are used.

That route allows both 1 and 2 within your options. Folks don't have to worry about the providers if they don't wish to, but can do so too.
It also allows you to unit-test your code without the need for setting globals.

As for setting custom boundaries, that's unfortunately not part of the API, but of the SDK. So it's the responsibility of the user to set the boundaries they deem reasonable (or rely on the default ones), not something doable per library.
What you could do though is provide an aggregation selector to the users of your library, who may be able to use it if they wish.

[dennis-tra]

Thanks @dmathieu, this sounds totally reasonable! Regarding the boundaries, that's inconvenient but okay 👍