-
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
[refactor]: Refactor Frontend Trace OpenTelemetry Implementation #7390
Conversation
|
||
/// Adds event to the span on the top of the stack, related to trace | ||
/// with `trace_id`. If activity is TRITONSERVER_TRACE_REQUEST_START, | ||
/// or TRITONSERVER_TRACE_COMPUTE_START, starts a new span and adds it |
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 not let caller use StartSpan
for those event?
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.
Could you please clarify?
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.
Could you add an example for how the start/end detection looks like for custom backend tracing API?
@Tabrizian this is just a re-factor for the frontend. The actual custom backend implementation PR will be up shortly |
Co-authored-by: Iman Tabrizian <[email protected]>
6b60d93
to
864cc75
Compare
What does the PR do?
This PR introduces an improvement to our frontend OpenTelemetry tracing implementation. The main goal of this refactoring is to enhance the reliability and flexibility of the system.
Key Changes:
parent_id
for every trace, I utilize this and introduced an unordered map to keep spans in stacks. Each trace and sub-trace has its own stack. When stack is empty, I useparent_id
to check the top of the parent's stack to get parent span's information.Custom backend tracing
implementation to avoid handling of the complex logic for multiple nested custom spans, i.e. we simply look at the top of the stack.Checklist
<commit_type>: <Title>
Commit Type:
Check the conventional commit type
box here and add the label to the github PR.
Related PRs:
N/A
Where should the reviewer start?
trace.h
Test plan:
Caveats:
Background
Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)
N/A