-
Notifications
You must be signed in to change notification settings - Fork 487
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
Log Markers on Spans #309
Log Markers on Spans #309
Conversation
Signed-off-by: Staffan Friberg <sfriberg@kth.se>
Signed-off-by: Staffan Friberg <sfriberg@kth.se>
awesome, resolves #119, a log outstanding issue. |
Codecov Report
@@ Coverage Diff @@
## master #309 +/- ##
==========================================
+ Coverage 83.04% 83.13% +0.09%
==========================================
Files 142 142
Lines 3149 3172 +23
Branches 649 654 +5
==========================================
+ Hits 2615 2637 +22
- Misses 427 428 +1
Partials 107 107
Continue to review full report at Codecov.
|
Maybe instead of showing all logs in the popup it should only show the log for the current tick, but with all log fields expanded (must be careful with max popup size in this case). It might get tricky / sensitive when there are many ticks next to each other. Another idea we previously discussed is when the span is expanded, then mousing over the logs highlights the corresponding tick on the span bar. |
It only shows for the "current tick", but I merge ticks close together. |
Signed-off-by: Staffan Friberg <sfriberg@medallia.com>
Signed-off-by: Staffan Friberg <sfriberg@kth.se>
Signed-off-by: Staffan Friberg <sfriberg@kth.se>
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.
Great PR! Thanks for creating it!
I've added a couple of small comments. Let me know if anything looks awry.
One caveat with the current implementation is that it will on a click in the popover expand the Span details in the main UI instead of anything in table inside the Popover. Any ideas how to get the more expected behavior of expanding the table in the popover instead?
I think it makes sense to keep the popover non-interactive. If the user is interacting with the popover to expand logs, etc., and then accidentally moves the mouse outside the popover, they will lose that state. If the user is interested in details, seems like expanding the row is a nice way to both present the details and keep the log-hints / popover simple.
What do you think?
If we end up going down the road of keeping the popover as-is, so clicking it expands the row instead of interactively expands items in the popover, then what do you think of remove the chevrons (the expand / collapse ">") from the popover, so the log items no longer look interactive?
packages/jaeger-ui/src/components/TracePage/TraceTimelineViewer/SpanBar.js
Show resolved
Hide resolved
rpc: { | ||
viewStart: number, | ||
viewEnd: number, | ||
color: string, | ||
}, | ||
setLongLabel: () => void, | ||
setShortLabel: () => void, | ||
trace: Trace, |
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.
Instead of pushing the trace down, maybe it makes sense to push the trace.startTime
down since it's only the startTime is needed? Alternatively, the Log
data can have a timestampOffset
field added when the HTTP trace payload is processed? E.g.
diff --git a/packages/jaeger-ui/src/model/transform-trace-data.js b/packages/jaeger-ui/src/model/transform-trace-data.js
index d18ef1e..bc67884 100644
--- a/packages/jaeger-ui/src/model/transform-trace-data.js
+++ b/packages/jaeger-ui/src/model/transform-trace-data.js
@@ -95,6 +95,8 @@ export default function transfromTraceData(data: TraceData & { spans: SpanWithPr
span.relativeStartTime = span.startTime - traceStartTime;
span.depth = depth - 1;
span.hasChildren = node.children.length > 0;
+ // eslint-disable-next-line no-param-reassign
+ span.logs.forEach(log => { log.timestampOffset = log.timestamp - traceStartTime });
span.references.forEach(ref => {
const refSpan: ?Span = (spanMap.get(ref.spanID): any);
if (refSpan) {
diff --git a/packages/jaeger-ui/src/types/trace.js b/packages/jaeger-ui/src/types/trace.js
index 5840e46..9c0c5a9 100644
--- a/packages/jaeger-ui/src/types/trace.js
+++ b/packages/jaeger-ui/src/types/trace.js
@@ -30,6 +30,7 @@ export type Link = {
export type Log = {
timestamp: number,
+ timestampOffset: number,
fields: Array<KeyValuePair>,
};
IMO passing trace.startTime
down is preferable as we'd be avoiding baking derived data into the redux state.
What do you think?
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.
Will change to push only the time stamp down, was debating back and forth as well on this and decided on sending the whole trace. Don't know if there is any perf difference with complex objects vs a simple primitive?
Perhaps something to consider for later is if the trace->span->log should backpointers so you could get the span from a log and then the trace from a span.
packages/jaeger-ui/src/components/TracePage/TraceTimelineViewer/utils.test.js
Outdated
Show resolved
Hide resolved
packages/jaeger-ui/src/components/TracePage/TraceTimelineViewer/utils.js
Outdated
Show resolved
Hide resolved
The main reason to allow expanding is to allow reading longs lines which otherwise would be truncated. I think most people would be fine with losing the state in the popup and common practice in other applications as well. It is just intended for some quick interaction. I'm fine with either solution, and leave the decision to you. :) Agree about removing the chevrons if we make it completely non-interactive. Back to the original question. I can't seem to figure out how to disable that a click in the popover expands the span details. Any clue what needs to change to disable that behavior? (that behavior is non-intuitive and unexpected :) ) |
Signed-off-by: Staffan Friberg <sfriberg@kth.se>
Signed-off-by: Joe Farro <joef@uber.com>
Signed-off-by: Joe Farro <joef@uber.com>
I found an issue where log markers that are on the far left, right at time=0 (for the current zoom) couldn't be triggered. It was a CSS issue; I pushed an update. Hope you don't mind.
I think adding event listeners for
I'm hesitant to have such full-fledged functionality in the logs popovers. Seems like it will get wierd when the height of the popover expands, might be a pain keep the popover positioned, correctly. I think it might be a nice UX to keep the span detail opening when you click in the popover but also expand the appropriate log entries. I tested it out, here. What do you think? |
Signed-off-by: Staffan Friberg <sfriberg@kth.se>
Was able to disable the clicking in the div. Trying to do it with the AccordionLogs would require several changes to expose the event to the handler methods give to AccordionLogs. I like the idea, my main concern is that it expands something that easily gets in the way of understanding the flow of the span in the UI. Think there are two ways to improve on that side. Easy one would be to make a second click collapse the details again. A more longterm/experimental way would be to consider if the span details should be shown on the side (static sidebar on the right or left) instead of inline with the spans which breaks visibility of spans as you want to look at details of one of them. |
I'll look into the onClick issue. I see what you mean about the span detail row interrupting the visual flow of span bars. Maybe we should expand the log items in the popover by default? Re switching to a details panel on the side, I'm absolutely a fan of this. This will allow us to use the same functionality to show span details in the trace graph and trace diffs views. (I thought we had a ticket for moving to a side panel, but I guess not.) |
Hover on log markers opens popover Click on log markers toggles span details Log marker popover is not interactive Signed-off-by: Joe Farro <joef@uber.com>
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.
The types on this function could be a bit more robust:
export function createViewedBoundsFunc({ min, max, viewStart, viewEnd}: {min: number, max: number, viewStart: number, viewEnd: number }): ViewedBoundsFunctionType {
/* ... */
}
But that's not critical. Otherwise looks good 👍
label={`${formatDuration(log.timestamp - timestamp)}`} | ||
onToggle={() => onItemToggle(log)} | ||
linksGetter={linksGetter} | ||
onToggle={interactive && onItemToggle ? () => onItemToggle(log) : null} |
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.
No sure what the preference/recommendation is.
Would it make sense to use undefined instead of null as it is defined as "onToggle?" in the properties?
More of a general question about using null vs undefined than anything.
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.
As a practice, I generally use null
, which differentiates something set to null
from something that's not there. E.g.
const o = {};
console.log(o.notThere === null); // false
// for convenience, `==` is easier than `value === null || value === undefined`
console.log(o.notThere == null); // true
packages/jaeger-ui/src/components/TracePage/TraceTimelineViewer/SpanBarRow.js
Show resolved
Hide resolved
packages/jaeger-ui/src/components/TracePage/TraceTimelineViewer/SpanDetail/AccordianLogs.js
Show resolved
Hide resolved
@everett980 Thanks for the catch re the flow types. Turns out |
Signed-off-by: Joe Farro <joef@uber.com>
@sfriberg The log markers are merged! 🎉 🎉 🎉Thanks so much for putting this together! |
* Log Markers on Spans Signed-off-by: Staffan Friberg <sfriberg@kth.se> * Make tests pass with empty logs for now Signed-off-by: Staffan Friberg <sfriberg@kth.se> * Simple test that log markers are created Signed-off-by: Staffan Friberg <sfriberg@medallia.com> * Push trace separately all they way down to SpanBar Signed-off-by: Staffan Friberg <sfriberg@kth.se> * Send Span all the way to SpanBar instead of Logs Signed-off-by: Staffan Friberg <sfriberg@kth.se> * PR comments Signed-off-by: Staffan Friberg <sfriberg@kth.se> * Update changelog for PR 309 Signed-off-by: Joe Farro <joef@uber.com> * CSS fix for logMarker hover at t0 Signed-off-by: Joe Farro <joef@uber.com> * Disable clicking Signed-off-by: Staffan Friberg <sfriberg@kth.se> * Tweaks to UX for span log markers Hover on log markers opens popover Click on log markers toggles span details Log marker popover is not interactive Signed-off-by: Joe Farro <joef@uber.com> * Fix changelog, missing "@ flow" and log-marker spacing Signed-off-by: Joe Farro <joef@uber.com> Signed-off-by: vvvprabhakar <vvvprabhakar@gmail.com>
Signed-off-by: Staffan Friberg sfriberg@kth.se
Which problem is this PR solving?
Currently to see log entries as part of the span you need to expand the details. This PR adds markers in the main Span UI for log entries with a popover showing the log details. Tightly packed log entries are grouped as a single marker until zoomed enough to be rendered separately.
Short description of the changes
The SpanBar class will now create markers for log entries.
Thanks to @tiffon for cleaning up the CSS and switching to Antd Popover instead of Tooltip.
One caveat with the current implementation is that it will on a click in the popover expand the Span details in the main UI instead of anything in table inside the Popover. Any ideas how to get the more expected behavior of expanding the table in the popover instead?