1VARNISHNCSA(1) VARNISHNCSA(1)
2
3
4
6 varnishncsa - Display Varnish logs in Apache / NCSA combined log format
7
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
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
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
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
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
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
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
291 varnishd(1) varnishlog(1) varnishstat(1) vsl(7)
292
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)