Manual section: | 7 |
---|
This document describes the format and content of all the Varnish shared memory logging tags. These tags are used by the varnishlog(1), varnishtop(1), etc. logging tools supplied with Varnish.
Logged when a connection is selected for handling a backend request.
The format is:
%d %s %s
| | |
| | +- Backend display name
| +---- VCL name
+------- Connection file descriptor
Logged when a backend connection is closed.
The format is:
%d %s [ %s ]
| | |
| | +- Optional reason
| +------ Backend display name
+--------- Connection file descriptor
Logged when a new backend connection is opened.
The format is:
%d %s %s %s %s %s
| | | | | |
| | | | | +- Local port
| | | | +---- Local address
| | | +------- Remote port
| | +---------- Remote address
| +------------- Backend display name
+---------------- Connection file descriptor
Logged when a backend connection is put up for reuse by a later connection.
The format is:
%d %s
| |
| +- Backend display name
+---- Connection file descriptor
Start of backend processing. Logs the backend IP address and port number.
The format is:
%s %s
| |
| +- Backend Port number
+---- Backend IP4/6 address
The result of a backend health probe.
The format is:
%s %s %s %u %u %u %f %f %s
| | | | | | | | |
| | | | | | | | +- Probe HTTP response
| | | | | | | +---- Average response time
| | | | | | +------- Response time
| | | | | +---------- Probe window size
| | | | +------------- Probe threshold level
| | | +---------------- Number of good probes in window
| | +------------------- Probe window bits
| +---------------------- Status message
+------------------------- Backend name
The first record of a VXID transaction.
The format is:
%s %d %s
| | |
| | +- Reason
| +---- Parent vxid
+------- Type ("sess", "req" or "bereq")
Contains byte counters from backend request processing.
The format is:
%d %d %d %d %d %d
| | | | | |
| | | | | +- Total bytes received
| | | | +---- Body bytes received
| | | +------- Header bytes received
| | +---------- Total bytes transmitted
| +------------- Body bytes transmitted
+---------------- Header bytes transmitted
HTTP header contents.
The format is:
%s: %s
| |
| +- Header value
+----- Header name
HTTP header contents.
The format is:
%s: %s
| |
| +- Header value
+----- Header name
Logs events related to object expiry. The events are:
The format is:
EXP_Rearm p=%p E=%f e=%f f=0x%x
EXP_Inbox p=%p e=%f f=0x%x
EXP_Kill p=%p e=%f f=0x%x
EXP_When p=%p e=%f f=0x%x
EXP_Expired x=%u t=%f
LRU_Cand p=%p f=0x%x r=%d
LRU x=%u
LRU_Fail
Legend:
p=%p Objcore pointer
t=%f Remaining TTL (s)
e=%f Expiry time (unix epoch)
E=%f Old expiry time (unix epoch)
f=0x%x Objcore flags
r=%d Objcore refcount
x=%u Object VXID
Ready to fetch body from backend.
The format is:
%d (%s) %s
| | |
| | +---- 'stream' or '-'
| +--------- Text description of body fetch mode
+------------- Body fetch mode
A Gzip record is emitted for each instance of gzip or gunzip work performed. Worst case, an ESI transaction stored in gzip'ed objects but delivered gunziped, will run into many of these.
The format is:
%c %c %c %d %d %d %d %d
| | | | | | | |
| | | | | | | +- Bit length of compressed data
| | | | | | +---- Bit location of 'last' bit
| | | | | +------- Bit location of first deflate block
| | | | +---------- Bytes output
| | | +------------- Bytes input
| | +---------------- 'E': ESI, '-': Plain object
| +------------------- 'F': Fetch, 'D': Deliver
+---------------------- 'G': Gzip, 'U': Gunzip, 'u': Gunzip-test
Examples:
U F E 182 159 80 80 1392
G F E 159 173 80 1304 1314
This value was added to the object lookup hash.
NB: This log record is masked by default.
Links this VXID to any child VXID it initiates.
The format is:
%s %d %s
| | |
| | +- Reason
| +---- Child vxid
+------- Child type ("req" or "bereq")
HTTP header contents.
The format is:
%s: %s
| |
| +- Header value
+----- Header name
Contains byte counters for pipe sessions.
The format is:
%d %d %d %d
| | | |
| | | +------- Piped bytes to client
| | +---------- Piped bytes from client
| +------------- Backend request headers
+---------------- Client request headers
PROXY protocol information.
The format is:
%d %s %d %s %d
| | | | |
| | | | +- server port
| | | +---- server ip
| | +------- client port
| +---------- client ip
+------------- PROXY protocol version
Contains byte counts for the request handling. ESI sub-request counts are also added to their parent request. The body bytes count does not include transmission (ie: chunked encoding) overhead. The format is:
%d %d %d %d %d %d
| | | | | |
| | | | | +- Total bytes transmitted
| | | | +---- Body bytes transmitted
| | | +------- Header bytes transmitted
| | +---------- Total bytes received
| +------------- Body bytes received
+---------------- Header bytes received
HTTP header contents.
The format is:
%s: %s
| |
| +- Header value
+----- Header name
Start of request processing. Logs the client IP address and port number.
The format is:
%s %s
| |
| +- Client Port number
+---- Client IP4/6 address
HTTP header contents.
The format is:
%s: %s
| |
| +- Header value
+----- Header name
SessClose is the last record for any client connection.
The format is:
%s %f
| |
| +- How long the session was open
+---- Why the connection closed
The first record for a client connection, with the socket-endpoints of the connection.
The format is:
%s %d %s %s %s %d
| | | | | |
| | | | | +- File descriptor number
| | | | +---- Local TCP port ('-' if !$log_local_addr)
| | | +------- Local IPv4/6 address ('-' if !$log_local_addr)
| | +---------- Listen socket (-a argument)
| +------------- Remote TCP port
+---------------- Remote IPv4/6 address
Type and name of the storage backend the object is stored in.
The format is:
%s %s
| |
| +- Name of storage backend
+---- Type ("malloc", "file", "persistent" etc.)
A TTL record is emitted whenever the ttl, grace or keep values for an object is set.
The format is:
%s %d %d %d %d [ %d %d %u %u ]
| | | | | | | | |
| | | | | | | | +- Max-Age from Cache-Control header
| | | | | | | +---- Expires header
| | | | | | +------- Date header
| | | | | +---------- Age (incl Age: header value)
| | | | +--------------- Reference time for TTL
| | | +------------------ Keep
| | +--------------------- Grace
| +------------------------ TTL
+--------------------------- "RFC" or "VCL"
The last four fields are only present in "RFC" headers.
Examples:
RFC 60 10 -1 1312966109 1312966109 1312966109 0 60
VCL 120 10 0 1312966111
Contains timing information for the Varnish worker threads.
Time stamps are issued by Varnish on certain events, and show the absolute time of the event, the time spent since the start of the work unit, and the time spent since the last timestamp was logged. See vsl(7) for information about the individual timestamps.
The format is:
%s: %f %f %f
| | | |
| | | +- Time since last timestamp
| | +---- Time since start of work unit
| +------- Absolute time of event
+----------- Event label
Logs VCL execution trace data.
The format is:
%u %u.%u
| | |
| | +- VCL program line position
| +---- VCL program line number
+------- VCL trace point index
NB: This log record is masked by default.
Contains name of VFP and statistics.
The format is:
%s %d %d
| | |
| | +- Total bytes produced
| +---- Number of calls made
+------- Name of filter
NB: This log record is masked by default.
Logs worker thread creation and termination events.
The format is:
%p %s
| |
| +- [start|end]
+---- Worker struct pointer
NB: This log record is masked by default.
Timestamps are inserted in the log on completing certain events during the worker thread's task handling. The timestamps has a label showing which event was completed. The reported fields show the absolute time of the event, the time spent since the start of the task and the time spent since the last timestamp was logged.
The timestamps logged automatically by Varnish are inserted after completing events that are expected to have delays (e.g. network IO or spending time on a waitinglist). Timestamps can also be inserted from VCL using the std.timestamp() method. If one is doing time consuming tasks in the VCL configuration, it's a good idea to log a timestamp after completing that task. This keeps the timing information in subsequent timestamps from including the time spent on the VCL event.
This document was initially written by Poul-Henning Kamp, and later updated by Martin Blix Grydeland.
This document is licensed under the same licence as Varnish itself. See LICENCE for details.
Enter search terms or a module, class or function name.