1VARNISHNCSA(1)                                                  VARNISHNCSA(1)
2
3
4

NAME

6       varnishncsa - Display Varnish logs in Apache / NCSA combined log format
7

SYNOPSIS

9       varnishncsa  [-a] [-b] [-c] [-C] [-d] [-D] [-E] [-F <format>] [-f <for‐
10       matfile>] [-g <request|vxid>] [-h] [-L <limit>] [-n <dir>] [-P  <file>]
11       [-Q  <file>]  [-q  <query>] [-r <filename>] [-R <limit[/duration]>] [-t
12       <seconds|off>] [-V] [-w <filename>]
13

DESCRIPTION

15       The varnishncsa  utility  reads  varnishd(1)  shared  memory  logs  and
16       presents them in the Apache / NCSA "combined" log format.
17
18       Each  log  line  produced is based on a single Request type transaction
19       gathered from the shared memory log. The Request  transaction  is  then
20       scanned for the relevant parts in order to output one log line. To fil‐
21       ter the log lines produced, use the query language to select the appli‐
22       cable transactions. Non-request transactions are ignored.
23
24       The following options are available:
25
26       -a     When  writing  output  to a file, append to it rather than over‐
27              write it.
28
29       -b     Log backend requests. If -c is not specified, then only  backend
30              requests will trigger log lines.
31
32       -c     Log  client  requests.  This is the default. If -b is specified,
33              then -c is needed to also log client requests
34
35       -C     Do all regular expression and string matching caseless.
36
37       -d     Process log records at the head of the log and exit.
38
39       -D     Daemonize.
40
41       -E     Show ESI requests, implies client mode.
42
43       -F <format>
44              Set the output log format string.
45
46       -f <formatfile>
47              Read output format from a file. Will read a single line from the
48              specified file, and use that line as the format.
49
50       -g <request|vxid>
51              The  grouping  of  the  log  records. The default is to group by
52              vxid.
53
54       -h     Print program usage and exit
55
56       -L <limit>
57              Sets the upper limit of incomplete transactions kept before  the
58              oldest  transaction is force completed. A warning record is syn‐
59              thesized when this happens. This setting keeps an upper bound on
60              the  memory  usage of running queries. Defaults to 1000 transac‐
61              tions.
62
63       -n <dir>
64              Specify the varnishd working directory (also known  as  instance
65              name) to get logs from. If -n is not specified, the host name is
66              used.
67
68       -P <file>
69              Write the process' PID to the specified file.
70
71       -Q <file>
72              Specifies the file containing the VSL query to use. When  multi‐
73              ple  -Q  or -q options are specified, all queries are considered
74              as if the 'or' operator was used to combine them.
75
76       -q <query>
77              Specifies the VSL query to use. When multiple -q or  -Q  options
78              are  specified, all queries are considered as if the 'or' opera‐
79              tor was used to combine them.
80
81       -r <filename>
82              Read log in binary file format from this file. The file  can  be
83              created with varnishlog -w filename.
84
85       -R <limit[/duration]>
86              Restrict the output to the specified limit. Transactions exceed‐
87              ing the limit will be suppressed. The limit is specified as  the
88              maximum  number  of  transactions  (with  respect  to the chosen
89              grouping method) and an optional time period. If no duration  is
90              specified,  a  default  of  s is used. The duration field can be
91              formatted as in VCL (e.g. -R 10/2m) or as a simple  time  period
92              without  the prefix (e.g. -R 5/m). When in -g raw grouping mode,
93              this setting can not be used alongside -i, -I, -x or -X, and  we
94              advise using -q instead.
95
96       -t <seconds|off>
97              Timeout before returning error on initial VSM connection. If set
98              the VSM connection is retried every 0.5 seconds  for  this  many
99              seconds.  If zero the connection is attempted only once and will
100              fail immediately if unsuccessful. If set to "off",  the  connec‐
101              tion will not fail, allowing the utility to start and wait inde‐
102              finetely for the Varnish instance to appear.  Defaults to 5 sec‐
103              onds.
104
105       -V     Print version information and exit.
106
107       -w <filename>
108              Redirect output to file. The file will be overwritten unless the
109              -a option was specified. If the application receives a SIGHUP in
110              daemon mode the file will be reopened allowing the old one to be
111              rotated away. This option is required  when  running  in  daemon
112              mode.
113
114       --optstring
115              Print the optstring parameter to getopt(3) to help writing wrap‐
116              per scripts.
117

