-
Notifications
You must be signed in to change notification settings - Fork 2.6k
feat(elasticsearch): add flag to enable gzip compression #7072
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
Conversation
This commit adds a new flag `--es.http-compression=true|false` that optionally enables gzip compression for requests to ElasticSearch. The setting is supported by both client libraries that are used. ElasticSearch has accepted compressed requests since version 5.0, anyway the default has been left on false to avoid breaking any existing setups. Signed-off-by: Timon Engelke <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there good reasons not to enable this by default and make it opt out rather than opt in?
No, I think it would be best to turn compression on by default (I can't even imagine why you would want to turn it off, so I probably would have just turned it on without exposing the setting), but I was afraid that you would hesitate to merge such a change and this seemed to be the easier solution. If you are open to that, I can adapt the changes to either change the default or not expose the configuration option. Either will probably save a lot of people a lot of money. |
It's the right way to have is as an option, but I agree it should be on by default |
Since gzip compression has no negative effect in a normal setup, we have decided to turn the setting on by default. Signed-off-by: Timon Engelke <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7072 +/- ##
==========================================
+ Coverage 96.01% 96.05% +0.04%
==========================================
Files 355 355
Lines 20993 21007 +14
==========================================
+ Hits 20156 20178 +22
+ Misses 630 624 -6
+ Partials 207 205 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…ng#7072) ## Which problem is this PR solving? Currently, Jaeger sends its traces to ElasticSearch as uncompressed text. Since text is can be compressed quite well, enabling Gzip compression can significantly reduce Jaeger's network traffic. ElasticSearch has accepted compressed requests since version 5.0 and since the same version it has already sent compressed responses by default (cf. elastic/elasticsearch@0a6f40c). ## Description of the changes * 🛑 (breaking change) **Enable by default** the compression for requests to ElasticSearch * Add a new flag `--es.http-compression=true|false` that can be used to opt-out of compression . The setting is already supported by both client libraries that are used. ## How was this change tested? I tested the change running a local ElasticSearch instance and `SPAN_STORAGE_TYPE=elasticsearch ./cmd/collector/collector-linux-amd64 --es.http-compression=true`. I sent traces to Jaeger using `tracepusher` and observed the network traffic between Jaeger and ElasticSearch using `tcpdump` to verify that the traffic is indeed compressed. ## Checklist - [x] I have read https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md - [x] I have signed all commits - [x] I have added unit tests for the new functionality - [x] I have run lint and test steps successfully - for `jaeger`: `make lint test` - for `jaeger-ui`: `npm run lint` and `npm run test` --------- Signed-off-by: Timon Engelke <[email protected]>
…ng#7072) ## Which problem is this PR solving? Currently, Jaeger sends its traces to ElasticSearch as uncompressed text. Since text is can be compressed quite well, enabling Gzip compression can significantly reduce Jaeger's network traffic. ElasticSearch has accepted compressed requests since version 5.0 and since the same version it has already sent compressed responses by default (cf. elastic/elasticsearch@0a6f40c). ## Description of the changes * 🛑 (breaking change) **Enable by default** the compression for requests to ElasticSearch * Add a new flag `--es.http-compression=true|false` that can be used to opt-out of compression . The setting is already supported by both client libraries that are used. ## How was this change tested? I tested the change running a local ElasticSearch instance and `SPAN_STORAGE_TYPE=elasticsearch ./cmd/collector/collector-linux-amd64 --es.http-compression=true`. I sent traces to Jaeger using `tracepusher` and observed the network traffic between Jaeger and ElasticSearch using `tcpdump` to verify that the traffic is indeed compressed. ## Checklist - [x] I have read https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md - [x] I have signed all commits - [x] I have added unit tests for the new functionality - [x] I have run lint and test steps successfully - for `jaeger`: `make lint test` - for `jaeger-ui`: `npm run lint` and `npm run test` --------- Signed-off-by: Timon Engelke <[email protected]> Signed-off-by: amol-verma-allen <[email protected]>
Which problem is this PR solving?
Currently, Jaeger sends its traces to ElasticSearch as uncompressed text. Since text is can be compressed quite well, enabling Gzip compression can significantly reduce Jaeger's network traffic. ElasticSearch has accepted compressed requests since version 5.0 and since the same version it has already sent compressed responses by default (cf. elastic/elasticsearch@0a6f40c).
Description of the changes
--es.http-compression=true|false
that can be used to opt-out of compression . The setting is already supported by both client libraries that are used.How was this change tested?
I tested the change running a local ElasticSearch instance and
SPAN_STORAGE_TYPE=elasticsearch ./cmd/collector/collector-linux-amd64 --es.http-compression=true
. I sent traces to Jaeger usingtracepusher
and observed the network traffic between Jaeger and ElasticSearch usingtcpdump
to verify that the traffic is indeed compressed.Checklist
jaeger
:make lint test
jaeger-ui
:npm run lint
andnpm run test