Adrian Cole

PS I know many folks aren't watching this repository, so I'll do a one-time spam for B3-compliant tracer authors. The aim is to capture B3 here and also ideally an...

related issue: https://github.com/openzipkin/b3-propagation/issues/4

Prologue: A reverse-documentation effort smokes out concerns in the original implementation. So, let me first mention that by documenting what's been the case for years doesn't mean I agree with...

@yurishkuro I think you have done some work in analyzing tracers.. do you have means to tag bad or out-of-date instrumentation? ex in finagle, the version is logged, so if...

@nicmunroe @jcarres-mdsol @shalako Ok, well we can't rewrite history, but we can affect this moving forward. How about this? --- `X-B3-TraceId` should be present with `X-B3-SpanId` to ensure that a...

This sounds similar to grpc. In grpc, they propagate the parent (client) id only. Then, when it is received, the server uses that parent, generates a new span id for...

> X-B3-SpanId is derived as the right-most 16 characters (64bits) of the > X-B3-TraceId > > that doesn't sound like a good practice. If the client app that only sends...

ps I thought about this recently, and one thing about this thread is that it seems there's multiple valid policies, of which context decides what's best. One way out is...

B3 ids are fixed-length lowerhex encoded values Ex. "48485a3953bb6124". These are easy to copy/paste vs numeric values or UUIDs which have hyphens in them. They are expected to be fully...

So the node that starts the trace makes the decision whether to use 128 bits or not. The thing I mentioned works when high bits of all zeros are not...