Protobuffer support

[cdloh]

Love the start of the library!

We use Dynatrace as part of our monitoring stack and presently they only support HTTP & Protobuffer as a transport mechanism for span traces and the such - https://www.dynatrace.com/support/help/shortlink/otel-getstarted-otlpexport

Any chance you would add protobuffer support at all?

Thanks!

[RichiCoder1]

I had proto support in https://github.com/RichiCoder1/opentelemetry-sdk-workers so I know it works. Only issue I had with it was size and complexity.

https://github.com/RichiCoder1/opentelemetry-sdk-workers#otlphttp-protobuf-support

Shouldn't be too difficult to add to this lib since it's more compliant with the source libs.

[evanderkoogh]

Theoretically it should be possible to use the OpenTelemetry-JS protobuf exporter? I haven’t tried it myself, but it uses the same interface for that reason..

So if you could give that a try I would greatly appreciate it so we can document that better for when the next person comes along.

Also let us know if you run into any problems ofc and we’ll see what we can come up with 😄

[cdloh]

I've had a go at this but turns out the OTEL exporter library uses XMLHttpRequest to send the data.

There is an MR to rework this but not clear how far off it is to landing https://github.com/open-telemetry/opentelemetry-js/pull/3542

[evanderkoogh]

Then we might need to look at adapting @RichiCoder1's code and porting it over to here.. Would you be able/have time to have a look at what would need to be done for that @RichiCoder1?

[RichiCoder1]

I'm happy to advise, but I'm afraid I can't make any promises about contributing it myself.

There's a few complexities with pulling my code:

• It uses a custom Cloudflare-tailored Exporter base
• It uses a submodule to pull in the OTEL protos and does custom generation off of that: https://github.com/RichiCoder1/opentelemetry-sdk-workers/blob/main/packages/opentelemetry-sdk-workers/package.json#L44

That said, there's no reason it couldn't/wouldn't work verbatim with this package, just would be pulling over a lot of junk. Might be easier to the OTEL JS PR merged, though one might have to ping the slack/WG to get it accelerated.

[evanderkoogh]

I know you were very strapped for time, but this is exactly what I was hoping for.. an idea of what would be involved so we can figure out how to best move forward.

Getting a PR merged sounds like it would be by far the best option. In the interim I guess we could fork, merge the PR ourselves and release that.. but that sounds a bit messy?

[cdloh]

So I've managed to get a branch of this all working and there's a few things that will likely need fixing on this end.

At present when the exporter calls fetch it resolves to the proxy which then causes it to start a new span and export it again resulting in a never ending loop of spans that keep sending till the Worker exhausts it's request limits.

Not sure how I can unwrap it within the exporter or get the Proxy to detect that it's the exporter that's using fetch vs the worker.

[evanderkoogh]

That is awesome news 😄

the unwrapping happens with the unwrap method. Here is an example: https://github.com/evanderkoogh/otel-cf-workers/blob/2d370cb9098a9066da3ba2b3102d6f29e5c99c31/src/exporter.ts#L54

does that help?