VSL(7)

📦
version 8.0.2 · 13 versions
, in fedora 44

🎀 NAME 🎀

VSL(7) — Varnish Shared Memory Logging 🦋💖

✨ OVERVIEW ✨

okay bestie, sit down, hydrate, because this page is THE doc for the format and content of every single Varnish shared memory logging tag. these tags are literally what the logging tools that ship with Varnish — you know, varnishlog(1), varnishtop(1), etc. — read from. no cap. 🫶

🌸 VSL tags 🌸

💅 BackendClose — Backend connection closed

logged the literal second a backend connection gets closed. it's giving "we're done here" 💀

The format is:

%d %s %s [ %s ]
|  |  |    |
|  |  |    +- Optional reason, see SessClose for explanation
|  |  +------ "close" or "recycle"
|  +--------- Backend display name
+------------ Connection file descriptor

✨ BackendOpen — Backend connection opened

logged when a fresh new backend connection opens up. new connection, who dis 🌈

The format is:

%d %s %s %s %s %s %s
|  |  |  |  |  |  |
|  |  |  |  |  |  +- "connect" or "reuse"
|  |  |  |  |  +---- Local port
|  |  |  |  +------- Local address
|  |  |  +---------- Remote port
|  |  +------------- Remote address
|  +---------------- Backend display name
+------------------- Connection file descriptor

🩺 Backend_health — Backend health check

the result of a backend health probe. basically a vibe check but for your backend, and if it fails it gets marked sick 😭

The format is:

%s %s %s %s %u %u %u %f %f %s
|  |  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |  +- Probe HTTP response / error information
|  |  |  |  |  |  |  |  +---- Average response time
|  |  |  |  |  |  |  +------- Response time
|  |  |  |  |  |  +---------- Probe window size
|  |  |  |  |  +------------- Probe threshold level
|  |  |  |  +---------------- Number of good probes in window
|  |  |  +------------------- Probe window bits
|  |  +---------------------- "healthy" or "sick"
|  +------------------------- "Back", "Still" or "Went"
+---------------------------- Backend name

Probe window bits are:

'-': Could not connect
'4': Good IPv4
'6': Good IPv6
'U': Good UNIX
'x': Error Xmit
'X': Good Xmit
'r': Error Recv
'R': Good Recv
'H': Happy

okay and here's the tea 🍵 — when the backend is just created, the window bits for health check slots that haven't run yet appear as '-' like failures to connect. so don't panic, they just haven't had their moment yet.

🎬 Begin — Marks the start of a VXID

the very first record of a VXID transaction. the opening scene, the main character entrance 👑

The format is:

%s %d %s [%u]
|  |  |   |
|  |  |   +- Task sub-level
|  |  +----- Reason
|  +-------- Parent vxid
+----------- Type ("sess", "req" or "bereq")

📊 BereqAcct — Backend request accounting

holds all the byte counters from backend request processing. numbers, numbers, numbers 📈

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

📨 BereqHeader — Backend request header

HTTP header contents, periodt.

The format is:

%s: %s
|   |
|   +- Header value
+----- Header name
NOTE: HTTP header fields are free form records and not strictly made of 2 fields. Accessing a specific header with the prefix notation helps treating the header value as a single string. (iykyk 🫶)

🛠️ BereqMethod — Backend request method

the HTTP request method that got used. GET, POST, whatever she chose 💅

📡 BereqProtocol — Backend request protocol

the HTTP protocol version info. old school HTTP/1.1 or the shiny HTTP/2, it's all here.

🔗 BereqURL — Backend request URL

the HTTP request URL. yes, the whole thing.

🧹 BereqUnset — Backend request unset header

HTTP header contents — specifically, the ones getting unset.

The format is:

%s: %s
|   |
|   +- Header value
+----- Header name
NOTE: HTTP header fields are free form records and not strictly made of 2 fields. Accessing a specific header with the prefix notation helps treating the header value as a single string.

