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.

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

Icon / demarcation for client spans with no responding server span #132

Open
tiffon opened this issue Dec 7, 2017 · 8 comments
Open

Icon / demarcation for client spans with no responding server span #132

tiffon opened this issue Dec 7, 2017 · 8 comments

Comments

@tiffon
Copy link
Member

tiffon commented Dec 7, 2017

Feature request:

When there is a client span with no responding server span, place some kind of indication that there is missing data.

Consider generalizing this to include the current functionality of marking spans with error:true and to enable other scenarios.

@tiffon tiffon self-assigned this Dec 7, 2017
@black-adder
Copy link
Contributor

You want the actual work of finding these inconsistencies done in the query service or do everything on the FE?

@tiffon
Copy link
Member Author

tiffon commented Dec 11, 2017

@black-adder I think it would be fine for this to be done on the front-end.

@yurishkuro
Copy link
Member

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.

@tiffon
Copy link
Member Author

tiffon commented Dec 16, 2017

@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
  • Spans with db.statement tag (or sql as seems to be a common practice)
  • Spans that have a log message with a stack-trace
  • Spans with an invalid or missing reference
  • Spans without any tags or with a process that has no tags

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?

@yurishkuro
Copy link
Member

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.

@tiffon
Copy link
Member Author

tiffon commented Dec 19, 2017

screen shot 2017-12-19 at 2 15 06 am copy

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.

  1. The first arrow refers to the timeline header. On the far left there is a "7" with a vertical ellipsis. This is a dropdown menu which will allow the user to toggle which icons are enabled. The "7" indicates seven icons are enabled. The dropdown menu is not pictured.
  2. The first row has three icons: an error icon, a warning icon (as an example) and a DB icon (to indicate a SQL statement in the tags).
  3. The third arrow points to a row that has four icons. As there isn't enough room to show four icons, the icons are shown on mouse-over as a tooltip (not pictured).
  4. The fourth and fifth arrow indicates rows with an error icon.
  5. A row with an error icon.

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:

  • A column for the icons keeps them organized instead of having icon-chaos with icons scattered throughout the span name area, disrupting the alignment of the text, various colors, etc.
  • The column is left of the span name. If the column were to the right of the span name it might hinder visually skimming the rows and associating a name with a span-bar.
  • Toggling icons on and off would be pretty easy
  • It sort of accomadates N number of icons — the user can make the column wider
  • Icons stand out a bit more — currently, error icons are embedded and therefore have less visually significance

@yurishkuro
Copy link
Member

lgtm. A bit concerned that it might become too busy.

Is there a specific icon font you have in mind?

@tiffon
Copy link
Member Author

tiffon commented Dec 19, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants