[sdk-logs] remove deprecated `LoggerProvider#addLogRecordProcessor()`

[pichlermarc]

Description

To align with the other SDKs (@opentelemetry/sdk-trace-*, @opentelemetry/sdk-metrics) we should drop LoggerProvider#addLogRecordProcessor() in favor of the constructor option introduced in #5588 (issue #5559)

This issue is considered done when:

• the contrib and core repos have been checked any any usage of LoggerProvider#addLogRecordProcessor() has been changed to use the constructor option instead.
• this method has been removed:

  • opentelemetry-js/experimental/packages/sdk-logs/src/LoggerProvider.ts

    Lines 78 to 102 in 56df3c0

    	/**
    	* @deprecated add your processors in the constructors instead.
    	*
    	* Adds a new {@link LogRecordProcessor} to this logger.
    	* @param processor the new LogRecordProcessor to be added.
    	*/
    	public addLogRecordProcessor(processor: LogRecordProcessor) {
    	if (this._sharedState.registeredLogRecordProcessors.length === 0) {
    	// since we might have enabled by default a batchProcessor, we disable it
    	// before adding the new one
    	this._sharedState.activeProcessor
    	.shutdown()
    	.catch(err =>
    	diag.error(
    	'Error while trying to shutdown current log record processor',
    	err
    	)
    	);
    	}
    	this._sharedState.registeredLogRecordProcessors.push(processor);
    	this._sharedState.activeProcessor = new MultiLogRecordProcessor(
    	this._sharedState.registeredLogRecordProcessors,
    	this._sharedState.forceFlushTimeoutMillis
    	);
    	}

[ShawnWu33]

Hi @pichlermarc, just wondering since we get rid of LoggerProvider#addLogRecordProcessor(), is that going forward we won't support adding processor after provider being created? Cuz seems the only place to add processor is at the constructor after this change.

[pichlermarc]

Hi @pichlermarc, just wondering since we get rid of LoggerProvider#addLogRecordProcessor(), is that going forward we won't support adding processor after provider being created? Cuz seems the only place to add processor is at the constructor after this change.

Yes, that is the way the OTel SDKs are designed: users should never hold on to SDK components after registering it with the API.

The LoggerProvider#addLogRecordProcessor() method, however, gives the impression that this is fine and leads many users to apply an anti-pattern where they hold on to the SDK instance even after it is registered with the API (which happens to lead to more anti-patterns applied down the line).

This method was initially introduced in the Trace SDK and was taken over into the Logs SDK without much consideration. The reason this initially ended up in the Trace SDK was that people intended it to be similar to the builder pattern that was used in Java, which by nature of it's design would've ensured that people don't modify the Processor after the fact, but that did not materialize in OTel JS.

There is a workaround though that you can apply at your own risk (if you understand that what you're doing is not intended by the OpenTelemetry Authors):

import { LogRecordProcessor, LogRecord } from '@opentelemetry/sdk-logs';
import { Context } from '@opentelemetry/api';

// I used an LLM to generate this code to illustrate you'll likely apply some extra checks and do some clean-up 
export class ExtensibleLogRecordProcessor implements LogRecordProcessor {
  private processors: LogRecordProcessor[];

  constructor(processors: LogRecordProcessor[] = []) {
    this.processors = [...processors];
  }

  addLogRecordProcessor(processor: LogRecordProcessor): void {
    this.processors.push(processor);
  }

  async forceFlush(): Promise<void> {
    for (const processor of this.processors) {
      await processor.forceFlush();
    }
  }

  onEmit(logRecord: LogRecord, context?: Context): void {
    for (const processor of this.processors) {
      processor.onEmit(logRecord, context);
    }
  }

  async shutdown(): Promise<void> {
    for (const processor of this.processors) {
      await processor.shutdown();
    }
  }
}

You can then use your custom processor like this to accomplish the same functionality:

const processor = new ExtensibleLogRecordProcessor();
new LoggerProvider({
  processors: [processor] 
});

// mimic functionality of adding processors on the fly:
processor.addLogRecordProcessor(...)