📬 BerespHeader — Backend response header

HTTP header contents, but this time it's the response's turn 💖

The format is:

%s: %s
|   |
|   +- Header value
+----- Header name
NOTE: HTTP header fields are free form records and not strictly made of 2 fields. Accessing a specific header with the prefix notation helps treating the header value as a single string.

🛰️ BerespProtocol — Backend response protocol

the HTTP protocol version information. slay.

💬 BerespReason — Backend response reason

the HTTP response reason string. you know, the little human-readable part after the status code.

🔢 BerespStatus — Backend response status

the HTTP response status code. 200? iconic. 503? we don't talk about it 😭

🧽 BerespUnset — Backend response unset header

HTTP header contents. the unset ones.

The format is:

%s: %s
|   |
|   +- Header value
+----- Header name
NOTE: HTTP header fields are free form records and not strictly made of 2 fields. Accessing a specific header with the prefix notation helps treating the header value as a single string.

🤨 BogoHeader — Bogus HTTP received

contains the first 20 characters of received HTTP headers we could not make sense of. yes bestie, sometimes the HTTP is just nonsense. applies to both req.http and beresp.http. 💀

🖥️ CLI — CLI communication

CLI communication between the varnishd master and the child process. they're chatting, it's fine.

🐛 Debug — Debug messages

debug messages can normally be ignored, but they're sometimes lowkey helpful during trouble-shooting. most debug messages must be explicitly enabled with parameters.

⚠️ Debug messages may be added, changed or removed without prior notice and shouldn't be considered stable. so don't build your whole personality around them fr fr.
NB: This log record is masked by default.

🧨 ESI_xmlerror — ESI parser error or warning message

an error or warning got generated while parsing an ESI object. the log record describes the problem encountered. messy but informative ✨

🏁 End — Marks the end of a VXID

the last record of a VXID transaction. closing credits, she's done 🎬

🚨 Error — Error messages

error messages are stuff you probably want to know. genuinely. look at these. 👀

🚫 ExpBan — Object evicted due to ban

logs the VXID when an object is banned. banned. blocked. removed from the group chat 🚫

⏳ ExpKill — Object expiry event

logs events related to object expiry. here's the full roster of events:

  • EXP_Rearm — logged when the expiry time of an object changes.
  • EXP_Inbox — logged when the expiry thread picks an object from the inbox for processing.
  • EXP_Kill — logged when the expiry thread kills an object from the inbox.
  • EXP_When — logged when the expiry thread moves an object on the binheap.
  • EXP_Inspect — logged when the expiry thread inspects the next object scheduled to expire.
  • EXP_Expired — logged when the expiry thread expires an object.
  • EXP_Removed — logged when the expiry thread removes an object before expiry.
  • VBF_Superseded — logged when an object supersedes another.
  • LRU_Cand — logged when an object is evaluated for LRU force expiry.
  • LRU — logged when an object is force expired due to LRU.
  • LRU_Fail — logged when no suitable candidate object is found for LRU force expiry.

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_Inspect p=%p e=%f f=0x%x
EXP_Expired x=%u t=%f h=%u
EXP_Removed x=%u t=%f h=%u
VBF_Superseded x=%u n=%u
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
n=%u         New object VXID
h=%u         Objcore hits

🕳️ FetchError — Error while fetching object

logs the error message of a failed fetch operation. the fetch did not eat, unfortunately 💔

🫀 Fetch_Body — Body fetched from backend

ready to fetch body from backend. it's go time 🏃‍♀️

The format is:

%d %s %s
|  |  |
|  |  +---- 'stream' or '-'
|  +------- Text description of body fetch mode
+---------- Body fetch mode

🧚 Filters — Body filters

list of filters applied to the body. stacking filters like accessories ✨

🗜️ Gzip — G(un)zip performed on object

