<div dir="ltr">Best way I see for now is to capture a pointer to req in PRIV_TASK and use is during the release/free operation. You should be okay since that operation comes before the release of the req, but don't keep anything after that step.<div><br></div><div>You'll lose some timing information, as well as the orignal http objects (you'll get the vcl-transformed ones) though. Would that suffice?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br></div>Guillaume Quintard<br></div></div></div>
<br><div class="gmail_quote">On Thu, May 18, 2017 at 3:20 PM, Ryan Burn <span dir="ltr"><<a href="mailto:rnickb731@gmail.com" target="_blank">rnickb731@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't see how that could work. The context for the active span needs<br>
to be injected into the headers of any backend requests. The headers<br>
need to be modified from the varnishd process, right? And you can't<br>
inject a span context unless the span has been created, so I would<br>
think a VMOD would have to start the span as well; then since the<br>
OpenTracing API to specify other properties of the span requires<br>
acting on the object returned when you start the span, those would all<br>
need to called from the VMOD.<br>
<br>
Also, none of the OpenTracing API functions should block for very<br>
long, if at all. The more expensive work such as uploading the tracing<br>
data would happen in a separate thread.<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, May 18, 2017 at 4:45 AM, Dridi Boukelmoune <dridi@varni.sh> wrote:<br>
> On Wed, May 17, 2017 at 11:07 PM, Ryan Burn <<a href="mailto:rnickb731@gmail.com">rnickb731@gmail.com</a>> wrote:<br>
>>> How about a VMOD doing the only StartSpan, std.log for logging keys<br>
>>> and whatnot, and the VUT doing all the rest when it processes the<br>
>>> transaction's logs?<br>
>><br>
>> But the VUT would be running in a separate process, no? If so, how<br>
>> does it access the span object returned when you start the span. The<br>
>> OpenTracing API doesn't support augmenting information to a span<br>
>> later. The functions to set the tags, finish time, etc all have to act<br>
>> on the same object that's returned when you first start the span.<br>
><br>
> You log whatever needs to ultimately be transmitted to the OT server<br>
> and let the VUT pick the logs and do the actual API calls. Performing<br>
> blocking (API) calls from VCL is also a performance killer, that's why<br>
> Varnish logs in memory and can let VUTs find what they need to do the<br>
> dirty work.<br>
><br>
> Take varnishncsa for example. The varnishd process that is technically<br>
> the HTTP server doesn't do access logs and instead it's a separate VUT<br>
> that picks up the relevant information from the shmlog to produce<br>
> them.<br>
><br>
> Dridi<br>
</div></div></blockquote></div><br></div>