How do you proxy frontend traces via a backend?

[triblondon]

Hi! I have a React frontend app configured like this (note the exporter sends to /traces):

const provider = new WebTracerProvider({ resource: new Resource({ 'service.name': 'React' }) });
provider.addSpanProcessor(new SimpleSpanProcessor(new OTLPTraceExporter({ url: '/traces' })));
provider.register();

registerInstrumentations({ instrumentations: [ new FetchInstrumentation() ] });

On the server side I am using the Node SDK in my ExpressJS app:

const oTelNode = new NodeSDK({
  resource: new Resource({ 'service.name': 'NodeJS app'}),
  traceExporter: new OTLPTraceExporter({ url: process.env.OTEL_HTTP_COLLECTOR_BASE_URL + "/v1/traces" }),
  instrumentations: getNodeAutoInstrumentations(),
});

And I have a handler to receive the frontend traces:

app.post('/traces', parseJson, async (req, res) => {
  //telemetry.importTraceData(req.body);  <-- need something like this
  res.status(204).end();
});

Two questions:

1. Why is there an SDK for Node which I think constructs a tracer provider internally, but in the browser we instantiate the tracer provider directly? Is this an intentional design choice or an inconsistency that will be smoothed out in the fullness of time?
2. When my Express app receives the POST to /traces from the frontend, what do I do with it? I'd rather like to have a method of the Node SDK instance such as oTelNode.importTraceData(data: string). Basically how do I deserialise an OTLP resourceSpans message from my frontend tracing and feed it into the server-side tracing for export to my collector?

[martinkuba]

Hi @triblondon, the web instrumentation is not as mature as Node, and if I had to guess it was not clear at the time what instrumentations should be there by default. Also async context propagation relies on Zone.js (unlike Node where it is part of the runtime), and Zone.js may not be compatible or desired with every type of web application. With that said, there definitely could be an SDK for web that initializes the web tracer provider with some defaults.

Also fyi, the Client-side SIG will likely work on a browser-optimized SDK in the near future.

As far as collecting the browser traces, I would recommend sending the data directly to a public Collector endpoint.