Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
There are many component systems here, such as
If we can add the tracing in
In order to make it easy to discuss, I make a google doc for this proposal.
And welcome to comment for this.
Hi @cpuguy83, thanks for comment.
Yes, absolutely. I agree. For client, I think it is always up to users.
I was thinking that the containerd components don't call each other. It seems that the client is good enough. However, it is good to add that into daemon.
I had an intern last fall who did a PoC of something similar. His containerd code changes are here: master...Monkeyanator:opencensus-tracing.
We ended up using OpenCensus instead of OpenTracing just because then we didn't need pick a tracing backend in open-source components, such as containerd. Then you can run the "OC Agent" to handle pushing traces to a tracing backend, and can ship the components independently.
Since containerd uses a stripped-down version of gRPC for it's shims, we explicitly added the trace context to the API, rather than try and add context propagation back in. But if we actually added it, we should do that properly. Other than that, adding tracing to containerd was pretty simple.
If you are curious how I think this should work in kubernetes, feel free to check out my proposal: kubernetes/enhancements#650.
It seems the industry is moving toward
FYI, I created a rough tracing package here: https://github.com/virtual-kubelet/virtual-kubelet/blob/master/trace/trace.go
In VK we use opencensus and logrus... have interfaces for trace and logging... but these are primarily for the purposes of supporting logging through a span and not so much about providing multiple backing implementations of the tracing... but here is how it works:
ctx, span := trace.StartSpan(ctx) log.G(ctx).WithField("foo", "bar").Debug("whatever")
In this case, the