Is your feature request related to a problem?
We need to dynamically add and remove processors / metric readers at run-time; This is currently possible directly via MeterProvider or by sub-classing SynchronousMultiSpanProcessor for tracing, however the equivalent SynchronousMultiLogRecordProcessor is only accessible via the private _internal package which seems to discourage its use. It's possible to copy paste the same implementation as a custom processor but that's not really ideal.
Describe the solution you'd like
Be able to dynamically add and remove processors at run-time which requires public APIs for accessing SynchronousMultiLogRecordProcessor for logs. If this is useful for others I can add public APIs to the provider similar to how MeterProvider works but if it's a niche for our use case I'd be happy with a public API we can extend and implement our custom logic.
Unfortunately I haven't been following the repo closely so I'm not sure which option is preferable for the maintainers. Would appreciate some feedback regarding which approach to request from @aabmass and @xrmx
Describe alternatives you've considered
No response
Additional Context
No response
Would you like to implement a fix?
Yes
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.
Is your feature request related to a problem?
We need to dynamically add and remove processors / metric readers at run-time; This is currently possible directly via MeterProvider or by sub-classing
SynchronousMultiSpanProcessorfor tracing, however the equivalentSynchronousMultiLogRecordProcessoris only accessible via the private_internalpackage which seems to discourage its use. It's possible to copy paste the same implementation as a custom processor but that's not really ideal.Describe the solution you'd like
Be able to dynamically add and remove processors at run-time which requires public APIs for accessing
SynchronousMultiLogRecordProcessorfor logs. If this is useful for others I can add public APIs to the provider similar to how MeterProvider works but if it's a niche for our use case I'd be happy with a public API we can extend and implement our custom logic.Unfortunately I haven't been following the repo closely so I'm not sure which option is preferable for the maintainers. Would appreciate some feedback regarding which approach to request from @aabmass and @xrmx
Describe alternatives you've considered
No response
Additional Context
No response
Would you like to implement a fix?
Yes
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding
+1orme too, to help us triage it. Learn more here.