NH-12018 oboe Reporter init moved to Configurator#17
Conversation
There was a problem hiding this comment.
As always thank you for the informative PR writeup @tammy-baylis-swi! The changes LGTM with one caveat which is my fault for not having actually discussed it with you -- let's essentially pin our distro to ONLY use our custom sampler :). Added the rationale to your nice confluence page.
And indeed I see now there are several cases of the use of next(iter_entry_points().. outside of any type of looping in OTel Python, and it does make sense from the angle of working around the brittleness of specifying a dist :)
Thank you @cheempz ! Changed to always use our SW Sampler in 01f1e98. Setting I've also changed the Troubleshooting page back to "Not supported" for customizing OTel sampler. I kept my findings in a note in case we want to try something similar in the future. Please let me know what you think 😺 |
cheempz
left a comment
There was a problem hiding this comment.
LGTM, thanks @tammy-baylis-swi! I've been glossing over how the agents should handle fatal misconfiguration but this PR has reminded me to jot it down in https://swicloud.atlassian.net/browse/NH-11751 so we can tackle that separately.
This update moves oboe
Reporter()from the SW Exporter to the SW Configurator so thatoboe_initis called at custom-distro setup when using the SW Exporter or with a different exporter set byOTEL_TRACES_EXPORTERenv var. There doesn't seem to be any other way to triggeroboe_initin the SWIG'doboe_api, which makes sense as it looks like the only responsibilities ofReporter()are to assemble options then use them tooboe_init.This also reverts a change made in #14 so that instead of
load_entry_pointfor a non-SW exporter, we go back to:I've done this because in my mind it's the cleanest way for custom-distro to find something like
otlp_proto_grpcin the Python Distribution at runtime. It's too brittle to map requireddistnames forload_entry_point, and it's too complex and a waste to implement a search throughsys.pathwheniter_entry_pointsalready does it. Even though there is a small chance a customer might have multiples of the sameenviron_exporter_namein their path (see this comment), generally speaking that's for them to make sure is correct. Also, theiter_entry_pointsapproach is used all over OTel Python and it's cleaner to match than to mix up setup techniques.Special note: Currently OTel Python does not use entry points to configure Sampler like it does for Exporter and Propagators, so using
iter_entry_pointsorload_entry_pointfor a non-SW Sampler fails. OTel Python usessampling._get_from_env_or_default()so we do too: https://github.com/open-telemetry/opentelemetry-python/blob/main/opentelemetry-sdk/src/opentelemetry/sdk/trace/sampling.py#L374-L377 I've added this piece to the NH Python Troubleshooting doc.Here is today's manual testing doc for this update: https://swicloud.atlassian.net/wiki/spaces/NIT/pages/3042050066/2022-05-04+configurator+testing
Please let me know what you think or if I've missed something 😃