xenial (7) vsl-query.7.gz

Provided by: varnish_4.1.1-1ubuntu0.2_amd64 bug

NAME

       vsl-query - Varnish VSL Query Expressions

OVERVIEW

       The  Varnish  VSL Query Expressions extracts transactions from the Varnish shared memory log, and perform
       queries on the transactions before reporting matches.

       A transaction is a set of log lines that belongs together, e.g. a client request or  a  backend  request.
       The  API  monitors  the  log, and collects all log records that make up a transaction before reporting on
       that transaction. Transactions can also be grouped, meaning backend transactions  are  reported  together
       with the client transaction that initiated it.

       A query is run on a group of transactions. A query expression is true if there is a log record within the
       group that satisfies the condition. It is false only if none of the log records satisfies the  condition.
       Query expressions can be combined using boolean functions.

GROUPING

       When  grouping transactions, there is a hierarchy structure showing which transaction initiated what. The
       level increases by one on an 'initiated by' relation, so for example a backend transaction will have  one
       higher  level than the client transaction that initiated it on a cache miss. Request restart transactions
       don't get their level increased to make it predictable.

       Levels start counting at 1, except when using raw where it will always be 0.

       The grouping modes are:

       • Session

         All transactions initiated by a client connection are reported together. Client  connections  are  open
         ended  when  using  HTTP  keep-alives,  so  it  is  undefined when the session will be reported. If the
         transaction timeout period is exceeded an incomplete session will be reported.  Non-transactional  data
         (VXID == 0) is not reported.

       • Request

         Transactions  are  grouped  by  request,  where  the set will include the request itself as well as any
         backend requests or ESI-subrequests.  Session data and  non-transactional  data  (VXID  ==  0)  is  not
         reported.

       • VXID

         Transactions  are  not  grouped,  so  each  VXID  is  reported  in  it's  entirety. Sessions, requests,
         ESI-requests and backend requests are all reported individually. Non-transactional data is not reported
         (VXID == 0). This is the default.

       • Raw

         Every  log  record  will  make up a transaction of it's own. All data, including non-transactional data
         will be reported.

   Transaction Hierarchy
       Example transaction hierarchy using request grouping mode

       Lvl 1: Client request (cache miss)
         Lvl 2: Backend request
         Lvl 2: ESI subrequest (cache miss)
           Lvl 3: Backend request
           Lvl 3: Backend request (VCL restart)
           Lvl 3: ESI subrequest (cache miss)
             Lvl 4: Backend request
         Lvl 2: ESI subrequest (cache hit)

MEMORY USAGE

       The API will use pointers to shared memory log data as long  as  possible  to  keep  memory  usage  at  a
       minimum.  But as the shared memory log is a ring buffer, data will get overwritten eventually, so the API
       creates local copies of referenced log data when varnishd comes close  to  overwriting  still  unreported
       content.

       This  process  avoids loss of log data in many scenarios, but it is not failsafe: Overruns where varnishd
       "overtakes" the log reader process in the ring buffer can still happen when API clients  cannot  keep  up
       reading and/or copying, for instance due to output blocking.

       Though being unrelated to grouping in principle, copying of log data is particularly relevant for session
       grouping together with long lasting client connections -  for  this  grouping,  the  logging  API  client
       process is likely to consume relevant amounts of memory. As the vxid grouping also logs (potentially long
       lasting) sessions, it is also likely to require memory for copies of  log  entries,  but  far  less  than
       session grouping.

