I think that might be what I'm looking for. Is there any function like VRT_r_resp_status, but that operates on the request object instead of the context, to let me extract the status code sent?
On Sun, May 21, 2017 at 11:56 AM, Guillaume Quintard <[email protected]> wrote: > 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. > > You'll lose some timing information, as well as the orignal http objects > (you'll get the vcl-transformed ones) though. Would that suffice? > > -- > Guillaume Quintard > > On Thu, May 18, 2017 at 3:20 PM, Ryan Burn <[email protected]> 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. >> >> 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 <[email protected]> wrote: >> > On Wed, May 17, 2017 at 11:07 PM, Ryan Burn <[email protected]> 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 > > _______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
