Feature discussion: support for custom exporters

[10xLaCroixDrinker]

TL;DR What do you think of adding support for custom exporters?

Background

Using the ConsoleLogRecordExporter with pino-opentelemetry-transport, I noticed that the colorization doesn't work locally. This happens because the logger is in a worker thread and process.stdout is not a TTY.

I opened open-telemetry/opentelemetry-js#4524 to add an option to ConsoleLogRecordExporter that would force colorization. However, the OpenTelemetry team suggested implementing a custom exporter as they do not want to expand the API for ConsoleLogRecordExporter (which currently takes no options).

Ultimately, I will likely stick with my workaround of using process.env.FORCE_COLOR=1. But this is what got me thinking about otlp-logger supporting custom exporters.

Design

A custom exporter just needs to implement the LogRecordExporter interface. The API could look something like this:

const logger = getOtlpLogger({
  loggerName: 'my-app',
  resourceAttributes: {/* ... */},
  serviceVersion: '1.0.0',
  logRecordProcessorOptions: {
    recordProcessorType: 'batch',
    exporterOptions: {
      path: path.join(__dirname, 'my-exporter'), // or just 'name-of-custom-exporter-package'
      export: 'LogExporter', // optional, assumes default export when omitted
      options: {/* ... */} // optional
    }
  }
})

[Vunovati]

Hello @10xLaCroixDrinker,

do you think this would complicate the interface or confuse the users? My understanding of the spec is that a finite number of exporters match the protocols supported by the collectors. I could be wrong, so please correct me if you are aware of counterexamples in the wild.

Even if that is not 100% the case, I assume that the average user would expect and use those three, so I would like to prioritize that over other use cases. In general, I am open to adding this if does not degrade the standard use-cases.