Add GZip encoding support to Zipkin

Is your feature request related to a problem? Please describe.
There should be a configurable option to send GZip-encoded spans to Zipkin endpoints.

Describe the solution you'd like

• add config property (on by default) to use GZip
• add code handling GZip of encoded byte array (of a span)

Describe alternatives you've considered

• none

Additional context

• none

[iNikem]

Before setting that ON by default, make sure that Collector can accept gzipped data

[anuraaga]

We use the okhttp sender which defaults to sending with gzip by default already. So is this about adding a config option? I think that makes sense, and I'd recommend adding an option for json vs proto too, we currently only have programmatic setting of that.

But how about sending a spec PR for the options first?

[iNikem]

I was not aware that we already use gzip :) Good to be us :) Now thinking about it, why do we need a config option for that? What is the use case to switch that off?

@anuraaga thanks for the tip - I took a brief look on the OkHttpSender but didn't spot the compressionEnabled option. So the situation right now is - if a customer uses OkHttpSender implementation, they will have GZIP enabled by default. I'll check if there is a use case for config option only and get back to you.

[anuraaga]

Thanks - times change and I think many environments have enough network bandwidth where gzip cost outweighs the benefit, so an option seems ok to me. But this is a good opportunity to also have an option for proto - zipkin had always defaulted to json for debugability but high ingestion sites benefit greatly from proto.

[iNikem]

WDYM by proto here? OTLP? Or Zipkin over protobuf?

[anuraaga]

Ah sorry - meant zipkin over protobuf. Zipkin supports both JSON and proto and easy to switch for the senders.

[iNikem]

The nearest thing in specification right now to exporters configuration is https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/sdk-environment-variables.md. I am not even sure where in spec should go the proposal to choose zipkin wire format: json/json+zip/protobuf.

[jkwatson]

Since the current exporter builder supports configuring both the Sender and the Encoder, can't the user set things up however they like, if they don't want the defaults?

[iNikem]

not autoinstrumentation's user :(

[jkwatson]

not autoinstrumentation's user :(

Hm. There's definitely a tension between providing every possible configuration option (via env var or sys prop, or whatever), and just providing the programmatic means for the agent (or other end user) to provide those options.

[iNikem]

Indeed. So you would prefer to have this configuration option in instrumentation repo?

[jkwatson]

Indeed. So you would prefer to have this configuration option in instrumentation repo?

I'm honestly not sure. What is the need of the original poster, @kubawach ? Is it needed for the general SDK, or is the agent enough for now? If it's only needed in the agent, I'd prefer to have it start there, and move it to the SDK if we have a need to configure the SDK that way.

[iNikem]

I think our original request was satisfied by the "discovery" that we already export gzipped zipkin :) So I think it is fair to close this ticket with resolution "either implement that switch in instrumentation repo or get it accepted to spec" :D