a Gzip record is emitted for each instance of gzip or gunzip work performed. worst case, an ESI transaction stored in gzipped objects but delivered gunzipped will run into many of these. so like, expect a lot of them sometimes.

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

📥 H2RxBody — Received HTTP2 frame body

Binary data. that's the whole vibe, bestie 🫶

📥 H2RxHdr — Received HTTP2 frame header

Binary data.

📤 H2TxBody — Transmitted HTTP2 frame body

Binary data.

📤 H2TxHdr — Transmitted HTTP2 frame header

Binary data.

#️⃣ Hash — Value added to hash

this value was added to the object lookup hash. hashing, but make it fashion 🔥

NB: This log record is masked by default.

🎯 Hit — Hit object in cache

object looked up in cache. a HIT. we love to see it, it's giving efficiency 💖

The format is:

…and here's the rest of that little diagram from the record above, bestie, no context switch, we're just picking up right where we left off 🫶

                 %u %f %f %f [%u [%u]]
                 |  |  |  |   |   |
                 |  |  |  |   |   +- Content length
                 |  |  |  |   +----- Fetched so far
                 |  |  |  +--------- Keep period
                 |  |  +------------ Grace period
                 |  +--------------- Remaining TTL
                 +------------------ VXID of the object

🦋 HitMiss — hit for a miss object in cache

It's a hit-for-miss object, and we looked it up in the cache. That's the whole vibe.

The format is:

                 %u %f
                 |  |
                 |  +- Remaining TTL
                 +---- VXID of the object

🎀 HitPass — hit for pass object in cache

Same energy, different flavour: it's a hit-for-pass object, looked up in the cache. ✨

The format is:

                 %u %f
                 |  |
                 |  +- Remaining TTL
                 +---- VXID of the object

💀 HttpGarbage — unparseable HTTP request

Somebody sent us an HTTP request we literally could not parse, and this record logs the content of those unparseable requests. Messy. We're logging it anyway.

🍓 Length — size of object body

Logs the size of a fetch object body. Just the length, that's it, that's the post.

This one links this VXID to any child VXID it initiates — like tagging your little sibling in the group chat, except it's task hierarchy and it's real 💅

The format is:

                 %s %d %s [%u]
                 |  |  |   |
                 |  |  |   +- Child task sub-level
                 |  |  +----- Reason
                 |  +-------- Child vxid
                 +----------- Child type ("sess", "req" or "bereq")

🙈 LostHeader — failed attempt to set HTTP header

When an HTTP header operation fails, this logs the header name. Why did it fail? Either we ran out of resources or we hit the configured limits. Either way, the header is gone, bestie. 😭

👑 Notice — informational messages about request handling

Informational log messages for events that happened while handling a request. Not drama, just tea ☕

The format is:

                 %s: %s
                 |   |
                 |   +- Short description of the notice message
                 +----- Manual page containing the detailed description

See the NOTICE MESSAGES section below, or the individual VMOD manual pages, for the detailed deets on notice messages.

🌸 ObjHeader — object header

HTTP header contents, obviously.

The format is:

                 %s: %s
                 |   |
                 |   +- Header value
                 +----- Header name
NOTE: HTTP header fields are free form records and not strictly made of 2 fields. Accessing a specific header with the prefix notation helps treating the header value as a single string.

⭐ ObjProtocol — object protocol

The HTTP protocol version information. That's it, that's the whole thing ✨

💜 ObjReason — object reason

The HTTP response reason string.

🔥 ObjStatus — object status

The HTTP response status code.

🎀 ObjUnset — object unset header

HTTP header contents.

The format is:

                 %s: %s
                 |   |
                 |   +- Header value
                 +----- Header name
NOTE: HTTP header fields are free form records and not strictly made of 2 fields. Accessing a specific header with the prefix notation helps treating the header value as a single string.

💅 PipeAcct — pipe byte counts

Contains byte counters for pipe sessions. Numbers, numbers, numbers, we love to see it.

