search

open-telemetry / opentelemetry-java

OpenTelemetry Java SDK
https://opentelemetry.io
Apache License 2.0
2.02k stars 839 forks source link

OTLP proto encoding in a standalone package #5068

Closed sfc-gh-sili closed 11 months ago

sfc-gh-sili commented 1 year ago

TL;DR; Can we have (Java object -> proto) code in a standalone package instead of in exporter-otlp-common which pulls in okhttps?

Is your feature request related to a problem? Please describe.

We are implementing our own SpanExporter that outputs spans in OTLP format, and we are trying to reuse the Java object -> proto encoding code instead of writing our own. The bare minimum package that includes the objectToProto() encoding would be exporter-otlp-common, but it pulls in okhttp3 as its dependency.

Describe the solution you'd like Is it possible to have Java object -> proto encoding code released in a standalone package instead of as part of OtlpGrpcExporter or OtlpHttpExporter?

Describe alternatives you've considered A couple of alternatives we are exploring right now:

  1. Having our own version of Java object -> proto encoding code, but it's something we want to avoid in general.
  2. Marking transitive dependencies (e.g. okhttps3, okio, kotlin) as optional or exclude.

Additional context We will be running user defined functions in the same environment, so we are extra cautious about every single new dependency.

jack-berg commented 1 year ago

What functionality is your SpanExporter providing that isn't available in OtlpGrpcSpanExporter or OtlpHttpSpanExporter?

If you really need to provide your own SpanExporter, I would suggest excluding the okhttp dependency. The code in :exporters:otlp:common is meant for internal use only and I think it should stay that way.

sfc-gh-sili commented 1 year ago

What functionality is your SpanExporter providing that isn't available in OtlpGrpcSpanExporter or OtlpHttpSpanExporter?

  1. We run user defined functions in a sandbox environment that has no access to the network, so neither GRPC or HTTP works.
  2. We auto-instrument spans and tie those to user defined functions. This means we are sending a bunch of meta data (e.g. function ID, user ID) with the span proto.

Essentially we would like to stick to the OTLP proto standard, but sending protos via Grpc or Http doesn't work for our use case

jack-berg commented 1 year ago

Interesting. Could you use the OtlpJsonLoggingSpanExporter and parse the OTLP JSON encoded content from the logs?

sfc-gh-sili commented 1 year ago

Yes that could definitely be an option, but it takes another layer of parsing which we prefer not to have.

jack-berg commented 11 months ago

Since last commenting on this, we've done some refactoring and exporter-otlp-common no longer includes a dependency on okhttp.

Closing because the original ask is completed, although I still don't recommend using the marshalers because they're in internal classes and not subject to our API compatibility guarantees.