MODES

119       The default mode of varnishncsa is "client mode".  In  this  mode,  the
120       log  will  be similar to what a web server would produce in the absence
121       of varnish.  Client mode can be explicitly selected by using -c.
122
123       If the -b switch is specified, varnishncsa  will  operate  in  "backend
124       mode".   In  this  mode,  requests generated by varnish to the backends
125       will be logged.  Unless -c is also specified, client requests  received
126       by varnish will be ignored.
127
128       When  running  varnishncsa  in  both  backend  and  client  mode, it is
129       strongly advised to include the format  specifier  %{Varnish:side}x  to
130       distinguish between backend and client requests.
131
132       Client  requests that results in a pipe (ie. return(pipe) in vcl), will
133       not generate logging in backend mode. This is because  varnish  is  not
134       generating  requests,  but  blindly passes on bytes in both directions.
135       However, a varnishncsa instance running in normal  mode  can  see  this
136       case by using the formatter %{Varnish:handling}x, which will be 'pipe'.
137
138       In  backend mode, some of the fields in the format string get different
139       meanings.  Most notably, the byte counting formatters (%b, %I, %O) con‐
140       siders varnish to be the client.
141
142       It  is possible to keep two varnishncsa instances running, one in back‐
143       end mode, and one in client mode, logging to different files.
144

FORMAT

