vunovati / otlp-logger Goto Github PK

Why is it that different keys are required to pass options to the different exporters? e.g. When exporterOptions.protocol is grpc, you must use exporterOptions.grpcExporterOptions and when exporterOptions.protocol is http, you must use exporterOptions.httpExporterOptions.

Why not just use exporterOptions.options for all of them? Is it simply because of the types? If so, are you open to a non-breaking PR to support exporterOptions.options properly typed with overrides?

What are your thoughts on making the OTel dependencies peerDependencies so that they can be updated without waiting on an otlp-logger release?

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
    }
  }
})