Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommend OTEL_EXPORTER_OTLP_*COMPRESSION "none" by default #2098

Open
tigrannajaryan opened this issue Nov 4, 2021 · 1 comment
Open

Recommend OTEL_EXPORTER_OTLP_*COMPRESSION "none" by default #2098

tigrannajaryan opened this issue Nov 4, 2021 · 1 comment
Labels
spec:miscellaneous For issues that don't match any other spec label

Comments

@tigrannajaryan
Copy link
Member

The topic was discussed by the TC and the resolution is:

  • We believe that having a locally running Collector is common.
  • The SDK defaults are optimized for this scenario. For example the default endpoints that SDKs send to are "localhost".
  • In line with this we also believe that the default setting for compression options should be "none". Enabling compression when sending to localhost increases CPU consumption and is unnecessary.
  • We think that it is not desirable to make one option's default value depend on another option's value (e.g. make "gzip" default compression if the destination is not "localhost").
  • Some SDKs will know for certain or with high probability that the typical destination they send to is not local. For example this may be the case for in-browser JS SDK or for mobile Android SDK. For such SDKs we want to allow to choose a different default setting for compression.

Therefore the TC believes that:

  • The default recommended value for OTEL_EXPORTER_OTLP_*COMPRESSION option in the spec should be "none". [this needs to be changed in the spec to add recommendation].
  • The spec will allow SDKs to deviate from this recommendation as explained above. [this is already part of the spec]
@tigrannajaryan tigrannajaryan added the spec:miscellaneous For issues that don't match any other spec label label Nov 4, 2021
@arminru
Copy link
Member

arminru commented Nov 16, 2021

For reference: This is related to #1895 which proposed the opposite.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec:miscellaneous For issues that don't match any other spec label
Projects
None yet
Development

No branches or pull requests

3 participants