Sorry to dig that one up, but I stumble upon it again, and it got me thinking: can't we just put the point to req->err_code in priv? That's not super clean, but from what I re-read in the code, it should still be there when it's time to clean the priv.
-- Guillaume Quintard On Tue, May 23, 2017 at 11:15 PM, Ryan Burn <[email protected]> wrote: > > When it comes to header manipulations (including method, status etc) > > they are already logged so a VUT can already pick that up and save > > some work from the VMOD. > > It doesn't need to just view the headers; it needs to add headers to > encode the > active span context. See > http://opentracing.io/documentation/pages/api/cross-process-tracing.html > And the active span needs to be started before those headers can be added. > > > I'm not familiar with OT but what I described is how Zipnish does its > > tracing. Except that Zipnish relies on the X-Varnish header to get a > > unique-ish id, so no blocking call needs to be made. So maybe they are > > highly different systems, I chimed in because I saw a Zipkin example > > while briefly skimming through the docs. > > Zipkin is a distributed tracing system that provides OpenTracing > implementations, but Zipnish is just using it as a monitor for > varnish. It's not doing context propagation. If you're only interested > in monitoring varnish, that's fine; but if you want to see how a > request is processed in an entire distributed system (i.e. not just > varnish, but the backend servers it's sitting in front of or any other > service that might be in front of varnish), then you need to do > context propagation. >
_______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
