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.

Sign up for GitHub

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

Jump to bottom

Add initial lime tracing #2706

Merged
merged 1 commit into from
Sep 17, 2024
Merged

Add initial lime tracing #2706

merged 1 commit into from
Sep 17, 2024

Conversation

fhanau
Copy link
Collaborator

@fhanau fhanau commented Sep 12, 2024

See downstream PR for discussion.

@fhanau fhanau requested review from mikea and zebp September 12, 2024 22:42
@fhanau fhanau requested review from a team as code owners September 12, 2024 22:42
@fhanau fhanau requested review from dom96 and removed request for dom96 September 12, 2024 22:42
@fhanau fhanau force-pushed the felix/lime-spans-v1 branch 2 times, most recently from b22b816 to 081f031 Compare September 13, 2024 00:40
@jasnell
Copy link
Member

jasnell commented Sep 13, 2024

We're soon going to be implementing streaming traces alongside the current in-memory traces. We'd need to figure out how these spans fit into that model.

@mikea
Copy link
Collaborator

mikea commented Sep 13, 2024

We're soon going to be implementing streaming traces alongside the current in-memory traces. We'd need to figure out how these spans fit into that model.

I suggest we introduce a single TraceContext that will carry around both of current span builders and all the future tracing infrastucture around. Its interface might be disjoint (separate create child span calls for each branch), but we won't have to change function signatures again.

@fhanau
Copy link
Collaborator Author

fhanau commented Sep 16, 2024

We're soon going to be implementing streaming traces alongside the current in-memory traces. We'd need to figure out how these spans fit into that model.

I suggest we introduce a single TraceContext that will carry around both of current span builders and all the future tracing infrastucture around. Its interface might be disjoint (separate create child span calls for each branch), but we won't have to change function signatures again.

Created two structs to track both span builders/span parents. I deliberately did not make this a fully-fledged class since places where the spans will be used are expected to remain somewhat disparate, but it does make passing through parameters in getSubrequest() and SubrequestMetadata easier. We can refactor/extend it later when this seems helpful.

mikea
mikea reviewed Sep 16, 2024
View reviewed changes
Copy link
Collaborator

@mikea mikea left a comment

Choose a reason for hiding this comment

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

Let's get naming sorted out while I review the rest of the code.

I also worry that Lime as in limeSpans wouldn't age well. How about user tracing framework: UserSpanBuilder and userSpans?

src/workerd/io/trace.h Show resolved Hide resolved
src/workerd/io/trace.h Show resolved Hide resolved
src/workerd/io/trace.h Outdated Show resolved Hide resolved
src/workerd/api/actor.c++ Outdated Show resolved Hide resolved
mikea
mikea reviewed Sep 16, 2024
View reviewed changes
src/workerd/io/trace.h Outdated
private:
PipelineLogLevel pipelineLogLevel;
kj::Own<Trace> trace;

// own an instance of the pipeline to make sure it doesn't get destroyed
// before we're finished tracing
kj::Maybe<kj::Own<PipelineTracer>> parentPipeline;
kj::Own<WeakRef<WorkerTracer>> weakRef;
Copy link
Collaborator

Choose a reason for hiding this comment

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

also let's document this since you're saying yourself it is tricky.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Added a comment describing my current understanding of the issue.

mikea
mikea reviewed Sep 16, 2024
View reviewed changes
src/workerd/io/trace.h Outdated Show resolved Hide resolved
@fhanau
Copy link
Collaborator Author

fhanau commented Sep 17, 2024

Updated this based on the review comments, documentation should look quite a bit better now. Changing the name to user tracing will be done in a follow-up PR. workerd side is ready for review.

mikea
mikea approved these changes Sep 17, 2024
View reviewed changes
Copy link
Collaborator

@mikea mikea left a comment

Choose a reason for hiding this comment

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

lg. Lime rename can happen in a follow-up

@fhanau fhanau merged commit 0b073a7 into main Sep 17, 2024
12 of 13 checks passed
@fhanau fhanau deleted the felix/lime-spans-v1 branch September 17, 2024 21:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jasnell jasnell jasnell left review comments

@mikea mikea mikea approved these changes

@zebp zebp Awaiting requested review from zebp

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@fhanau @jasnell @mikea