Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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(tracing): make spans resilient to performance clock drift #3434
fix(tracing): make spans resilient to performance clock drift #3434
Changes from 13 commits
7083983
5794fbc
7890388
a764b2b
e991a6c
4405fc0
ee10895
27d72df
44d9dc5
2a5fc2f
0149f56
7c540fe
7626ca2
26a27f0
488b5da
9cc92bf
8bddc96
91cfd37
63f3b2c
e66b75f
b848140
f4c1be0
8c48a34
6790d17
3b61190
5614bcb
f6d88aa
e763118
03c96c0
fd2398d
830c799
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
in core we have similar logic where we use
origin
for this check, and notnow
I believe they both work fine, but better to have consistency in the project, even maybe extract this logic into a function
isTimeInputPerformanceNow(time: TimeInput)
similar to the existing functionisTimeInputHrTime
, this is also self documenting and will make the comment below redundantThere 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 change is actually very important to the functioning of the PR. I think the function in core should be deprecated.
The reason to use
performance.now
is that we can be much more sure that a given number is a performance timestamp. A number before timeOrigin may be ingested from historical logs or come from an inconsistent time source which has been corrected and timeOrigin is wrong.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.
That makes sense, thanks for the response.
My point is that we are doing the same computation in 2 different places in 2 different ways. This comment is a suggestion to unify it (and maybe extract the logic into a function while we are at it). Could be done in this PR, later one, or not at all
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 version seems to be susceptible to drift in fetch instrumentation (undefined start + hrTime end):
opentelemetry-js/experimental/packages/opentelemetry-instrumentation-fetch/src/fetch.ts
Line 281 in 3290b25
Because hrTime() does
getTimeOrigin() + performance.now()
it would generate drifted HrTimeThere 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 because an
HrTime
formatted timestamp is not corrected in any case. Currently, the start time also uses the performance timing API indirectly because a start time is not provided and the performance clock is used. This means that in the current state the whole span is shifted anyway.My recommendation would be to:
Date.now
Either of these changes would fix the issue here, but I actually recommend we do both.
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.
Alternative to (2) would be to update fetch instrumentation to get start and end times from the performance timing API
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.
@t2t2 does the updated version address your concern?
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.
fetch and xhr have both been updated. I think this is resolved but I'll wait for @t2t2 to confirm.
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.
Yep