Skip to content

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

Merged
merged 2 commits into from
Apr 26, 2025

Conversation

timonegk
Copy link
Contributor

@timonegk timonegk commented Apr 25, 2025

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

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]>
@timonegk timonegk requested a review from a team as a code owner April 25, 2025 07:27
@timonegk timonegk requested a review from albertteoh April 25, 2025 07:27
Copy link
Member

@yurishkuro yurishkuro left a 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?

@timonegk
Copy link
Contributor Author

timonegk commented Apr 25, 2025

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.

@yurishkuro
Copy link
Member

It's the right way to have is as an option, but I agree it should be on by default

@yurishkuro yurishkuro added the changelog:breaking-change Change that is breaking public APIs or established behavior label Apr 25, 2025
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]>
@yurishkuro yurishkuro enabled auto-merge April 26, 2025 20:17
Copy link

codecov bot commented Apr 26, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.05%. Comparing base (e22fa5d) to head (3f55115).
Report is 5 commits behind head on main.

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     
Flag Coverage Δ
badger_v1 9.95% <0.00%> (-0.02%) ⬇️
badger_v2 2.06% <0.00%> (-0.01%) ⬇️
cassandra-4.x-v1-manual 14.97% <0.00%> (-0.02%) ⬇️
cassandra-4.x-v2-auto 2.05% <0.00%> (-0.01%) ⬇️
cassandra-4.x-v2-manual 2.05% <0.00%> (-0.01%) ⬇️
cassandra-5.x-v1-manual 14.97% <0.00%> (-0.02%) ⬇️
cassandra-5.x-v2-auto 2.05% <0.00%> (-0.01%) ⬇️
cassandra-5.x-v2-manual 2.05% <0.00%> (-0.01%) ⬇️
elasticsearch-6.x-v1 19.99% <63.63%> (+0.05%) ⬆️
elasticsearch-7.x-v1 20.07% <63.63%> (+0.05%) ⬆️
elasticsearch-8.x-v1 20.25% <72.72%> (+0.06%) ⬆️
elasticsearch-8.x-v2 2.06% <0.00%> (-0.01%) ⬇️
grpc_v1 11.50% <0.00%> (-0.02%) ⬇️
grpc_v2 2.06% <0.00%> (-0.01%) ⬇️
kafka-3.x-v1 10.23% <0.00%> (-0.02%) ⬇️
kafka-3.x-v2 2.06% <0.00%> (-0.01%) ⬇️
memory_v2 2.06% <0.00%> (-0.01%) ⬇️
opensearch-1.x-v1 20.12% <63.63%> (+0.05%) ⬆️
opensearch-2.x-v1 20.12% <63.63%> (+0.05%) ⬆️
opensearch-2.x-v2 2.06% <0.00%> (-0.01%) ⬇️
query 2.06% <0.00%> (-0.01%) ⬇️
tailsampling-processor 0.56% <0.00%> (-0.01%) ⬇️
unittests 94.82% <100.00%> (+0.04%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@yurishkuro yurishkuro added this pull request to the merge queue Apr 26, 2025
Merged via the queue into jaegertracing:main with commit 1b1cfe2 Apr 26, 2025
57 checks passed
amilbcahat pushed a commit to amilbcahat/jaeger that referenced this pull request May 4, 2025
…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]>
amilbcahat pushed a commit to amilbcahat/jaeger that referenced this pull request May 4, 2025
…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]>
@timonegk timonegk deleted the add-http-compression branch May 7, 2025 08:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/storage changelog:breaking-change Change that is breaking public APIs or established behavior enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants