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

Track libraries that properly address span timestamp and duration #49

Closed
adriancole opened this Issue Sep 21, 2016 · 2 comments

Comments

Projects
None yet
1 participant
@adriancole
Copy link
Contributor

adriancole commented Sep 21, 2016

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:

unless (logging "sr" in an shared span) {
 set Span.timestamp and duration (both in microseconds)
}

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:

  • unsupported: the library never sets Span.timestamp/duration
  • always: the library sets Span.timestamp/duration even when it shouldn't
  • supported: the library sets Span.timestamp/duration only when it should

This is a list of zipkin libraries and their status in supporting Span.timestamp/duration

library version status notes
zipkin-js 0.4+ supported
py_zipkin 0.5+ supported
brave 3.13+ supported
spring-cloud-sleuth 1.0.11+ supported
finagle versions supporting zipkin-finagle supported At the current time, zipkin-finagle must be used in order to report timestamps properly
zipkin-ruby 0.12+ supported
ZipkinTracerModule
zipkin-go-opentracing 0.2.1+ supported
zipkin4net 0.3+ supported
akka-tracing
wingtips
jaeger

See #46

adriancole added a commit to openzipkin/brave that referenced this issue Sep 27, 2016

More precise timestamps by using nanos offsets where available
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
@adriancole

This comment has been minimized.

Copy link
Contributor Author

adriancole commented Sep 27, 2016

here's the first step towards this openzipkin/brave#243

adriancole added a commit to spring-cloud/spring-cloud-sleuth that referenced this issue Nov 6, 2016

Ensures Span.timestamp/duration are not reported on remote spans
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

adriancole added a commit to spring-cloud/spring-cloud-sleuth that referenced this issue Nov 7, 2016

Ensures Span.timestamp/duration are not reported on remote spans
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

adriancole added a commit to spring-cloud/spring-cloud-sleuth that referenced this issue Nov 7, 2016

Ensures Span.timestamp/duration are not reported on remote spans
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

fedj pushed a commit to criteo-forks/zipkin that referenced this issue Dec 28, 2016

Pierre-Hugues Jeanneret
Don't spam logs when RPC spans are in use.
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

Pierre-Hugues Jeanneret
Don't spam logs when RPC spans are in use.
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.

adriancole added a commit to apache/incubator-zipkin that referenced this issue Dec 28, 2016

Don't spam logs when RPC spans are in use. (#1459)
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.

adriancole added a commit to apache/incubator-zipkin that referenced this issue Aug 13, 2017

Lack of timestamp in server-only spans implies shared
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

adriancole added a commit to apache/incubator-zipkin that referenced this issue Aug 13, 2017

Lack of timestamp in server-only spans implies shared (#1690)
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
@adriancole

This comment has been minimized.

Copy link
Contributor Author

adriancole commented Sep 17, 2018

@adriancole adriancole closed this Sep 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.