Skip to content

[ES][v2] Refactor from_dbmodel and to_dbmodel to accept and return DB Spans #6934

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 13 commits into from
Mar 29, 2025

Conversation

Manik2708
Copy link
Contributor

Which problem is this PR solving?

Fixes a part of: #6458

Description of the changes

  • This is a prerequisite for the full implementation of converting OTLP Spans to db spans and vice-versa

How was this change tested?

  • Unit Tests

Checklist

Signed-off-by: Manik2708 <[email protected]>
Signed-off-by: Manik2708 <[email protected]>
Signed-off-by: Manik2708 <[email protected]>
@Manik2708 Manik2708 requested a review from a team as a code owner March 26, 2025 16:00
@Manik2708 Manik2708 requested a review from jkowall March 26, 2025 16:00
@Manik2708
Copy link
Contributor Author

@yurishkuro @mahadzaryab1 Please review this PR, if the changes look good, I will complete the code-coverage. Initially I thought to raise PR seperately for both files but their tests are inter-related, therefore I had to do them in a single PR.

return traceData, nil
}

func regroup(batches []*model.Batch) []*model.Batch {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Grouping is removed and therefore every span has it's own resource.

@@ -183,37 +93,71 @@ type scope struct {
name, version string
}

func jSpansToInternal(spans []*model.Span, dest ptrace.ScopeSpansSlice) {
spansByLibrary := make(map[scope]ptrace.SpanSlice)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can't group spans with same scope together as before this they should have the same resource which can't be possible in our case.

case dbmodel.BoolType:
convBoolVal, err := strconv.ParseBool(tagValue)
if err != nil {
putConversionErrKeyValuePair(tag, err, dest)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am confused for this, whether should I return the error or put the error as an attribute in the span?

Copy link
Member

Choose a reason for hiding this comment

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

we have similar conversion implemented in convertKeyValue in internal/storage/v1/elasticsearch/spanstore/to_domain.go. It doesn't have to be much different here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That is returning error, so we should also?

Copy link

codecov bot commented Mar 26, 2025

Codecov Report

Attention: Patch coverage is 98.60140% with 4 lines in your changes missing coverage. Please review.

Project coverage is 96.18%. Comparing base (26bfb4f) to head (ab91fc5).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
...torage/v2/elasticsearch/tracestore/from_dbmodel.go 97.27% 2 Missing and 2 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #6934      +/-   ##
==========================================
- Coverage   96.26%   96.18%   -0.08%     
==========================================
  Files         343      344       +1     
  Lines       20313    20255      -58     
==========================================
- Hits        19554    19482      -72     
- Misses        574      583       +9     
- Partials      185      190       +5     
Flag Coverage Δ
badger_v1 10.21% <ø> (ø)
badger_v2 2.12% <ø> (ø)
cassandra-4.x-v1-manual 15.36% <ø> (ø)
cassandra-4.x-v2-auto 2.11% <ø> (ø)
cassandra-4.x-v2-manual 2.11% <ø> (ø)
cassandra-5.x-v1-manual 15.36% <ø> (ø)
cassandra-5.x-v2-auto 2.11% <ø> (ø)
cassandra-5.x-v2-manual 2.11% <ø> (ø)
elasticsearch-6.x-v1 20.12% <ø> (ø)
elasticsearch-7.x-v1 20.21% <ø> (ø)
elasticsearch-8.x-v1 20.38% <ø> (-0.06%) ⬇️
elasticsearch-8.x-v2 2.12% <ø> (ø)
grpc_v1 11.28% <ø> (ø)
grpc_v2 8.23% <ø> (ø)
kafka-3.x-v1 10.51% <ø> (ø)
kafka-3.x-v2 2.12% <ø> (ø)
memory_v2 2.12% <ø> (ø)
opensearch-1.x-v1 20.26% <ø> (ø)
opensearch-2.x-v1 20.26% <ø> (-0.06%) ⬇️
opensearch-2.x-v2 2.12% <ø> (ø)
tailsampling-processor 0.57% <ø> (ø)
unittests 94.96% <98.60%> (-0.09%) ⬇️

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.

Comment on lines 192 to 201
if !ok {
// We have to do this as we are unsure that whether bool will be a string or a bool
tagBoolVal, boolOk := tag.Value.(bool)
if boolOk && tag.Type == dbmodel.BoolType {
dest.PutBool(tag.Key, tagBoolVal)
} else {
dest.PutStr(tag.Key, "Got non string value for the key "+tag.Key)
}
continue
}
Copy link
Member

Choose a reason for hiding this comment

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

I don't follow what this is doing. Why does bool require different handling that all other types handled in the switch statement?

Copy link
Contributor Author

@Manik2708 Manik2708 Mar 27, 2025

Choose a reason for hiding this comment

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

The Value of tag is any not string and in case of bool the values are in-consistent. Sometimes it is "true" and sometimes it is true, so we need to take care of both the cases!

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.

please make high level fixes suggested in the comments, its difficult to review when old/new code is all mixed up.

@yurishkuro
Copy link
Member

btw, this is the equivalent for ClickHouse model, which somehow seems a lot cleaner

https://github.com/jaegertracing/jaeger/pull/6935/files

@Manik2708
Copy link
Contributor Author

btw, this is the equivalent for ClickHouse model, which somehow seems a lot cleaner

https://github.com/jaegertracing/jaeger/pull/6935/files

@yurishkuro Thanks for suggestions. When I was modifying the code, I was also concerned about code cleaniness. But then I was also worried about PR becoming excessively large. Therefore I decided to keep the scope of this PR just to replace model.Batch with []dbmodel.Span without changing any name and structure. But now I could understand that it has made this PR difficult to review. My exact plan was:

  1. Replacing model with dbmodel (This PR)
  2. Implementing ToModel struct with tagDotReplacement and changing the structure of to_dbmodel.go and fixing the tests (Next PR)
  3. Implementing FromModel struct with tagDotReplacement and changing the structure of from_dbmodel.go (Next PR).

@Manik2708 Manik2708 requested a review from yurishkuro March 27, 2025 06:37
Signed-off-by: Manik2708 <[email protected]>
Signed-off-by: Manik2708 <[email protected]>
@Manik2708
Copy link
Contributor Author

@yurishkuro @mahadzaryab1 Please review this PR, as it is a blocker for next PRs!

Signed-off-by: Yuri Shkuro <[email protected]>
@Manik2708
Copy link
Contributor Author

@yurishkuro Thanks for the commit! Should I work on code-coverage now?

Signed-off-by: Yuri Shkuro <[email protected]>
Signed-off-by: Yuri Shkuro <[email protected]>
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.

ok to merge this but it needs more clean-up. There is too much business logic that should not be present in the db layer. The job of db layer is to capture information without a loss, not to perform business logic translations.

}

func jProcessToInternalResource(process *model.Process, dest pcommon.Resource) {
if process == nil || process.ServiceName == noServiceName {
func dbProcessToResource(process dbmodel.Process, destinationResource pcommon.Resource) {
Copy link
Member

Choose a reason for hiding this comment

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

avoid unnecessary complex variable names. In this case what is even the alternative to it being "destination"?

Suggested change
func dbProcessToResource(process dbmodel.Process, destinationResource pcommon.Resource) {
func dbProcessToResource(process dbmodel.Process, resource pcommon.Resource) {

Comment on lines 48 to 50
if process.ServiceName == "" || process.ServiceName == noServiceName {
return
}
Copy link
Member

Choose a reason for hiding this comment

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

there's no point to this check

spansByLibrary := make(map[scope]ptrace.SpanSlice)

for _, span := range spans {
func setSpansFromDbSpans(dbSpans []*dbmodel.Span, resourceSpans ptrace.ResourceSpansSlice) error {
Copy link
Member

Choose a reason for hiding this comment

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

use consistent naming, if you have dbProcessToResource then this should be

Suggested change
func setSpansFromDbSpans(dbSpans []*dbmodel.Span, resourceSpans ptrace.ResourceSpansSlice) error {
func dbSpansToSpans(dbSpans []*dbmodel.Span, resourceSpans ptrace.ResourceSpansSlice) error {

@yurishkuro yurishkuro added the changelog:exprimental Change to an experimental part of the code label Mar 29, 2025
@yurishkuro yurishkuro enabled auto-merge March 29, 2025 16:25
@Manik2708
Copy link
Contributor Author

ok to merge this but it needs more clean-up. There is too much business logic that should not be present in the db layer. The job of db layer is to capture information without a loss, not to perform business logic translations.

Ok, so should I work on the cleanup? If yes, then what should be the forwarding step for the cleanup? Also code coverage is below threshold, should I complete it in this PR? Or in a different PR?

Signed-off-by: Manik2708 <[email protected]>
auto-merge was automatically disabled March 29, 2025 18:25

Head branch was pushed to by a user without write access

@yurishkuro yurishkuro added this pull request to the merge queue Mar 29, 2025
@yurishkuro
Copy link
Member

Ok, so should I work on the cleanup?

historically we used snapshot based testing for transformers, where you have a set of JSON fixtures used to perform round-trip conversion and to cover the edge cases. We should switch testing to that mode, e.g. by starting with the fixtures in v1 implementation and creating the corresponding OTLP files from them.

@Manik2708
Copy link
Contributor Author

Ok, so should I work on the cleanup?

historically we used snapshot based testing for transformers, where you have a set of JSON fixtures used to perform round-trip conversion and to cover the edge cases. We should switch testing to that mode, e.g. by starting with the fixtures in v1 implementation and creating the corresponding OTLP files from them.

Got it, should I work on it now or implement the writer/reader for v2?

Merged via the queue into jaegertracing:main with commit 97c6778 Mar 29, 2025
56 checks passed
@yurishkuro
Copy link
Member

you can do both in parallel, they are now independent tasks and won't conflict with the files.

amilbcahat pushed a commit to amilbcahat/jaeger that referenced this pull request May 4, 2025
…n DB Spans (jaegertracing#6934)

## Which problem is this PR solving?
Fixes a part of: jaegertracing#6458 

## Description of the changes
- This is a prerequisite for the full implementation of converting OTLP
Spans to db spans and vice-versa

## How was this change tested?
- Unit Tests

## 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: Manik2708 <[email protected]>
Signed-off-by: Yuri Shkuro <[email protected]>
Co-authored-by: Yuri Shkuro <[email protected]>
amilbcahat pushed a commit to amilbcahat/jaeger that referenced this pull request May 4, 2025
…n DB Spans (jaegertracing#6934)

## Which problem is this PR solving?
Fixes a part of: jaegertracing#6458

## Description of the changes
- This is a prerequisite for the full implementation of converting OTLP
Spans to db spans and vice-versa

## How was this change tested?
- Unit Tests

## 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: Manik2708 <[email protected]>
Signed-off-by: Yuri Shkuro <[email protected]>
Co-authored-by: Yuri Shkuro <[email protected]>
Signed-off-by: amol-verma-allen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/storage changelog:exprimental Change to an experimental part of the code v2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants