-
Notifications
You must be signed in to change notification settings - Fork 109
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
flow output not paired up precisely #75
Comments
But, "There are four annotations the one span must have in order to construct a On Mon, Jul 4, 2016 at 8:21 PM, Adrian Cole notifications@github.com
|
@hubayirp I'm aware of what the annotations are used for, I'm just curious what your comment is eluding to. Can you be more precise with your recommendation? |
In Spigo, there is no acknowledgement of a Put. That might be the issue. It you look at a GetRequest/GetResponse you should see the full set of four Adrian On Monday, July 4, 2016, Adrian Cole notifications@github.com wrote:
|
ic, so this is about a fire-and-forget operation. duration is tricky to derive since we can't derive the time spent doing the Put from annotations. One way is we could fabricate the time spent doing the put (ex adding span.duration). Another way is for me to find another file to look at :) |
seems to also be the case in a root span of type
|
The getresponse should be the same traceid to complete the flow I could generate a response for a put, it's needed to simulate failures to Adrian On Monday, July 4, 2016, Adrian Cole notifications@github.com wrote:
|
maybe something isn't emitting the GetResponse events to the flow json
recorder thing for the root span. I spot checked a couple, and they don't
seem to have the closing event.
https://github.com/adrianco/spigo/blob/master/json_metrics/netflix_flow.json
https://github.com/adrianco/spigo/blob/master/json_metrics/lamp_flow.json
|
Ok. I'll take a look. On Monday, July 4, 2016, Adrian Cole notifications@github.com wrote:
|
Looking at the flow data from cassandra, I noticed a mismatch on bookend annotations.
For example, something is logging ["cs", "sr"] on a root span. This is a bit odd, as root spans either start with a "cs" or an "sr", and end (respectively) with an "cr" or "ss". This leaves the following normal combinations, none of which being ["cs", "sr"].
["cs", "cr"]
["sr", "ss"]
["cs", "sr", "ss", "cr"]
Reason I mention this is that I'm working on cassandra tuning of zipkin, and the input data having root spans like ["cs", "sr"] leaves no means to accurately compute the span's duration (since neither the client was closed, nor the server opened). If we can change the code to generate one of the above forms, the test I'm doing will be more realistic.
The text was updated successfully, but these errors were encountered: