UI common problems detection and highlight #1484

Open
fedj opened this Issue Jan 11, 2017 · 3 comments

Projects

None yet

3 participants

@fedj
Contributor
fedj commented Jan 11, 2017

When integrating Zipkin, it can happen that the instrumentation acts weirdly.
When there is a problem in the trace (example: SS is after SR), the trace is displayed badly and that's the only way to detect that there is a problem.

I think that there are common patterns that could be detected at runtime (and we could add more and more rules with more experience).

The idea would be that the UI could display warnings about wrong patterns to alert integrators that there might be a problem.

It can also be logged in the collector for spans problems.

@adriancole
Contributor
@cburroughs
Contributor

Would the actual "badness" detection happen on the server, or in javascript? My initial inclination leans towards server side, but I"m not sure if adding more fields to the API response has complications or not.

@cburroughs cburroughs added a commit to cburroughs/zipkin that referenced this issue Jan 13, 2017
@cburroughs cburroughs do not silently drop subsequent spans missing a parent
Currently zipkin models traces as a tree of spans.  During the
conversation from a list (or whatever the underlying storage engine
uses) to a tree, spans are dropped if more than one of them is missing
a parentId (it is a "root" node).  This appears to be an unintentional
regression (possibly around 9d8261a),
since the comment still indicate a workaround for this problem:
attribute missing parents to root.

This is still imperfect, but exposes it to the the user so they can
debug the instrumentation problem instead of silently dropping data.
Note that the workaround only applies when constructing a tree
internally the actual spans returned by the API still have no
parentID, and this is what is displayed in the web ui.

This problem is alluded to in #324, but the thrust of that ticket is
modeling asynchronous actions.

Highlighting suspect traces is discussed in #1484 and this condition
would be a prime candidate.
6237bad
@cburroughs cburroughs added a commit to cburroughs/zipkin that referenced this issue Jan 13, 2017
@cburroughs cburroughs do not silently drop subsequent spans missing a parent
Currently zipkin models traces as a tree of spans.  During the
conversation from a list (or whatever the underlying storage engine
uses) to a tree, spans are dropped if more than one of them is missing
a parentId (it is a "root" node).  This appears to be an unintentional
regression (possibly around 9d8261a),
since the comment still indicate a workaround for this problem:
attribute missing parents to root.

This is still imperfect, but exposes it to the the user so they can
debug the instrumentation problem instead of silently dropping data.
Note that the workaround only applies when constructing a tree
internally the actual spans returned by the API still have no
parentID, and this is what is displayed in the web ui.

This problem is alluded to in #324, but the thrust of that ticket is
modeling asynchronous actions.

Highlighting suspect traces is discussed in #1484 and this condition
would be a prime candidate.
2787e5c
@adriancole
Contributor
@adriancole adriancole added a commit that referenced this issue Jan 16, 2017
@cburroughs @adriancole cburroughs + adriancole do not silently drop subsequent spans missing a parent (#1487)
Currently zipkin models traces as a tree of spans.  During the
conversation from a list (or whatever the underlying storage engine
uses) to a tree, spans are dropped if more than one of them is missing
a parentId (it is a "root" node).  This appears to be an unintentional
regression (possibly around 9d8261a),
since the comment still indicate a workaround for this problem:
attribute missing parents to root.

This is still imperfect, but exposes it to the the user so they can
debug the instrumentation problem instead of silently dropping data.
Note that the workaround only applies when constructing a tree
internally the actual spans returned by the API still have no
parentID, and this is what is displayed in the web ui.

This problem is alluded to in #324, but the thrust of that ticket is
modeling asynchronous actions.

Highlighting suspect traces is discussed in #1484 and this condition
would be a prime candidate.
9a83aa6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment