Sure. The intention with OpenTracing is to provide a common API that
can be used to instrument frameworks and libraries. What happens when,
for example, a span is created or its context injected into a request
header isn’t specified by the standard. It’s up to the particular
tracing implementation used (e.g. LightStep, Zipkin, Jaeger, etc) to
decide what specifically to do.
So, if a user wants to enable varnish for OpenTracing, I’d expect them
do something like the following in their VCL:
###
# This is distributed as part of the varnish-opentracing project. It
imports a varnish module
# that exposes VCL functions to interact with the C++ OpenTracing API
# https://github.com/opentracing/opentracing-cpp
# and adds commands to the VCL built-in subroutines so that the
module’s functions will
# be invoked when certain events occur.
include “opentracing.vcl”;
# A user also needs to select a tracing implementation to use. This is
done by importing
# the implementation’s module and initializing the tracer in vcl_init.
For example, if they’re
# using LightStep they might do something like this
import lightstep;
sub vcl_init {
lightstep.collector_host(“…”);
lightstep.collector_port(“…”);
lightstep.init_tracer();
}
# Tracing is then explicitly turned on for a particular request with
logic in the vcl_recv subroutine.
# This means that a span will be created for the request and any
backend requests that result from it.
# The trace’s context will also be propagated into the backend request
headers, so that any tracing done
# by the backend server can be linked to it.
sub vcl_recv {
# This turns on tracing for all requests.
opentracing.trace_request();
}
###
Though all the pieces aren’t together, I have an example set up here
https://github.com/rnburn/varnish-opentracing/blob/master/example/library/varnish/library.vcl
To go back to the questions:
- what data do you inject, and how do you create it?
You would be injecting a list of key-value pairs that represent the
context of the active span
(https://github.com/opentracing/specification/blob/master/specification.md#spancontext).
Specifically what that means is up to the tracing implementation, but
it would look something like this:
'ot-tracer-traceid': 'f84de504f0287bbc' // An ID used to
identify the Trace.
'ot-tracer-spanid': 'e34088878e7f0ce8' // An ID used to identify
the active span within the Trace.
'ot-tracer-sampled': 'true' // Heuristic
used by the Tracer
- what do you need to know about the req/resp/bereq/beresp?
Knowing whether the request resulted in an error is pretty important
to record. Other data usually added
are the URI, http method, ip addresses of the client, server, and
backend servers. Some of the guidelines on what to include are
documented here:
https://github.com/opentracing/specification/blob/master/semantic_conventions.md
An example might make this clearer. This shows the breakdown of a
trace representing the action of a user submitting a profile form:
Loading Image...
The server (described in more detail here
https://github.com/rnburn/nginx-opentracing/blob/master/doc/Tutorial.md)
uses nginx as a reverse proxy in front of Node.js servers that update
a database and perform image manipulation. You can see spans created
on the nginx side to track the duration of the request and how long it
passes through various location blocks as well as spans created from
the Node.js server to represent the database activity and image
manipulation. Injecting context into the request headers is what
allows the spans to be linked together so that the entire trace can be
formed.
On Thu, May 11, 2017 at 9:38 PM, Guillaume Quintard
Post by Guillaume Quintardyou can put anything in the priv field of the task, but the issue is that
you have to put that data in there, meaning a call to your vmod from the
vcl.
the VUT.dispatch_f function isn't to be called from a vmod, and I don't
think you need to.
Maybe it's time to take a step back, can you fill us in the whole workflow,
- what data do you inject, and how do you create it?
- what do you need to know about the req/resp/bereq/beresp?
I almost have the feeling that this could be solved through pure vcl+shell.
--
Guillaume Quintard
Post by Ryan BurnFrom the free function, is there any way to get the status code or
other properties of the request? I tried using VRT_r_obj_status with a
stored reference to the context, but that doesn't seem to work since
https://github.com/rnburn/varnish-opentracing/blob/master/opentracing/src/trace.cpp#L22
Is there any other place something like the status would be stored?
Post by Reza NaghibiSorry, email misfire.
https://varnish-cache.org/docs/trunk/reference/vmod.html#private-pointers
It might make sense to track this stuff in some kind of struct, in which
case, put it into *priv and then register a *free callback. Otherwise, just
put a dummy value into the *priv. *free will get called after the request is
done and you can put your custom code in there.
--
Reza Naghibi
Varnish Software
On Mon, May 8, 2017 at 11:10 AM, Reza Naghibi
Post by Reza Naghibi--
Reza Naghibi
Varnish Software
Post by Ryan BurnHello,
From VCL, is it possible to execute code that runs after a request has
been processed?
I'm looking into writing a module that enables Varnish for distributed
tracing using the OpenTracing project [opentracing.io]. This requires
invoking code at the beginning of a request to start a span and insert
tracing context into the request's headers and invoking code after a
request's been processed to finish the span and measure how long it
took to process.
I recently did a similar project for nginx
[github.com/rnburn/nginx-opentracing]. Nginx provides an
NGX_HTTP_LOG_PHASE [www.nginxguts.com/2011/01/phases/] that allows you
to set up handlers run after requests are serviced. Can anything
equivalent be done using VCL?
I image you could accomplish this by subscribing and regularly reading
from Varnish's shared memory log, but I'd much rather do it directly
if possible.
Thanks, Ryan
_______________________________________________
varnish-misc mailing list
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
_______________________________________________
varnish-misc mailing list
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
