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

Add new Elasticsearch reader implementation #2364

Merged
merged 6 commits into from
Aug 19, 2020

Conversation

pavolloffay
Copy link
Member

@pavolloffay pavolloffay commented Jul 31, 2020

This PR adds new Elasticsearch reader implementation that uses https://github.com/elastic/go-elasticsearch which is the client that ES OTEL exporter uses and we would like to use it for all interactions with ES.

Notable changes:

@pavolloffay pavolloffay requested a review from a team as a code owner July 31, 2020 13:35
@pavolloffay pavolloffay changed the title Add new Elasticsearch reader implementation WIP: Add new Elasticsearch reader implementation Jul 31, 2020
@pavolloffay pavolloffay changed the title WIP: Add new Elasticsearch reader implementation Add new Elasticsearch reader implementation Aug 3, 2020
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Copy link
Contributor

@objectiser objectiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only part way through the PR, will look at the rest later - but one question I wanted to ask was about the location the ES client code.

Previously it was under the otel exporter because it was only handling ES writer - but now it also includes the query/reader side, having it reside under the exporter hierarchy is not so meaningful.

If we were to move it to a more independent location, would this cause issues with dependencies from the exporter? Or is there a suitable location that would be ok to use from exporter and query service?

@pavolloffay
Copy link
Member Author

If we were to move it to a more independent location, would this cause issues with dependencies from the exporter? Or is there a suitable location that would be ok to use from exporter and query service?

The new reader has to reside in the same go module as the esclient package which is at the moment the Jaeger OTEL go module.

We should move the esclient to Jaeger core module with the reader. I would rather do that once this is merged to keep the changes minimal as this is already too large :/.

Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
@pavolloffay pavolloffay closed this Aug 5, 2020
@pavolloffay pavolloffay reopened this Aug 5, 2020
@codecov
Copy link

codecov bot commented Aug 5, 2020

Codecov Report

Merging #2364 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2364      +/-   ##
==========================================
- Coverage   95.61%   95.60%   -0.02%     
==========================================
  Files         206      206              
  Lines       10542    10548       +6     
==========================================
+ Hits        10080    10084       +4     
- Misses        394      396       +2     
  Partials       68       68              
Impacted Files Coverage Δ
...lugin/sampling/strategystore/adaptive/processor.go 99.20% <0.00%> (-0.80%) ⬇️
plugin/storage/integration/integration.go 80.38% <0.00%> (-0.48%) ⬇️
plugin/storage/kafka/options.go 94.05% <0.00%> (+0.37%) ⬆️
cmd/flags/admin.go 79.36% <0.00%> (+1.58%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9529bee...c379098. Read the comment docs.

Copy link
Contributor

@objectiser objectiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few more comments - will eventually complete the review :)

"io"
)

const multiSearchHeaderFormat = `{"ignore_unavailable": "true"}` + "\n"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a comment to explain how this value relates to "HeaderFormat"?

@@ -115,57 +113,55 @@ func (s *IntegrationTest) esCleanUp(allTagsAsFields bool) error {
}

func (s *IntegrationTest) initSpanstore(allTagsAsFields bool) error {
bp, _ := s.client.BulkProcessor().BulkActions(1).FlushInterval(time.Nanosecond).Do(context.Background())
s.bulkProcessor = bp
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assume the bulk processor is being removed as it will now be supported via the otel batch processor?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct

Copy link
Contributor

@objectiser objectiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - just the few comments here and above.

Signed-off-by: Pavol Loffay <ploffay@redhat.com>
@pavolloffay
Copy link
Member Author

@objectiser PR updated

@pavolloffay pavolloffay merged commit 2b5fe11 into jaegertracing:master Aug 19, 2020
@idohalevi
Copy link

@pavolloffay I've noticed that since this PR the query to ES, when tags included, changed from:

"bool": { "must": { "match": { "tag.error": { "query": "true" } } } }

To:

"must": { "regexp": { "tag.error": { "value": "true" } } }

Any reason for this? I get 500 when I'm trying to search any tag that is not mapped to a keyword

@pavolloffay
Copy link
Member Author

It might be a bug, could you please open an issue with some reproducer?

@idohalevi
Copy link

@pavolloffay sure #2540

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants