Possible to use multiple exporters with metrics?

[dradetsky]

• This only affects the JavaScript OpenTelemetry library

This is either a feature request or a simple question. I mean, maybe it's a simple question + a feature request for improved documentation and examples, but...

Anyway, I'm wondering whether it's currently possible for metrics to be sent to multiple collectors. For example, could I export all metrics via both the regular CollectorMetricExporter to my otel collector container, and to prometheus via the PrometheusExporter?

For traces, just by looking at the API, it was immediately obvious how I could send my traces to two different collector targets. I just guessed that the example here with two otel collectors in docker and a span processor for each would work, and of course it does.

But looking at the metrics API, it's not obvious how I would do the same sort of thing. All my metrics have to start at a MeterProvider, which gets bound to exactly one exporter in its config. It looks like if I wanted to accomplish this, I would have to create a big layer of abstraction around MeterProvider so that it was actually a list of providers (one per exporter), with all the methods from .getMeter() down to .add() being mapped over the lists. Just thinking about this is making me feel dumber.

Since this might actually turn out to be a feature request:

Describe the solution you'd like

Ideally, for consistency with the tracer api, I'd be able to write

const provider = new MeterProvider({
  interval: 1000,
})

provider.addExporter(metricExporter0)
provider.addExporter(metricExporter1)

But I guess it would be okay if I could also write

const provider = new MeterProvider({
  exporters: [
    metricExporter0,
    metricExporter1
  ],
  interval: 1000,
})

if that was substantially easier for some reason.

Additional context

At my company, some people were talking about a metrics strategy for our platform that involved sending metrics to both Cloudwatch (i.e. we're actually using the aws-otel distro collector, if that matters at all) and Prometheus. I can't remember exactly why (we also had a very big release going on at the time), but my point is that this isn't just an abstract desire for a flexible & consistent API. It was something we actually wanted to do, if possible.

[cpeddecord]

I don't know if this helpful or sane, but I make a quick mutli-exporter for local debugging:

import { ExportResult } from '@opentelemetry/core';
import { MetricExporter, MetricRecord } from '@opentelemetry/metrics';

export default class MultiExporter implements MetricExporter {
  private exporters: MetricExporter[];

  constructor(exporters: MetricExporter[]) {
    this.exporters = exporters;
  }

  export(
    record: MetricRecord[],
    callback: (result: ExportResult) => void,
  ): void {
    this.exporters.forEach((exporter) => {
      exporter.export(record, callback);
    });
  }

  async shutdown(): Promise<void> {
    await Promise.all(this.exporters.map((e) => e.shutdown()));
  }
}

[dyladan]

@dradetsky we definitely intend to allow exporting to multiple backends concurrently. The current state has more to do with the rapidly shifting and unfinished specification than anything.

[legendecas]

Closing as the metrics SDK has been refactored with the new metrics spec, and the feature is supported with the new SDK.