QUERY LANGUAGE

       A query expression consists of record selection criteria, and optionally an operator and a value to match
       against the selected records.

       <record selection criteria> <operator> <operand>

   Record selection criteria
       The record selection criteria determines what kind records from  the  transaction  group  the  expression
       applies to. Syntax:

       {level}taglist:record-prefix[field]

       Taglist is mandatory, the other components are optional.

       The  level  limits  the expression to a transaction at that level. If left unspecified, the expression is
       applied to transactions at all levels. Level is a positive integer or zero. If level is followed by a '+'
       character,  it  expresses greater than or equal. If level is followed by a '-', it expresses less than or
       equal.

       The taglist is a comma-separated list of VSL record tags that this expression should be checked  against.
       Each  list element can be a tag name or a tag glob. Globs allow a '*' either in the beginning of the name
       or at the end, and will select all tags that match either the prefix or  subscript.  A  single  '*'  will
       select all tags.

       The record prefix will further limit the matches to those records that has this prefix as it's first part
       of the record content followed by a colon. The part of the  log  record  matched  against  will  then  be
       limited to what follows the prefix and colon. This is useful when matching against specific HTTP headers.
       The record prefix matching is done case insensitive.

       The field will, if present, treat the log record as a white space separated list of fields, and only  the
       nth part of the record will be matched against. Fields start counting at 1.

       An  expression  using  only  a  record  selection  criteria  will  be  true if there is any record in the
       transaction group that is selected by the criteria.

   Operators
       The following matching operators are available:

       • == != < <= > >=

         Numerical comparison. The record contents will be converted to either an  integer  or  a  float  before
         comparison, depending on the type of the operand.

       • eq ne

         String comparison. 'eq' tests string equality, 'ne' tests for not equality.

       • ~ !~

         Regular expression matching. '~' is a positive match, '!~' is a non-match.

   Operand
       The operand is the value the selected records will be matched against.

       An  operand  can  be  quoted  or  unquoted.  Quotes can be either single or double quotes, and for quoted
       operands a backslash can be used to escape the quotes.

       Unquoted operands can only consist of the following characters:

       a-z A-Z 0-9 + - _ . *

       The following types of operands are available:

       • Integer

         A number without any fractional part, valid for the numerical comparison operators. The integer type is
         used when the operand does not contain any period (.) characters.

       • Float

         A  number  with a fractional part, valid for the numerical comparison operators. The float type is used
         when the operand does contain a period (.) character.

       • String

         A sequence of characters, valid for the string equality operators.

       • Regular expression

         A PCRE regular expression. Valid for the regular expression operators.

   Boolean functions
       Query expressions can be linked together  using  boolean  functions.  The  following  are  available,  in
       decreasing precedence:

       • not <expr>

         Inverts the result of <expr>

       • <expr1> and <expr2>

         True only if both expr1 and expr2 are true

       • <expr1> or <expr2>

         True if either of expr1 or expr2 is true

       Expressions can be grouped using parenthesis.

QUERY EXPRESSION EXAMPLES

       • Transaction group contains a request URL that equals to "/foo"

         ReqURL eq "/foo"

       • Transaction group contains a request cookie header

         ReqHeader:cookie

       • Transaction group doesn't contain a request cookie header

         not ReqHeader:cookie

       • Client request where internal handling took more than 800ms.:

         Timestamp:Process[2] > 0.8

       • Transaction  group  contains  a request user-agent header that contains "iPod" and the request delivery
         time exceeds 1 second

         ReqHeader:user-agent ~ "iPod" and Timestamp:Resp[2] > 1.

       • Transaction group contains a backend response status larger than or equal to 500

         BerespStatus >= 500

       • Transaction group contains a request response status of 304, but where the request did not  contain  an
         if-modified-since header

         ReqStatus == 304 and not ReqHeader:if-modified-since

       • Transactions  that  have  had backend failures or long delivery time on their ESI subrequests. (Assumes
         request grouping mode).

         BerespStatus >= 500 or {2+}Timestamp:Process[2] > 1.

HISTORY

       This document was written by Martin Blix Grydeland.

       This document is licensed under the same licence as Varnish itself. See LICENCE for details.

       • Copyright (c) 2006 Verdens Gang AS

       • Copyright (c) 2006-2015 Varnish Software AS

                                                                                                    VSL-QUERY(7)