The format is:

                 %d %d %d %d
                 |  |  |  |
                 |  |  |  +------- Piped bytes to client
                 |  |  +---------- Piped bytes from client
                 |  +------------- Backend request headers
                 +---------------- Client request headers

🌈 Proxy — PROXY protocol information

PROXY protocol information. Say that five times fast, I dare you.

The format is:

                 %d %s %d %s %d
                 |  |  |  |  |
                 |  |  |  |  +- server port
                 |  |  |  +---- server ip
                 |  |  +------- client port
                 |  +---------- client ip
                 +------------- PROXY protocol version

                 All fields are "local" for PROXY local connections (command 0x0)

💀 ProxyGarbage — unparseable PROXY request

A PROXY protocol header was unparseable. Straight to the void with it.

🦋 ReqAcct — request handling byte counts

Contains byte counts for the request handling. Important detail bestie: the body bytes count includes transmission overhead (ie: chunked encoding). And ESI sub-requests show the body bytes this ESI fragment including any subfragments contributed to the top level request. 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

🍓 ReqHeader — client request header

HTTP header contents.

The format is:

                 %s: %s
                 |   |
                 |   +- Header value
                 +----- Header name
NOTE: HTTP header fields are free form records and not strictly made of 2 fields. Accessing a specific header with the prefix notation helps treating the header value as a single string.

⭐ ReqMethod — client request method

The HTTP request method used. GET, POST, whatever the client decided to serve us today 💅

🧚 ReqProtocol — client request protocol

The HTTP protocol version information.

🌸 ReqStart — client request start

