Hi @yurishkuro , is it up for grab can I start on it ?

@psk001 yes

Thanks @yurishkuro. I followed the mentioned article and was able to get traces using jaeger all-in-one For the exporter, a URL is required to send traces to collector

const collectorExporter = new OTLPTraceExporter({
// url:""
  headers: {}
});

Without a given value, it defaults to localhost. Is there a collector URL that can be added here?

All-in-one listens on port 4318 for OTLP over HHTP.

is it up for grabs? :)

Yes, but also see a previous unsuccessful PR #1627

yep, read it through and personally i think author got almost through with the implementation with few formatting/cleanup issues i suppose and one issue with adding a way to disable the tracing.
soon I'll open up a draft PR if i got it right?

@MAX-786 I think the main unresolved issue for me was how the traces from the UI should be exported. UI communicates with jaeger-query via an internal API. jaeger-query itself generates traces internally and exports them somewhere (in case of all-in-one it exports it back to itself over local port). So my assumption was that the zero-configuration option would be for the UI to export traces into an internal endpoint in the jaeger-query where it can handle them the same way as the the traces it itself generates.

A non-zero configuration option would be to make it the responsibility of the operator to provide an export URL for traces from the UI. It's certainly doable but makes the configuration much more complicated imo, as one has to potentially deal with additional CORS settings to allow the UI to talk to something else, etc.

To be fair, we could start with the non-zero configuration and at least merge the React PR to capture the traces, to divide the problem. Then we can see if we can add a new endpoint to jaeger-query to accept traces from the UI (we already have an implementation of OTLP/HTTP endpoint, it's easy to reuse).