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

[Ryan Burn]

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.

Also, none of the OpenTracing API functions should block for very
long, if at all. The more expensive work such as uploading the tracing
data would happen in a separate thread.

On Thu, May 18, 2017 at 4:45 AM, Dridi Boukelmoune <dridi at varni.sh> wrote:
> On Wed, May 17, 2017 at 11:07 PM, Ryan Burn <rnickb731 at gmail.com> wrote:
>>> How about a VMOD doing the only StartSpan, std.log for logging keys
>>> and whatnot, and the VUT doing all the rest when it processes the
>>> transaction's logs?
>>
>> But the VUT would be running in a separate process, no? If so, how
>> does it access the span object returned when you start the span. The
>> OpenTracing API doesn't support augmenting information to a span
>> later. The functions to set the tags, finish time, etc all have to act
>> on the same object that's returned when you first start the span.
>
> You log whatever needs to ultimately be transmitted to the OT server
> and let the VUT pick the logs and do the actual API calls. Performing
> blocking (API) calls from VCL is also a performance killer, that's why
> Varnish logs in memory and can let VUTs find what they need to do the
> dirty work.
>
> Take varnishncsa for example. The varnishd process that is technically
> the HTTP server doesn't do access logs and instead it's a separate VUT
> that picks up the relevant information from the shmlog to produce
> them.
>
> Dridi