-
Notifications
You must be signed in to change notification settings - Fork 812
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 setup method to configure the OpenTelemetry API #1149
Comments
I think we should still do the SPI thing we do at this moment, while also supporting explicit, manual configuration as done in #1058 |
I think @bogdandrutu was going to prototype an SDK that could also be a no-op until it had been configured, which would, I think, solve many of the startup-timing issues that make all of this extra tricky. |
I have some questions about this:
|
My opinion is
|
Can we push this off until after GA? I think this is a purely additive change to the API/SDK, so it seems like this could be pushed off, especially as the instrumentation agent seems to be working fine for now. |
Technically we should implement this as part of the Specification (as mentioned by @thisthat in the issue description) - yet I feel this is indeed something that could be left as "Required for GA" but low priority (in case we cannot address all the items by deadline time). @thisthat @anuraaga Sounds great? If not, please elaborate ;) |
Heh. I wrote that specification, so I do think we should be programmatically configurable. But, I also think we could probably get away with only SPI for GA, if we need to. |
If SPI covers all configuration options that we want to provide, then it is certainly enough for GA. Other options, like |
Moving to after-ga. Please yell if you think this is actually needed for GA. |
I think this would be satisfied by #1737 , yes? |
According to the specifications, the OpenTelemetry SDK must be programmatically configurable. The current initialization looks for implementations of the OpenTelemetry API via Service Provider and if no instance is found, it defaults to a no-op implementation. In the SIG call, we agreed that the default behavior should be no-op until a configuration is provided.
#1058 provides a first implementation that allows to set up individually tracer provider, metric provider, and context manager. We should iterate over this proposal and making it friendly to the auto-instrumentation.
The text was updated successfully, but these errors were encountered: