chore(nodejs): change from loggerProvider.addLogRecordProcessor() to 'processors' constructor arg

[trentm]

This will fix the CI failure in #1897. @opentelemetry/sdk-logs@0.203.0
dropped the deprecated LoggerProvider#addLogRecordProcessor(...)
method.

Refs: open-telemetry/opentelemetry-js#5764

---

Note that the (undocumented?) configureLoggerProvider global might not be as useful anymore. A user specifying that global function will no longer be able to add a LogRecordProcessor to the given LoggerProvider instance. I'm not sure if configureLoggerProvider is considered a promised interface.

Unrelated to this PR, it might make sense to change configureLoggerProvider to be more like configureTracer. The latter is given a config object to customize that is later given to new NodeTracerProvider(config);. This would be a more future-proof API.

[trentm]

The latter is given a config object to customize that is later given to new NodeTracerProvider(config);. This would be a more future-proof API.

Actually I was just reading about the OTel Spec's "development" status *Configurator things:

• tracing: https://opentelemetry.io/docs/specs/otel/trace/sdk/#configuration
• metrics: https://opentelemetry.io/docs/specs/otel/metrics/sdk/#configuration
• logging: https://opentelemetry.io/docs/specs/otel/logs/sdk/#configuration

These will eventually likely be the appropriate mechanism for configuring the SDK. However, they are limited to enabled/disable state currently. I'm not sure exactly what a best future-proof API for the lambda layer would be here. Anyway, this is a bit off-topic for this immediate fix.

[serkan-ozal]

Hi @trentm,

Thanks for taking care of this fix.

Yep, I have been thinking of introducing configureLogger function to allow users customizing logger config instead of configuring over configureLoggerProvider.

And, we can still keep the configureLoggerProvider until major release (v1), but it will not be useful for the users other than setting LoggerProvider to global (logs.setGlobalLoggerProvider). To be backward compatible for configureLoggerProvider.addLogRecordProcessor over global configureLoggerProvider function, we might have some tricks, but I don't think it worths to introduce such complexity.

So, I think, what we can do is that:

• Introduce configureLogger function (similar to configureTracer)
• And mention in the release notes that configureLoggerProvider.addLogRecordProcessor over global configureLoggerProvider function is no longer supported. Use configureLogger function instead.

cc @tylerbenson @wpessers @pragmaticivan

[wpessers]

Solution offered by @serkan-ozal sounds good to me. In the past when we dropped support for configureTracerProvider we allowed for a "grace period" by marking it deprecated first before removing it in the subsequent release. But I believe, as these global functions aren't really documented they probably aren't widely used. So in my opinion, including in release notes is sufficient.

[serkan-ozal]

Created a follow-up ticket to introduce configureLogger function #1905 and so merging this PR as is.