mdsol/medidata.zipkintracermodule

[Deprecated] Zipkin Request Tracing for .Net Apps

medidata.zipkintracermodule's Issues

constructor parameters for ZipkinClient?

From the README.md, it looks like just IOwinContext

var client = new ZipkinClient(context);

but Medidata.ZipkinTracer.Core (v3.0.0) from NuGet (as of 26 July 2016), it takes 3 required and 1 optional parameters

public ZipkinClient(ILog logger, IZipkinConfig zipkinConfig, IOwinContext context, SpanCollector collector = null);

and ZipkinClient.cs takes 2 required and 1 optional parameters

public ZipkinClient(IZipkinConfig zipkinConfig, IOwinContext context, SpanCollector collector = null)

Assuming the current source is correct, it looks like both the README and NuGet need to be updated.

Readme update: The tracing can not be done from a console application

The documentation should be updated accordingly so that user knows that the tracing cannot be done from a console/ non-web Applicaiton.

implement "b3 single" header format

Let's support at least reading "b3" header from a single string, most commonly traceid-spanid-1
It would also be nice to support optionally writing this, especially in message providers or others with constrained environments.

Expected behavior

As discussed on openzipkin/b3-propagation#21 and first implemented here: https://github.com/openzipkin/brave/blob/master/brave/src/main/java/brave/propagation/B3SingleFormat.java https://github.com/openzipkin/brave/blob/master/brave/src/test/java/brave/propagation/B3SingleFormatTest.java we should be able to parse "b3" and ideally also write it depending on config.

Actual behavior

right now, we read the historical "X-B3-" headers, which we should still support. However, if we see a header named "b3" we should read that instead.

Steps to reproduce the behavior

Turn on tracing and see if b3=80f198ee56343ba864fe8b2a57d3eff7-05e3ac9a4f6e3b90-1-e457b5a2e4d86bd1 results in the same context as:

X-B3-TraceId: 80f198ee56343ba864fe8b2a57d3eff7
X-B3-ParentSpanId: 05e3ac9a4f6e3b90
X-B3-SpanId: e457b5a2e4d86bd1
X-B3-Sampled: 1

No Build/Package scripts

Hi guys,

Thanks for a useful project. I normally create scripts for build and package (see my github projects) and I am happy to do the same for you if happy.

I did not just create a PR, I do not like receiving just a PR without creating issue for my projects :)

Separate nuget packages for Core logic and Middleware/s

This library needs to separate nuget packages for Core logic and Middleware/s to easily adapt to platforms and framework.

• create a core nuget package
• create a nuget package for owin middleware framework
• create a nuget package for asp net 4 framework (ex. http module)
• core nuget package should be compatible with dot net core (include dot net core middleware capability)

Does this work with .NET Core?

The example program should be updated

The current example uses methods of Zipkinclient, TraceProvider classes like StartServerTrace.
As discussed with Brent - "We can only use tracing for inbound calls using the OWIN middlewares and outbound calls using http client message handlers. Please don't use ZipkinClient methods directly."

IPv6 support

We currently support logging of only IPv4 addresses. Starting with Zipkin 1.4 endpoints can omit IPv4 (by setting Endpoint.ipv4 to 0), and optionally log Endpoint.ipv6 as the raw 16byte address.
https://github.com/openzipkin/zipkin-api/blob/master/thrift/zipkinCore.thrift#L276

In json, both are the string formatting http://zipkin.io/zipkin-api

ipv4:
string
The text representation of a IPv4 address associated with this endpoint. Ex. 192.168.99.100
ipv6:
string
The text representation of a IPv6 address associated with this endpoint. Ex. 2001:db8::c001

gRPC support

Can I use the library to trace the gRPC microservices interaction ?

support for .net core

This can't support a .net core project.
How can fix it ?

Update to record timestamp and duration authoratively

Recent versions of zipkin have a duration query that only works when timestamp and duration are set authoritatively. This implies adding the fields to the Span type when reporting to zipkin. These should be set when originating a new span (ex. all root and client spans, but not set on spans continued via B3 headers).

This was noticed by @prbarl who found duration query not working in cassandra for this reason

See openzipkin/openzipkin.github.io#49 for more details.

Don't break on 128bit X-B3-TraceId by tossing high bits

Problem

The first step of transitioning to 128bit X-B3-TraceId is tolerantly reading 32 character long ids. Until a change is made, those propagating 128bit ids to Medidata.ZipkinTracerModule will have their traces restarted due to a parse failure.

Medidata.ZipkinTracerModule is one of the last libraries that need an update.

Proposal

Change the TraceProvider.parse to leniently parse an unsigned 64bit long from a lower-hex string. This could address 128bit (32 character) ids by throwing away the high bits (any characters left of 16 characters)

Test

When a 128bit id like X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124 is received, the lower 64 bits (right most 16 characters ex48485a3953bb6124) will become the trace id as opposed to having the trace restarted.

See also

twitter/finagle#553
openzipkin/brave#239