146       Specify the log format to use. If no format is  specified  the  default
147       log format is used:
148
149          %h %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i"
150
151       Escape sequences \n and \t are supported.
152
153       Supported formatters are:
154
155       %b     In  client mode, size of response in bytes, excluding HTTP head‐
156              ers.  In backend mode, the number of  bytes  received  from  the
157              backend,  excluding  HTTP  headers.   In  CLF format, i.e. a '-'
158              rather than a 0 when no bytes are sent.
159
160       %D     In client mode, time taken to serve the  request,  in  microsec‐
161              onds.   In  backend  mode, time from the request was sent to the
162              entire body had been received. This is equivalent to %{us}T.
163
164       %H     The request protocol. Defaults to HTTP/1.0 if not known.
165
166       %h     Remote host. Defaults to '-' if not known.  In backend mode this
167              is the IP of the backend server.
168
169       %I     In  client  mode,  total bytes received from client.  In backend
170              mode, total bytes sent to the backend.
171
172       %{X}i  The contents of request header X. If the header appears multiple
173              times in a single transaction, the last occurrence is used.
174
175       %l     Remote logname. Always '-'.
176
177       %m     Request method. Defaults to '-' if not known.
178
179       %{X}o  The  contents of response header X. If the header appears multi‐
180              ple times in a single transaction, the last occurrence is used.
181
182       %O     In client mode, total bytes sent to client.   In  backend  mode,
183              total bytes received from the backend.
184
185       %q     The query string. Defaults to an empty string if not present.
186
187       %r     The first line of the request. Synthesized from other fields, so
188              it may not be the request verbatim. See the NOTES section.
189
190       %s     Status sent to the client.  In  backend  mode,  status  received
191              from the backend.
192
193       %t     In  client  mode,  time  when  the request was received, in HTTP
194              date/time format.  In backend mode, time when  the  request  was
195              sent.
196
197       %{X}t  In  client mode, time when the request was received, in the for‐
198              mat specified by X.  In backend mode, time when the request  was
199              sent.   The  time  specification format is the same as for strf‐
200              time(3).
201
202       %T     In client mode, time taken to serve the request, in seconds.  In
203              backend  mode, time from the request was sent to the entire body
204              had been received. This is equivalent to %{s}T.
205
206       %{X}T  In client mode, time taken to serve the request, in  the  format
207              specified by X.  In backend mode, time from the request was sent
208              to the entire body had been  received.  The  time  specification
209              format  can  be  one  of the following: s (same as %T), ms or us
210              (same as %D).
211
212       %U     The request URL without the query string. Defaults to '-' if not
213              known.
214
215       %u     Remote user from auth.
216
217       %{X}x  Extended variables.  Supported variables are:
218
219              Varnish:time_firstbyte
220                     Time  from  when  the request processing starts until the
221                     first byte is sent to the client, in seconds.  For  back‐
222                     end  mode:  Time from the request was sent to the backend
223                     to the entire header had been received.
224
225              Varnish:hitmiss
226                     One of the 'hit' or 'miss' strings, depending on  whether
227                     the request was a cache hit or miss. Pipe, pass and synth
228                     are considered misses.
229
230              Varnish:handling
231                     One of the  'hit',  'miss',  'pass',  'pipe'  or  'synth'
232                     strings indicating how the request was handled.
233
234              Varnish:side
235                     Backend  or  client  side. One of two values, 'b' or 'c',
236                     depending on where the request was made. In pure  backend
237                     or client mode, this field will be constant.
238
239              Varnish:vxid
240                     The VXID of the varnish transaction.
241
242              VCL_Log:key
243                     The value set by std.log("key:value") in VCL.
244
245              VSL:tag:record-prefix[field]
246                     The  value of the VSL entry for the given tag-record pre‐
247                     fix-field combination. Tag is mandatory, the other compo‐
248                     nents are optional.
249
250                     The record prefix will limit the matches to those records
251                     that have this prefix as the first  part  of  the  record
252                     content followed by a colon.
253
254                     The  field  will,  if  present, treat the log record as a
255                     white space separated list of fields, and  only  the  nth
256                     part  of the record will be matched against. Fields start
257                     counting at 1 and run up to 255.
258
259                     Defaults to '-' when the tag is not seen, the record pre‐
260                     fix  does  not  match or the field is out of bounds. If a
261                     tag appears multiple times in a single  transaction,  the
262                     first occurrence is used.
263

SIGNALS

265       • SIGHUP
266
267         Rotate  the  log  file (see -w option) in daemon mode, abort the loop
268         and die gracefully when running in the foreground.
269
270       • SIGUSR1
271
272         Flush any outstanding transactions.
273

NOTES

275       The %r formatter is equivalent to  "%m  http://%{Host}i%U%q  %H".  This
276       differs  from  apache's  %r behavior, equivalent to "%m %U%q %H".  Fur‐
277       thermore, when using the %r formatter, if the Host header appears  mul‐
278       tiple times in a single transaction, the first occurrence is used.
279

EXAMPLE

281       Log  the second field of the Begin record, corresponding to the VXID of
282       the parent transaction:
283
284          varnishncsa -F "%{VSL:Begin[2]}x"
285
286       Log the entire Timestamp record associated with the processing length:
287
288          varnishncsa -F "%{VSL:Timestamp:Process}x"
289

SEE ALSO

291       varnishd(1) varnishlog(1) varnishstat(1) vsl(7)
292

HISTORY

294       The varnishncsa utility was developed by Poul-Henning Kamp in  coopera‐
295       tion with Verdens Gang AS and Varnish Software AS. This manual page was
296       initially written by Dag-Erling Smørgrav <des@des.no>,  and  later  up‐
297       dated by Martin Blix Grydeland and Pål Hermunn Johansen.
298
300       This document is licensed under the same licence as Varnish itself. See
301       LICENCE for details.
302
303       • Copyright (c) 2006 Verdens Gang AS
304
305       • Copyright (c) 2006-2016 Varnish Software AS
306
307
308
309
310                                                                VARNISHNCSA(1)
Impressum