-
Notifications
You must be signed in to change notification settings - Fork 634
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
Allow configuration of inner SDK Logger
using LoggingHandler
#4060
Comments
Please correct me if I am wrong, but this is what I understand about this issue. There is a that function points here: opentelemetry-python/opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/__init__.py Line 644 in b1e99c1
and here we are instantiating |
That is my understanding as well @vivek378521 |
So we can give the user the option to add InstrumentationScope object (optional) when they instantiate the LoggingHandler. I can raise a PR for this in some time if the solution is acceptable? (altho it is pretty straightforward, I'd still like someone to say "yes, do it") |
Less clear to me whether we want to accept an actual InstrumentationScope instance vs just the name (at least for now). Please feel free to open a PR. |
@vivek378521 thanks for working on this one. |
Thanks for the help @emdneto! So I have made the changes and added a test that confirms that we are able to set the instrumentation_scope values, but I now need to test the handler functionality, but I am not sure how do I assert or find out the InstrumentationScope values from a LoggingHandler object. I think I'll have to use the emit fn and put some assertions there, but not sure. Should I raise a WIP PR so that I can get some help with that? |
@vivek378521 I think a PR would be nice |
This is the WIP PR #4073 |
Any feedback on the PR? Reiterating: How do I check the instrumentation scope field values on a LoggingHandler Object? I see a emit fn that gives LogData but I didn't find anything resembling the test case. Draft PR: #4073 |
Is your feature request related to a problem?
Currently, our recommended approach for collecting logs using the sdk is through the LoggingHandler, which encapsulates a
LoggerProvider
and instantiates a OT SDK Logger by callingget_logger
internally. This is synonomous to tracing'sget_tracer
and metricsget_meter
, which accept name, version and schema url to construct anInstrumentationScope
. The different with metrics and tracing is that the recommended approach is to constructTracer
andMeter
manually by using those apis instead of through a handler. So with our current recommendation, users who useLoggingHandler
to instantiate an sdkLogger
by default will always get__name__
as the instrumentation module name (which is hardcoded to the name of the file), blank library version and blank schema url. We should probably provide a way for users to populateInstrumentationScope
values through the use ofLoggingHandler
.Describe the solution you'd like
Most likely have to add a parameter to allow for configuration of the inner sdk
Logger
inLoggingHandler
.Describe alternatives you've considered
No response
Additional Context
No response
Would you like to implement a fix?
None
The text was updated successfully, but these errors were encountered: