Open tiffon opened 6 years ago
You want the actual work of finding these inconsistencies done in the query service or do everything on the FE?
@black-adder I think it would be fine for this to be done on the front-end.
Once we have XYS's trace quality metrics migrated to Jaeger backend, we could expose an endpoint that will return those metrics for a single trace, and the UI can display them. Would it make sense as a feature? When the metrics are displayed, they can provide navigation to the specific spans within the trace, which would be a superset of this issue.
@yurishkuro That sounds like a great feature; it will make those measurements much more concrete. I'll create a ticket for it. As an aside, your suggestion also sounds like a candidate for trace-derived features.
I think this ticket lends itself to a general mechanism for marking spans with an icon or some sort of demarcation. In addition to the incomplete RPC scenario the OP mentioned, there's been some discussion about the value of marking spans with http.status_code >= 400
with an error icon or a flag of some sort.
Ideas for possible demarcations:
span.kind=client
missing span.kind=server
span.kind=producer
missing span.kind=consumer
http.status_code >= 400
db.statement
tag (or sql
as seems to be a common practice)Each marking could be enabled/disabled on two levels: 1) globally via the UI config and 2) locally via a toggle in the UI (persisted to localStorage
). Additional markings can be configured by the UI config once it is switched to JavaScript. (I think the plugin design has a way to go before it is suitable for this sort of thing.)
What do you think?
this all sounds fine to me on paper, but I am unable to visualize how it would look, so some design mock-ups would be useful.
The screenshot attached is an initial take on one way this might work.
The screenshot has five arrows. They're on the right side, but that is so they are out of the way, visually.
The area of interest is a new left-most column that's been added for the icons.
The width of the left-most column would be adjustable.
The column widths and which icons are enabled would be persisted in local storage.
Some notes about this layout:
lgtm. A bit concerned that it might become too busy.
Is there a specific icon font you have in mind?
Great to hear.
Re icon library, not sure, yet. I'd like to switch UI libraries. I'm taking another look at ant.design, based on feedback from @saminzadeh.
One approach is to have a limited number of icons categories:
Limiting it in this way would make changing them out easier, at a later date.
Feature request:
Consider generalizing this to include the current functionality of marking spans with
error:true
and to enable other scenarios.