Any way to invoke code from VCL after a request has been serviced?

[Dridi Boukelmoune]

On Thu, May 18, 2017 at 9:20 PM, Ryan Burn <rnickb731 at gmail.com> wrote:
> I don't see how that could work. The context for the active span needs
> to be injected into the headers of any backend requests. The headers
> need to be modified from the varnishd process, right? And you can't
> inject a span context unless the span has been created, so I would
> think a VMOD would have to start the span as well; then since the
> OpenTracing API to specify other properties of the span requires
> acting on the object returned when you start the span, those would all
> need to called from the VMOD.

You can have a VMOD that both populates whatever value you need to
pass through requests and std.log whatever needs to be sent back to
the OpenTracing server. The the VUT can collect that information, plus
Timestamp records and do the sending (it could even send them by
batches if the OT API supports it).

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.

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.

> Also, none of the OpenTracing API functions should block for very
> long, if at all.

The nice thing with blocking calls is that you can add "until they
do". And even if they only take a handful of milliseconds, that's
still orders of magnitude slower than regular VCL code. If I
understand correctly only getting an id should be necessary in
your case.

> The more expensive work such as uploading the tracing
> data would happen in a separate thread.

And your VUT can be that separate thread (well in a separate process
too) so that you don't need to care about synchronizing anything, it's
all done by libvarnishapi. And it can work both in "real time" on a
live varnish instance or on a log dump [1] if the OpenTracing API allows
to defer spans submission after the facts (or for testing purposes).

A VUT can survive a crash of the varnishd child, a thread created by a
VMOD can't.

Cheers,
Dridi

[1] see varnishlog -w and -r