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

fix: deal with orphan traces in trace cache #1405

Merged
merged 4 commits into from
Oct 31, 2024

Conversation

VinozzZ
Copy link
Contributor

@VinozzZ VinozzZ commented Oct 31, 2024

Which problem is this PR solving?

If for some reason, a trace that doesn't belong to a peer in the trace cache missed its trace decision from its decider, it will stay in the cache forever.

This PR introduce a clean up mechanism for the scenario above.

  • When a trace has expired more than 2 times of the TraceTimeout, we will forward a proxy span to its decider so that the decider will publish the trace decision again.
  • When a trace has expired more than 4 times of the TraceTimeout, we will just make a decision for that partial trace from the current host.

Short description of the changes

  • modify the filter function in sendExpiredTraces to also return traces that have expired for too long
  • remove return value from trace cache interface since its no longer used
  • fix trace_cache histogram metrics to pass in the duration as float64
  • add test for the new sendExpiredTraces behavior

@VinozzZ VinozzZ requested a review from a team as a code owner October 31, 2024 19:58
@VinozzZ VinozzZ self-assigned this Oct 31, 2024
@VinozzZ VinozzZ added the type: enhancement New feature or request label Oct 31, 2024
@VinozzZ VinozzZ added this to the v2.9 milestone Oct 31, 2024
collect/collect.go Outdated Show resolved Hide resolved
Comment on lines +641 to +646
i.PeerTransmission.EnqueueEvent(i.createDecisionSpan(&types.Span{
TraceID: trace.ID(),
Event: types.Event{
Context: trace.GetSpans()[0].Context,
},
}, trace, i.Sharder.WhichShard(trace.ID())))
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm curious what impact this will have on network traffic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This should be an edge case and we are essentially just sending a trace id. Hopefully it won't have too big of an impact

Copy link
Contributor

@kentquirk kentquirk left a comment

Choose a reason for hiding this comment

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

I'm worried about that warning, but otherwise this looks good.

if !i.IsMyTrace(trace.ID()) {
err := errors.New("cannot make a decision for partial traces")

i.Logger.Warn().WithFields(map[string]interface{}{
Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't this really common? Do we actually want to be sending thousands of copies of this warning?

If we keep it, I think the error message could be clearer (what kind of decision are we trying to make?).

And finally, it's a constant string -- why construct an error out of it, and then convert it back to a string?

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 agree with you concern. I changed the log level to debug and the message to be more specific

collect/cache/cache.go Outdated Show resolved Hide resolved
@VinozzZ VinozzZ merged commit 422bee6 into main Oct 31, 2024
5 checks passed
@VinozzZ VinozzZ deleted the yingrong/deal_with_orphan_traces branch October 31, 2024 22:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants