Add compression configuration to the OpenTelemetry Environment Variable Specification

[Donnerbart]

What are you trying to achieve?

I would like to add missing environment variables to configure compression on (span) exporters to the OpenTelemetry Environment Variable Specification and clarify the compression default value for the OTLP exporter on OpenTelemetry Protocol Exporter.

The suggested new environment variables are:

• OTEL_EXPORTER_JAEGER_COMPRESSION: The compression type to use on Jaeger trace requests. Options include none and gzip. Default is none.
• OTEL_EXPORTER_ZIPKIN_COMPRESSION: The compression type to use on Zipkin trace requests. Options include none and gzip. Default is gzip.

The environment variables to clarify are:

• OTEL_EXPORTER_OTLP_COMPRESSION, OTEL_EXPORTER_OTLP_TRACES_COMPRESSION, OTEL_EXPORTER_OTLP_METRICS_COMPRESSION, OTEL_EXPORTER_OTLP_LOGS_COMPRESSION: The compression type to use on OTLP log requests. Options include none and gzip. Default is none.

The default values are taken from the current implementation of the OpenTelemetry Java SDK.

EDIT: Please notice that in Java compression is currently disabled by default for OTLP and Jaeger, but enabled for Zipkin (using gzip). This may overlap with existing issues like #2098 and #1895.

Additional context.

As a user of the OpenTelemetry Java SDK I'd like to be able to configure compression consistently over the provided trace/metric/log exporters. For the OTLP exporters there is already a programmatic way to configure compression, for Jaeger and Zipkin I'm working on a contribution to add those to the SDK. During the review I was made aware, that for auto-configuration we need to add new environment variables to the SDK specification.

[reyang]

@Donnerbart during the triage meeting, we have question regarding why these new environment variables are needed, and why the defaults are different. It'll be helpful if folks could comment here providing examples in their usage scenario. We also encourage you to join the weekly specification SIG meeting (on Tue.) to discuss this further.

CC @yurishkuro regarding the default compression for Jaeger.

[Donnerbart]

@reyang A big motivation is feature parity between the exporters provided by OpenTelemetry. The OTLP exporters already offers compression configuration, and at least for Java the underlying Jaeger and Zipkin exporters also have compression capabilities.

In general I think it's useful to make the compression configurable, since there might be use cases where network is the bigger bottleneck than CPU, even for local transportation. For example, my company provides an MQTT broker with millions of connected clients. The network can be very easily saturated, while there is still CPU available. So we would like to be able to offer this configuration for our customers, to balance network vs. CPU usage in production systems.

I think it's also helpful to define the default values in the specification, since at in the OTel Java SDK we discovered that the Zipkin exporter (gzip is enabled) uses a different default than OTel and Jaeger (no compression is enabled). I have no idea how this looks in other implementations though.

[Donnerbart]

Results from the SIG discussion:

• The wording for the OTLP default value is deliberately "no value" (after long discussions), so the implementations can decide what's the best for their use case. So there is nothing to do here.
• The future of Jaeger is still to be decided. Until then we should probably not add more configuration options.

So what's left would be to specify a new environment variable for Zipkin to make the compression configurable, specify the valid values (none and gzip) and leave the default to the implementations (like with OTLP).

Since our use-case is fully satisfied with the programmatic API of the Java SDK, I'm happy with every outcome of this issue.