Start of request processing. It logs the client address, the port number, and the listener endpoint name (that's the one from the -a command-line argument).

The format is:

                 %s %s %s
                 |  |  |
                 |  |  +-- Listener name (from -a)
                 |  +----- Client Port number (0 for Unix domain sockets)
                 +-------- Client IP4/6 address (0.0.0.0 for UDS)

🙈 ReqTarget — request target as received

For HTTP1 connections, this is the request-target field from the request line, which has the format method SP request-target SP HTTP-Version (SP for space, 0x20).

NB: This log record is masked by default. 👀

💜 ReqURL — client request URL

The HTTP request URL.

🎀 ReqUnset — client request unset header

HTTP header contents.

The format is:

                 %s: %s
                 |   |
                 |   +- Header value
                 +----- Header name
NOTE: HTTP header fields are free form records and not strictly made of 2 fields. Accessing a specific header with the prefix notation helps treating the header value as a single string.

🌈 RespHeader — client response header

HTTP header contents.

The format is:

                 %s: %s
                 |   |
                 |   +- Header value
                 +----- Header name
NOTE: HTTP header fields are free form records and not strictly made of 2 fields. Accessing a specific header with the prefix notation helps treating the header value as a single string.

⭐ RespProtocol — client response protocol

The HTTP protocol version information.

💜 RespReason — client response reason

The HTTP response reason string.

🔥 RespStatus — client response status

The HTTP response status code.

🎀 RespUnset — client response unset header

HTTP header contents.

The format is:

                 %s: %s
                 |   |
                 |   +- Header value
                 +----- Header name
NOTE: HTTP header fields are free form records and not strictly made of 2 fields. Accessing a specific header with the prefix notation helps treating the header value as a single string.

🦋 SessClose — client connection closed

SessClose is the last record for any client connection. The final boss of the session, if you will 👑

The format is:

                 %s %f
                 |  |
                 |  +- How long the session was open
                 +---- Why the connection closed

Explanation of reasons (first column):

  • REM_CLOSE: Client Closed
  • REQ_CLOSE: Client requested close
  • REQ_HTTP10: Proto < HTTP/1.1
  • RX_BAD: Received bad req/resp
  • RX_BODY: Failure receiving body
  • RX_JUNK: Received junk data
  • RX_OVERFLOW: Received buffer overflow
  • RX_TIMEOUT: Receive timeout
  • RX_CLOSE_IDLE: timeout_idle reached
  • TX_PIPE: Piped transaction
  • TX_ERROR: Error transaction
  • TX_EOF: EOF transmission
  • RESP_CLOSE: Backend/VCL requested close
  • OVERLOAD: Out of some resource
  • PIPE_OVERFLOW: Session pipe overflow
  • RANGE_SHORT: Insufficient data for range
  • REQ_HTTP20: HTTP2 not accepted
  • VCL_FAILURE: VCL failure
  • RAPID_RESET: HTTP2 rapid reset

😭 SessError — client connection accept failed

Accepting a client connection failed. It happens to the best of us, bestie.

The format is:

                 %s %s %s %d %d %s
                 |  |  |  |  |  |
                 |  |  |  |  |  +- Detailed error message
                 |  |  |  |  +---- Error Number (errno) from accept(2)
                 |  |  |  +------- File descriptor number
                 |  |  +---------- Local TCP port / 0 for UDS
                 |  +------------- Local IPv4/6 address / 0.0.0.0 for UDS
                 +---------------- Socket name (from -a argument)

✨ SessOpen — client connection opened

The first record for a client connection, and it comes with the socket-endpoints of the connection. Main character energy, opening the whole show 🌟

The format is:

                 %s %d %s %s %s %f %d
                 |  |  |  |  |  |  |
                 |  |  |  |  |  |  +- File descriptor number
                 |  |  |  |  |  +---- Session start time (unix epoch)
                 |  |  |  |  +------- Local TCP port / 0 for UDS
                 |  |  |  +---------- Local IPv4/6 address / 0.0.0.0 for UDS
                 |  |  +------------- Socket name (from -a argument)
                 |  +---------------- Remote TCP port / 0 for UDS
                 +------------------- Remote IPv4/6 address / 0.0.0.0 for UDS

🍓 Storage — where object is stored

The type and the name of the storage backend the object is stored in. Where does the object live? Here's your answer 🏠

The format is:

                 %s %s
                 |  |
                 |  +- Name of storage backend
                 +---- Type ("malloc", "file", "persistent" etc.)

🌸 TTL — TTL set on object

A TTL record gets emitted whenever the ttl, grace or keep values for an object are set — and also whether the object is cacheable or not. So much information in one little record, we're obsessed 💖

The format is:

                 %s %d %d %d %d [ %d %d %u %u ] %s
                 |  |  |  |  |    |  |  |  |    |
                 |  |  |  |  |    |  |  |  |    +- "cacheable" or "uncacheable"
                 |  |  |  |  |    |  |  |  +------ Max-Age from Cache-Control header
                 |  |  |  |  |    |  |  +--------- Expires header
                 |  |  |  |  |    |  +------------ Date header
                 |  |  |  |  |    +--------------- Age (incl Age: header value)
                 |  |  |  |  +-------------------- Reference time for TTL
                 |  |  |  +----------------------- Keep
                 |  |  +-------------------------- Grace
                 |  +----------------------------- TTL
                 +-------------------------------- "RFC", "VCL" or "HFP"

The four optional fields are only present in RFC headers. (like, only the RFC flavor brings the extra little squad along, okay?)

Examples, bestie:

                 RFC 60 10 -1 1312966109 1312966109 1312966109 0 60 cacheable
                 VCL 120 10 0 1312966111 uncacheable
                 HFP 2 0 0 1312966113 uncacheable

Timestamp - Timing information

Contains timing information for the Varnish worker threads. the receipts on how long everything took, basically

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 the TIMESTAMPS section below for information about the individual time stamps. iykyk 💅

The format is:

                 %s: %f %f %f
                 |   |  |  |
                 |   |  |  +- Time since last timestamp
                 |   |  +---- Time since start of work unit
                 |   +------- Absolute time of event
                 +----------- Event label

VCL_Error - VCL execution error message

Logs error messages generated during VCL execution. something went sideways in your VCL, and this is where it tells you 😭

VCL_Log - Log statement from VCL

User generated log messages insert from VCL through std.log(). that's YOUR voice showing up in the log, main character energy ✨

VCL_acl - VCL ACL check results

ACLs with the +log flag emits this record with the result. so if you flipped that flag on, here's the verdict

The format is:

                 %s [%s [%s [fixed: %s]]]
                 |   |   |          |
                 |   |   |          +- Fix info (see below)
                 |   |   +------------ Matching entry (only for MATCH)
                 |   +---------------- Name of the ACL for MATCH or NO_MATCH
                 +-------------------- MATCH, NO_MATCH or NO_FAM
  • Fix info: either contains network/mask for non-canonical entries (see acl +pedantic flag) or folded for entries which were the result of a fold operation (see acl +fold flag).
  • MATCH denotes an ACL match (slay, it matched)
  • NO_MATCH denotes that a checked ACL has not matched (rip, it did not)
  • NO_FAM denotes a missing address family and should not occur. fr fr, if you see this, something is Weird 💀

VCL_call - VCL method called

Logs the VCL method name when a VCL method is called. basically a little "hey, we're running this one now" ping

VCL_return - VCL method return value

Logs the VCL method terminating statement. the return that ended it, periodt

VCL_trace - VCL trace data

Logs VCL execution trace data. a lil breadcrumb trail through your VCL 🦋

The format is:

                 %s %u %u.%u.%u
                 |  |  |  |  |
                 |  |  |  |  +- VCL program line position
                 |  |  |  +---- VCL program line number
                 |  |  +------- VCL program source index
                 |  +---------- VCL trace point index
                 +------------- VCL configname
NB: This log record is masked by default. (so don't panic if you can't see it — you gotta unmask it)

VCL_use - VCL in use

Records the name of the VCL being used. which VCL is currently running the show 👑

The format is:

                 %s [ %s %s ]
                 |    |  |
                 |    |  +- Name of label used to find it
                 |    +---- "via"
                 +--------- Name of VCL put in use

VSL - VSL API warnings and error message

Warnings and error messages generated by the VSL API while reading the shared memory log. the API itself is complaining, not your VCL

VdpAcct - Deliver filter accounting

Contains name of VDP and statistics. numbers about your deliver filters, bestie 📊

The format is:

                 %s %d %d
                 |  |  |
                 |  |  +- Total bytes produced
                 |  +---- Number of calls made
                 +------- Name of filter
NB: This log record is masked by default.

VfpAcct - Fetch filter accounting

Contains name of VFP and statistics. same energy, but for fetch filters this time 🌸

The format is:

                 %s %d %d
                 |  |  |
                 |  |  +- Total bytes produced
                 |  +---- Number of calls made
                 +------- Name of filter
NB: This log record is masked by default.

Witness - Lock order witness records

Diagnostic recording of locking order. purely diagnostic, it's just watching the locks line up so nothing deadlocks 🔍

WorkThread - Logs thread start/stop events

Logs worker thread creation and termination events. birth and death of worker threads, iconic honestly 🧚

The format is:

                 %p %s
                 |  |
                 |  +- [start|end]
                 +---- Worker struct pointer
NB: This log record is masked by default.

✨ TIMESTAMPS ✨

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. so: when it happened, how long since the whole thing started, and how long since the last stamp ⏱️

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() function. 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. no cap — if your VCL is doing something slow, stamp it so the next stamps don't blame themselves for the delay 💅

Request handling timestamps

  • Start — The start of request processing (first byte received or restart).
  • Req — Complete client request received.
  • ReqBody — Client request body processed (discarded, cached or passed to the backend).
  • Waitinglist — Came off waitinglist.
  • Fetch — Fetch processing finished (completely fetched or ready for streaming).
  • Process — Processing finished, ready to deliver the client response.
  • Resp — Delivery of response to the client finished.
  • Restart — Client request is being restarted.
  • Reset — The client closed its connection, reset its stream or caused a stream error that forced Varnish to reset the stream. Request processing is interrupted and considered failed, with a 408 "Request Timeout" status code. (it's giving "we're done here", abruptly)

Pipe handling timestamps

The following timestamps are client timestamps specific to pipe transactions: pipe-only stamps, okay?

  • Pipe — Opened a pipe to the backend and forwarded the request.
  • PipeSess — The pipe session has finished.

The following timestamps change meaning in a pipe transaction:

  • Process — Processing finished, ready to begin the pipe delivery. (yes it's the same label, but in a pipe it means something a lil different)

Backend fetch timestamps

  • Start — Start of the backend fetch processing.
  • Fetch — Came off vcl_backend_fetch ready to send the backend request.
  • Connected — Successfully established a backend connection, or selected a recycled connection from the pool.
  • Bereq — Backend request sent.
  • Beresp — Backend response headers received.
  • Process — Processing finished, ready to fetch the response body.
  • BerespBody — Backend response body received.
  • Retry — Backend request is being retried.
  • Error — Backend request failed to vcl_backend_error.

💌 NOTICE MESSAGES 💌

Notice messages contain informational messages about the handling of a request. These can be exceptional circumstances encountered that causes deviation from the normal handling. The messages are prefixed with vsl: for core Varnish generated messages, and VMOD authors are encouraged to use vmod_<name>: for their own notice messages. This matches the name of the manual page where detailed descriptions of notice messages are expected. so the prefix literally tells you which manual page to go read — convenient, honestly 🫶

The core messages are described below.

Conditional fetch wait for streaming object

The backend answered 304 Not Modified on a conditional fetch using an object that has not yet been fully fetched as the stale template object. This can only happen when the TTL of the object is less than the time it takes to fetch it. The fetch is halted until the stale object is fully fetched, upon which the new object is created as normal. While waiting, any grace time on the stale object will be in effect. so we're just chillin', waiting on the old one to finish, and grace is doing its thing the whole time 🦋

High number of variants

Objects are primarily looked up from an index using the hash key computed from the hash_data() VCL function. When variants are involved, that is to say when a backend response was stored with a Vary header, a secondary lookup is performed but it is not indexed. As the number of variants for a given key increases, this can slow cache lookups down, and since this happens under a lock, this can greatly increase lock contention, even more so for frequently requested objects. Variants should therefore be used sparingly on cacheable responses, but since they can originate from either VCL or origin servers, this notice should help identify problematic resources. tl;dr: too many variants = the lock gets crowded and everything gets slow, so use them sparingly ⚠️

📜 HISTORY 📜

This document was initially written by Poul-Henning Kamp, and later updated by Martin Blix Grydeland. legends, genuinely 👑

👀 SEE ALSO 👀

This document is licensed under the same licence as Varnish itself. See LICENCE for details. (go read the LICENCE file, bestie, it's right there)

  • Copyright (c) 2006 Verdens Gang AS
  • Copyright (c) 2006-2015 Varnish Software AS

okay that's the whole thing, you made it to the end of VSL(7) 🎀 like actually the entire page, section 7 of the Varnish manual, and I'm so proud of you for reading all of it 💖 go forth and read your logs with confidence, you absolute icon ✨🦋💅

📦 where this page comes from
  • fedora 44: varnish 8.0.2-1.fc44 · BSD-2-Clause AND (BSD-2-Clause-FreeBSD AND BSD-3-Clause AND LicenseRef-Fedora-Public-Domain AND Zlib)
  • fedora 44: varnish 8.0.2-1.fc44 · BSD-2-Clause AND (BSD-2-Clause-FreeBSD AND BSD-3-Clause AND LicenseRef-Fedora-Public-Domain AND Zlib)
  • 📜 the page's license: BSD-2-Clause
  • Copyright (c) 2011-2021 Varnish Software AS
  • 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms