Track libraries that properly address span timestamp and duration #49
Comments
codefromthecrypt
pushed a commit
to openzipkin/brave
that referenced
this issue
Sep 27, 2016
This change brings Brave into the best timestamp practice by doing the following: * Fixes unsafe access to Span.startTick * Records Span.startTick when starting any span the local process owns * Ensures Span.timestamp/duration are not reported on spans the local process doesn't own * Uses nanos offsets where available for annotation timestamps The above corrects the common misalignment of spans in the UI, where within a local process, operations that vary on microsecond basis have annotations that extend beyond the span duration. See openzipkin/openzipkin.github.io#49
|
here's the first step towards this openzipkin/brave#243 |
codefromthecrypt
pushed a commit
to spring-cloud/spring-cloud-sleuth
that referenced
this issue
Nov 6, 2016
This ensures spans that have remote set to true don't send Span.timestamp/duration. In the RPC span model, the client owns the timestamp and duration of the span. If we were propagated an id, we can assume that we shouldn't report timestamp or duration, rather let the client do that. Worst case we were propagated an unreported ID and Zipkin backfills timestamp and duration. See openzipkin/openzipkin.github.io#49
codefromthecrypt
pushed a commit
to spring-cloud/spring-cloud-sleuth
that referenced
this issue
Nov 7, 2016
This ensures spans that have remote set to true don't send Span.timestamp/duration. In the RPC span model, the client owns the timestamp and duration of the span. If we were propagated an id, we can assume that we shouldn't report timestamp or duration, rather let the client do that. Worst case we were propagated an unreported ID and Zipkin backfills timestamp and duration. See openzipkin/openzipkin.github.io#49
codefromthecrypt
pushed a commit
to spring-cloud/spring-cloud-sleuth
that referenced
this issue
Nov 7, 2016
This ensures spans that have remote set to true don't send Span.timestamp/duration. In the RPC span model, the client owns the timestamp and duration of the span. If we were propagated an id, we can assume that we shouldn't report timestamp or duration, rather let the client do that. Worst case we were propagated an unreported ID and Zipkin backfills timestamp and duration. See openzipkin/openzipkin.github.io#49
This was referenced Nov 22, 2016
Open
fedj
pushed a commit
to criteo-forks/zipkin
that referenced
this issue
Dec 28, 2016
As mentionned in openzipkin/openzipkin.github.io#49, timestamp should be set on span originators. In the case of a span sent from a mid-tier server (e.g. receiving a request from a instrumented service), it is not supposed to set the timestamp, leading to a log message when using cassandra as storage. This log can be only wrote when the span is an originator. It is still trying to guess the correct timestamp to cope with non-compliant tracers.
fedj
pushed a commit
to criteo-forks/zipkin
that referenced
this issue
Dec 28, 2016
As mentionned in openzipkin/openzipkin.github.io#49, timestamp should be set on span originators. In the case of a span sent from a mid-tier server (e.g. receiving a request from a instrumented service), it is not supposed to set the timestamp, leading to a log message when using cassandra as storage. This log can be only wrote when the span is an originator. It is still trying to guess the correct timestamp to cope with non-compliant tracers.
codefromthecrypt
pushed a commit
to openzipkin/zipkin
that referenced
this issue
Dec 28, 2016
As mentionned in openzipkin/openzipkin.github.io#49, timestamp should be set on span originators. In the case of a span sent from a mid-tier server (e.g. receiving a request from a instrumented service), it is not supposed to set the timestamp, leading to a log message when using cassandra as storage. This log can be only wrote when the span is an originator. It is still trying to guess the correct timestamp to cope with non-compliant tracers.
This was referenced Mar 16, 2017
codefromthecrypt
pushed a commit
to openzipkin/zipkin
that referenced
this issue
Aug 13, 2017
When "sr" is present without a timestamp, we assume this is a shared span. Moving this signal to the converter allows stackdriver-zipkin to reuse this when converting to their single-host types. See openzipkin/openzipkin.github.io#49
codefromthecrypt
pushed a commit
to openzipkin/zipkin
that referenced
this issue
Aug 13, 2017
When "sr" is present without a timestamp, we assume this is a shared span. Moving this signal to the converter allows stackdriver-zipkin to reuse this when converting to their single-host types. See openzipkin/openzipkin.github.io#49
|
tracking moved here https://cwiki.apache.org/confluence/display/ZIPKIN/Timestamps+in+shared+spans |
abesto
pushed a commit
to abesto/zipkin
that referenced
this issue
Sep 10, 2019
When "sr" is present without a timestamp, we assume this is a shared span. Moving this signal to the converter allows stackdriver-zipkin to reuse this when converting to their single-host types. See openzipkin/openzipkin.github.io#49
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Span.timestamp is problematic when misreported, or never reported. This issue will track known active zipkin libraries towards effective timestamp practice.
Summary of timestamp and duration logic
From http://zipkin.io/pages/instrumenting.html, the simplest logic for v1 format is:
When a server joins a span from incoming headers, it is sharing the span with
the client (who generated the headers). In that case, the server shouldn't
set Span.timestamp or duration since its view of the span is later and shorter than
the client.
Otherwise, you should set timestamp and duration on finished spans. That makes
sure indexing and duration queries work best.
Note v2 format includes a shared flag which is used to help with this problem
in v2 format, you always set timestamp and duration.
Status
Here are the status options for Span.timestamp/duration:
This is a list of zipkin libraries and their status in supporting Span.timestamp/duration
See #46
The text was updated successfully, but these errors were encountered: