-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Switch Jaeger receiver to internal data model #844
Switch Jaeger receiver to internal data model #844
Conversation
Codecov Report
@@ Coverage Diff @@
## master #844 +/- ##
==========================================
- Coverage 85.93% 85.32% -0.62%
==========================================
Files 157 159 +2
Lines 11841 12115 +274
==========================================
+ Hits 10176 10337 +161
- Misses 1297 1396 +99
- Partials 368 382 +14
Continue to review full report at Codecov.
|
1ccb464
to
7765622
Compare
@@ -33,7 +33,7 @@ const header = `// Copyright 2020 OpenTelemetry Authors | |||
// Code generated by "internal/data_generator/main.go". DO NOT EDIT. | |||
// To regenerate this file run "go run internal/data_generator/main.go". | |||
|
|||
package data` | |||
package pdata` |
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.
can you split all changes to the data_generator and generated files in a separate PR?
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.
done #850
receiver/jaegerreceiver/factory.go
Outdated
} | ||
|
||
// CreateMetricsReceiver creates a metrics receiver based on provided config. | ||
func (f *Factory) CreateMetricsReceiver( | ||
logger *zap.Logger, | ||
ctx context.Context, |
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.
For unused arguments use _
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.
done
span0.SetStartTime(pdata.TimestampUnixNano(uint64(t1.UnixNano()))) | ||
span0.SetEndTime(pdata.TimestampUnixNano(uint64(t2.UnixNano()))) | ||
span0.Status().InitEmpty() | ||
span0.Status().SetCode(pdata.StatusCode(otlptrace.Status_NotFound)) |
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.
add an issue to declare all statuses as constants in the pdata
.
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.
done #851
@@ -0,0 +1,272 @@ | |||
// Copyright 2019, OpenTelemetry Authors |
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.
2020?
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.
changed
// Number of special fields in the Node. See the code below that deals with special fields. | ||
const specialNodeAttrCount = 7 | ||
|
||
// Number of special fields in the Resource. | ||
const specialResourceAttrCount = 1 | ||
|
||
// Calculate maximum total number of attributes. It is OK if we are a bit higher than | ||
// the exact number since this is only needed for capacity reservation. | ||
maxTotalAttrCount := 0 | ||
if ocNode != nil { | ||
maxTotalAttrCount += len(ocNode.Attributes) + specialNodeAttrCount | ||
} | ||
if ocResource != nil { | ||
maxTotalAttrCount += len(ocResource.Labels) + specialResourceAttrCount | ||
} | ||
|
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.
why this change?
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.
This is just dead code
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.
Separate PR then :)
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.
done #852
94a8259
to
66c0d38
Compare
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.
Conversion were replicated from existing jaeger -> OC -> internal.
One concern:
We are getting ParentSpanID from Jaeger span links and writing the link to internal Span.Links slice as well. I'm not sure if it's desired behavior. I'd remove parent span link from the translated internal span and keep that information only ParentSpanID field. Keeping the link copy in Span.Links makes it even more confusing because, with the links conversion, we lose RefType information (like Span_Link_PARENT_LINKED_SPAN or Span_Link_TYPE_UNSPECIFIED), OTLP doesn't have that field.
@tigrannajaryan @pjanotti what do you think about it ^
@dmitryax I do not quite understand. Can you point to the old code that does this? You probably also need to check this with backend/UI team to make sure we don't break them if we change the behavior.
attrs := jTagsToInternalAttributes(span.Tags) | ||
setInternalSpanStatus(attrs, dest.Status()) | ||
if spanKindAttr, ok := attrs[tracetranslator.TagSpanKind]; ok { | ||
dest.SetKind(jSpanKindToInternal(spanKindAttr.StringVal())) | ||
} | ||
dest.Attributes().InitFromMap(attrs) |
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.
We convert a slice to map here, then convert the map to slice again. I suspect this may be slow. Let's get a perf profile once this is merged and see what it shows. If it is slow we can probably just do a one pass and convert the source Tags slice directly to dest attributes.
This is OK for now, but let's verify it.
@tigrannajaryan | You probably also need to check this with backend/UI team to make sure we don't break them if we change the behavior. |
@tigrannajaryan
|
In addition to the comment above, looks like we are not checking for this duplicate in OC SpanLinks during OC->Jaeger translation opentelemetry-collector/translator/trace/jaeger/protospan_to_jaegerproto.go Lines 492 to 509 in 75ae919
It means that Jaeger -> OC -> Jaeger translation most of the times adds a duplicate in Span.References for Parent span Id |
@pjanotti could you please take a look at the PR since you are the most familiar with original translation? |
3253c7d
to
e1374a6
Compare
@pjanotti @tigrannajaryan I've applied the change to the span links translation as described above. |
Appeared that HTTP Status code -> OC Status code translation is different between jaeger thrift -> OC and jaeger proto -> OC.
@owais @pjanotti do you know if it's intentional? In this PR I've applied the translation in both thrift and proto versions. |
e1374a6
to
ca5aa7d
Compare
Translation was replicated from existing jaeger -> OC -> internal logic.
ca5aa7d
to
54e252e
Compare
@dmitryax I know that jaeger proto version is also used by SAPM, so I would take the proto version of the translation as the canonical one and modify thirft to match it. |
@dmitryax actually, ignore that, I am not sure what I said is correct. Can you check with the backend team? |
We discussed the translation and all looks good. We will test it one more time when this goes to production. |
Translation was replicated from existing jaeger -> OC -> internal logic.
…matic Github workflow (open-telemetry#844)
…open-telemetry#844) * fix pipeline order when enabling k8sattributes * bump collector and document breakage * kubernetesAttributes example * regenerate examples * Update charts/opentelemetry-collector/UPGRADING.md Co-authored-by: Tyler Helmuth <12352919+TylerHelmuth@users.noreply.github.com> --------- Co-authored-by: Tyler Helmuth <12352919+TylerHelmuth@users.noreply.github.com>
Conversion were replicated from existing jaeger -> OC -> internal.
One concern:
We are getting ParentSpanID from Jaeger span links and writing the link to internal Span.Links slice as well. I'm not sure if it's desired behavior. I'd remove parent span link from the translated internal span and keep that information only ParentSpanID field. Keeping the link copy in Span.Links makes it even more confusing because, with the links conversion, we lose RefType information (like Span_Link_PARENT_LINKED_SPAN or Span_Link_TYPE_UNSPECIFIED), OTLP doesn't have that field.
@tigrannajaryan @pjanotti what do you think about it ^