The APIs themselves are pretty similar. The biggest difference is in the scope/goals of the projects.
OT defines an API that various tracers can implement while OC ships a single implementation that tracing vendors can export data from.
OT is focused on traces, OC aims to support move observability signals. Traces and stats are available today. Logs and error tracking are on the roadmap.
There’s a few other differences, but those are the main ones.
"Open tracing" is a bit too opinionated by be universally useful. For example opentracing makes sampling decisions at the end of the span, not the beginning. Because of this you always pay the cost of span annotations even though the vast majority of spans are discarded. I think it's interesting that opentracing descends from the author of Dapper, and opencensus is from Google itself, and yet they've diverged on this and other details. Google of course just uses Dapper.
OpenTracing doesn’t actually specify when a span is sampled. IIRC Lightstep sends all spans to a service that makes sampling decisions based on moving latency percentiles, while Jaeger works as you described, sampling in the client. Its implementation specific.
We also use census for a variety of tasks, mainly for metrics but also for propagating small tags from task to task. The tags [1] can be essentially thought of as request-local scoped state for the entire tree of requests.
The presence of these tags can be used to control behavior if you're clever about it.
nikmd231|7 years ago
OT defines an API that various tracers can implement while OC ships a single implementation that tracing vendors can export data from.
OT is focused on traces, OC aims to support move observability signals. Traces and stats are available today. Logs and error tracking are on the roadmap.
There’s a few other differences, but those are the main ones.
romed|7 years ago
seattleeng|7 years ago
Xorlev|7 years ago
The presence of these tags can be used to control behavior if you're clever about it.
[1] https://opencensus.io/tag/