Enhanced PHP File Manager

⬆️ Go Up (..)

📊 Server Information

Server:

nginx/1.28.0

System:

Linux 6.8.0-90-generic

PHP Version:

8.4.15

User:

alqudsvolunteers

Directory:

/home/alqudsvolunteers/rootlink/proc/thread-self/root/usr/share/doc/varnish/html/reference

Free Space:

79.76 GB

🔧 Quick Actions

✏️ Editing: vsl.html

<!DOCTYPE html>

<title>VSL &#8212; Varnish version 7.5.0 documentation</title>
 <link rel="stylesheet" type="text/css" href="../_static/pygments.css?v=fa44fd50" />
 <link rel="stylesheet" type="text/css" href="../_static/classic.css?v=e2714048" />
 
 <script src="../_static/documentation_options.js?v=8214db13"></script>
 <script src="../_static/doctools.js?v=888ff710"></script>
 <script src="../_static/sphinx_highlight.js?v=dc90522c"></script>
 
 <link rel="index" title="Index" href="../genindex.html" />
 <link rel="search" title="Search" href="../search.html" />
 <link rel="next" title="vsl-query" href="vsl-query.html" />
 <link rel="prev" title="varnish-cli" href="varnish-cli.html" /> 
 </head><body>
 <div class="related" role="navigation" aria-label="related navigation">
 <h3>Navigation</h3>
 <ul>
 <li class="right" style="margin-right: 10px">
 <a href="../genindex.html" title="General Index"
 accesskey="I">index</a></li>
 <li class="right" >
 <a href="vsl-query.html" title="vsl-query"
 accesskey="N">next</a> |</li>
 <li class="right" >
 <a href="varnish-cli.html" title="varnish-cli"
 accesskey="P">previous</a> |</li>
 <li class="nav-item nav-item-0"><a href="../index.html">Varnish version 7.5.0 documentation</a> &#187;</li>
 <li class="nav-item nav-item-1"><a href="index.html" accesskey="U">The Varnish Reference Manual</a> &#187;</li>
 <li class="nav-item nav-item-this"><a href="">VSL</a></li> 
 </ul>
 </div>

<div class="document">
 <div class="documentwrapper">
 <div class="bodywrapper">
 <div class="body" role="main">
 
 <section id="vsl">
<h1>VSL<a class="headerlink" href="#vsl" title="Link to this heading">¶</a></h1>
<section id="varnish-shared-memory-logging">
<h2>Varnish Shared Memory Logging<a class="headerlink" href="#varnish-shared-memory-logging" title="Link to this heading">¶</a></h2>
<dl class="field-list simple">
<dt class="field-odd">Manual section:</dt>
<dd class="field-odd">7
</dd>
</dl>
<section id="overview">
<h3>OVERVIEW<a class="headerlink" href="#overview" title="Link to this heading">¶</a></h3>
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.
<section id="vsl-tags">
<h4>VSL tags<a class="headerlink" href="#vsl-tags" title="Link to this heading">¶</a></h4>
<dl>
<dt>BackendClose - Backend connection closed</dt><dd>Logged when a backend connection is closed.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%d %s %s [ %s ]
| | | |
| | | +- Optional reason, see SessClose for explanation
| | +------ &quot;close&quot; or &quot;recycle&quot;
| +--------- Backend display name
+------------ Connection file descriptor
</pre></div>
</div>
</dd>
<dt>BackendOpen - Backend connection opened</dt><dd>Logged when a new backend connection is opened.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%d %s %s %s %s %s %s
| | | | | | |
| | | | | | +- &quot;connect&quot; or &quot;reuse&quot;
| | | | | +---- Local port
| | | | +------- Local address
| | | +---------- Remote port
| | +------------- Remote address
| +---------------- Backend display name
+------------------- Connection file descriptor
</pre></div>
</div>
</dd>
<dt>Backend_health - Backend health check</dt><dd>The result of a backend health probe.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%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
| | +---------------------- &quot;healthy&quot; or &quot;sick&quot;
| +------------------------- &quot;Back&quot;, &quot;Still&quot; or &quot;Went&quot;
+---------------------------- Backend name
</pre></div>
</div>
Probe window bits are:
<div class="highlight-default notranslate"><div class="highlight"><pre>&#39;-&#39;: Could not connect
&#39;4&#39;: Good IPv4
&#39;6&#39;: Good IPv6
&#39;U&#39;: Good UNIX
&#39;x&#39;: Error Xmit
&#39;X&#39;: Good Xmit
&#39;r&#39;: Error Recv
&#39;R&#39;: Good Recv
&#39;H&#39;: Happy
</pre></div>
</div>
When the backend is just created, the window bits for health check
slots that haven’t run yet appear as ‘-’ like failures to connect.
</dd>
<dt>Begin - Marks the start of a VXID</dt><dd>The first record of a VXID transaction.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s %d %s [%u]
| | | |
| | | +- Task sub-level
| | +----- Reason
| +-------- Parent vxid
+----------- Type (&quot;sess&quot;, &quot;req&quot; or &quot;bereq&quot;)
</pre></div>
</div>
</dd>
<dt>BereqAcct - Backend request accounting</dt><dd>Contains byte counters from backend request processing.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%d %d %d %d %d %d
| | | | | |
| | | | | +- Total bytes received
| | | | +---- Body bytes received
| | | +------- Header bytes received
| | +---------- Total bytes transmitted
| +------------- Body bytes transmitted
+---------------- Header bytes transmitted
</pre></div>
</div>
</dd>
<dt>BereqHeader - Backend request header</dt><dd>HTTP header contents.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s: %s
| |
| +- Header value
+----- Header name
</pre></div>
</div>
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.
</dd>
<dt>BereqMethod - Backend request method</dt><dd>The HTTP request method used.
</dd>
<dt>BereqProtocol - Backend request protocol</dt><dd>The HTTP protocol version information.
</dd>
<dt>BereqURL - Backend request URL</dt><dd>The HTTP request URL.
</dd>
<dt>BereqUnset - Backend request unset header</dt><dd>HTTP header contents.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s: %s
| |
| +- Header value
+----- Header name
</pre></div>
</div>
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.
</dd>
<dt>BerespHeader - Backend response header</dt><dd>HTTP header contents.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s: %s
| |
| +- Header value
+----- Header name
</pre></div>
</div>
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.
</dd>
<dt>BerespProtocol - Backend response protocol</dt><dd>The HTTP protocol version information.
</dd>
<dt>BerespReason - Backend response reason</dt><dd>The HTTP response reason string.
</dd>
<dt>BerespStatus - Backend response status</dt><dd>The HTTP response status code.
</dd>
<dt>BerespUnset - Backend response unset header</dt><dd>HTTP header contents.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s: %s
| |
| +- Header value
+----- Header name
</pre></div>
</div>
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.
</dd>
<dt>BogoHeader - Bogus HTTP received</dt><dd>Contains the first 20 characters of received HTTP headers we could not make sense of. Applies to both req.http and beresp.http.
</dd>
<dt>CLI - CLI communication</dt><dd>CLI communication between varnishd master and child process.
</dd>
<dt>Debug - Debug messages</dt><dd>Debug messages can normally be ignored, but are sometimes 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.
NB: This log record is masked by default.
</dd>
<dt>ESI_xmlerror - ESI parser error or warning message</dt><dd>An error or warning was generated during parsing of an ESI object. The log record describes the problem encountered.
</dd>
<dt>End - Marks the end of a VXID</dt><dd>The last record of a VXID transaction.
</dd>
<dt>Error - Error messages</dt><dd>Error messages are stuff you probably want to know.
</dd>
<dt>ExpBan - Object evicted due to ban</dt><dd>Logs the VXID when an object is banned.
</dd>
<dt>ExpKill - Object expiry event</dt><dd>Logs events related to object expiry. The events are:
<dl class="simple">
<dt>EXP_Rearm</dt><dd>Logged when the expiry time of an object changes.
</dd>
<dt>EXP_Inbox</dt><dd>Logged when the expiry thread picks an object from the inbox for processing.
</dd>
<dt>EXP_Kill</dt><dd>Logged when the expiry thread kills an object from the inbox.
</dd>
<dt>EXP_When</dt><dd>Logged when the expiry thread moves an object on the binheap.
</dd>
<dt>EXP_Inspect</dt><dd>Logged when the expiry thread inspects the next object scheduled to expire.
</dd>
<dt>EXP_Expired</dt><dd>Logged when the expiry thread expires an object.
</dd>
<dt>EXP_Removed</dt><dd>Logged when the expiry thread removes an object before expiry.
</dd>
<dt>VBF_Superseded</dt><dd>Logged when an object supersedes another.
</dd>
<dt>LRU_Cand</dt><dd>Logged when an object is evaluated for LRU force expiry.
</dd>
<dt>LRU</dt><dd>Logged when an object is force expired due to LRU.
</dd>
<dt>LRU_Fail</dt><dd>Logged when no suitable candidate object is found for LRU force expiry.
</dd>
</dl>
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>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
</pre></div>
</div>
</dd>
<dt>FetchError - Error while fetching object</dt><dd>Logs the error message of a failed fetch operation.
</dd>
<dt>Fetch_Body - Body fetched from backend</dt><dd>Ready to fetch body from backend.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%d %s %s
| | |
| | +---- &#39;stream&#39; or &#39;-&#39;
| +------- Text description of body fetch mode
+---------- Body fetch mode
</pre></div>
</div>
</dd>
<dt>Filters - Body filters</dt><dd>List of filters applied to the body
</dd>
<dt>Gzip - G(un)zip performed on object</dt><dd>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:
<div class="highlight-default notranslate"><div class="highlight"><pre>%c %c %c %d %d %d %d %d
| | | | | | | |
| | | | | | | +- Bit length of compressed data
| | | | | | +---- Bit location of &#39;last&#39; bit
| | | | | +------- Bit location of first deflate block
| | | | +---------- Bytes output
| | | +------------- Bytes input
| | +---------------- &#39;E&#39;: ESI, &#39;-&#39;: Plain object
| +------------------- &#39;F&#39;: Fetch, &#39;D&#39;: Deliver
+---------------------- &#39;G&#39;: Gzip, &#39;U&#39;: Gunzip, &#39;u&#39;: Gunzip-test
</pre></div>
</div>
Examples:
<div class="highlight-default notranslate"><div class="highlight"><pre>U F E 182 159 80 80 1392
G F E 159 173 80 1304 1314
</pre></div>
</div>
</dd>
<dt>H2RxBody - Received HTTP2 frame body</dt><dd>Binary data
</dd>
<dt>H2RxHdr - Received HTTP2 frame header</dt><dd>Binary data
</dd>
<dt>H2TxBody - Transmitted HTTP2 frame body</dt><dd>Binary data
</dd>
<dt>H2TxHdr - Transmitted HTTP2 frame header</dt><dd>Binary data
</dd>
<dt>Hash - Value added to hash</dt><dd>This value was added to the object lookup hash.
NB: This log record is masked by default.
</dd>
<dt>Hit - Hit object in cache</dt><dd>Object looked up in cache.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%u %f %f %f [%u [%u]]
| | | | | |
| | | | | +- Content length
| | | | +----- Fetched so far
| | | +--------- Keep period
| | +------------ Grace period
| +--------------- Remaining TTL
+------------------ VXID of the object
</pre></div>
</div>
</dd>
<dt>HitMiss - Hit for miss object in cache.</dt><dd>Hit-for-miss object looked up in cache.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%u %f
| |
| +- Remaining TTL
+---- VXID of the object
</pre></div>
</div>
</dd>
<dt>HitPass - Hit for pass object in cache.</dt><dd>Hit-for-pass object looked up in cache.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%u %f
| |
| +- Remaining TTL
+---- VXID of the object
</pre></div>
</div>
</dd>
<dt>HttpGarbage - Unparseable HTTP request</dt><dd>Logs the content of unparseable HTTP requests.
</dd>
<dt>Length - Size of object body</dt><dd>Logs the size of a fetch object body.
</dd>
<dt>Link - Links to a child VXID</dt><dd>Links this VXID to any child VXID it initiates.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s %d %s [%u]
| | | |
| | | +- Child task sub-level
| | +----- Reason
| +-------- Child vxid
+----------- Child type (&quot;sess&quot;, &quot;req&quot; or &quot;bereq&quot;)
</pre></div>
</div>
</dd>
<dt>LostHeader - Failed attempt to set HTTP header</dt><dd>Logs the header name of a failed HTTP header operation due to resource exhaustion or configured limits.
</dd>
<dt>Notice - Informational messages about request handling</dt><dd>Informational log messages on events occurred during request handling.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s: %s
| |
| +- Short description of the notice message
+----- Manual page containing the detailed description
</pre></div>
</div>
See the NOTICE MESSAGES section below or the individual VMOD manual pages for detailed information of notice messages.
</dd>
<dt>ObjHeader - Object header</dt><dd>HTTP header contents.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s: %s
| |
| +- Header value
+----- Header name
</pre></div>
</div>
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.
</dd>
<dt>ObjProtocol - Object protocol</dt><dd>The HTTP protocol version information.
</dd>
<dt>ObjReason - Object reason</dt><dd>The HTTP response reason string.
</dd>
<dt>ObjStatus - Object status</dt><dd>The HTTP response status code.
</dd>
<dt>ObjUnset - Object unset header</dt><dd>HTTP header contents.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s: %s
| |
| +- Header value
+----- Header name
</pre></div>
</div>
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.
</dd>
<dt>PipeAcct - Pipe byte counts</dt><dd>Contains byte counters for pipe sessions.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%d %d %d %d
| | | |
| | | +------- Piped bytes to client
| | +---------- Piped bytes from client
| +------------- Backend request headers
+---------------- Client request headers
</pre></div>
</div>
</dd>
<dt>Proxy - PROXY protocol information</dt><dd>PROXY protocol information.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%d %s %d %s %d
| | | | |
| | | | +- server port
| | | +---- server ip
| | +------- client port
| +---------- client ip
+------------- PROXY protocol version

All fields are &quot;local&quot; for PROXY local connections (command 0x0)
</pre></div>
</div>
</dd>
<dt>ProxyGarbage - Unparseable PROXY request</dt><dd>A PROXY protocol header was unparseable.
</dd>
<dt>ReqAcct - Request handling byte counts</dt><dd>Contains byte counts for the request handling.
The body bytes count includes transmission overhead (ie: chunked encoding).
ESI sub-requests show the body bytes this ESI fragment including any subfragments contributed to the top level request.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%d %d %d %d %d %d
| | | | | |
| | | | | +- Total bytes transmitted
| | | | +---- Body bytes transmitted
| | | +------- Header bytes transmitted
| | +---------- Total bytes received
| +------------- Body bytes received
+---------------- Header bytes received
</pre></div>
</div>
</dd>
<dt>ReqHeader - Client request header</dt><dd>HTTP header contents.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s: %s
| |
| +- Header value
+----- Header name
</pre></div>
</div>
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.
</dd>
<dt>ReqMethod - Client request method</dt><dd>The HTTP request method used.
</dd>
<dt>ReqProtocol - Client request protocol</dt><dd>The HTTP protocol version information.
</dd>
<dt>ReqStart - Client request start</dt><dd>Start of request processing. Logs the client address, port number and listener endpoint name (from the -a command-line argument).
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%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)
</pre></div>
</div>
</dd>
<dt>ReqURL - Client request URL</dt><dd>The HTTP request URL.
</dd>
<dt>ReqUnset - Client request unset header</dt><dd>HTTP header contents.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s: %s
| |
| +- Header value
+----- Header name
</pre></div>
</div>
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.
</dd>
<dt>RespHeader - Client response header</dt><dd>HTTP header contents.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s: %s
| |
| +- Header value
+----- Header name
</pre></div>
</div>
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.
</dd>
<dt>RespProtocol - Client response protocol</dt><dd>The HTTP protocol version information.
</dd>
<dt>RespReason - Client response reason</dt><dd>The HTTP response reason string.
</dd>
<dt>RespStatus - Client response status</dt><dd>The HTTP response status code.
</dd>
<dt>RespUnset - Client response unset header</dt><dd>HTTP header contents.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s: %s
| |
| +- Header value
+----- Header name
</pre></div>
</div>
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.
</dd>
<dt>SessClose - Client connection closed</dt><dd>SessClose is the last record for any client connection.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s %f
| |
| +- How long the session was open
+---- Why the connection closed
</pre></div>
</div>
<dl class="simple">
<dt>Explanation of reasons (first column):</dt><dd><ul class="simple">
<li><code class="docutils literal notranslate">REM_CLOSE</code>: Client Closed</li>
<li><code class="docutils literal notranslate">REQ_CLOSE</code>: Client requested close</li>
<li><code class="docutils literal notranslate">REQ_HTTP10</code>: Proto &lt; HTTP/1.1</li>
<li><code class="docutils literal notranslate">RX_BAD</code>: Received bad req/resp</li>
<li><code class="docutils literal notranslate">RX_BODY</code>: Failure receiving body</li>
<li><code class="docutils literal notranslate">RX_JUNK</code>: Received junk data</li>
<li><code class="docutils literal notranslate">RX_OVERFLOW</code>: Received buffer overflow</li>
<li><code class="docutils literal notranslate">RX_TIMEOUT</code>: Receive timeout</li>
<li><code class="docutils literal notranslate">RX_CLOSE_IDLE</code>: timeout_idle reached</li>
<li><code class="docutils literal notranslate">TX_PIPE</code>: Piped transaction</li>
<li><code class="docutils literal notranslate">TX_ERROR</code>: Error transaction</li>
<li><code class="docutils literal notranslate">TX_EOF</code>: EOF transmission</li>
<li><code class="docutils literal notranslate">RESP_CLOSE</code>: Backend/VCL requested close</li>
<li><code class="docutils literal notranslate">OVERLOAD</code>: Out of some resource</li>
<li><code class="docutils literal notranslate">PIPE_OVERFLOW</code>: Session pipe overflow</li>
<li><code class="docutils literal notranslate">RANGE_SHORT</code>: Insufficient data for range</li>
<li><code class="docutils literal notranslate">REQ_HTTP20</code>: HTTP2 not accepted</li>
<li><code class="docutils literal notranslate">VCL_FAILURE</code>: VCL failure</li>
<li><code class="docutils literal notranslate">RAPID_RESET</code>: HTTP2 rapid reset</li>
</ul>
</dd>
</dl>
</dd>
<dt>SessError - Client connection accept failed</dt><dd>Accepting a client connection has failed.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%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)
</pre></div>
</div>
</dd>
<dt>SessOpen - Client connection opened</dt><dd>The first record for a client connection, with the socket-endpoints of the connection.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%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
</pre></div>
</div>
</dd>
<dt>Storage - Where object is stored</dt><dd>Type and name of the storage backend the object is stored in.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s %s
| |
| +- Name of storage backend
+---- Type (&quot;malloc&quot;, &quot;file&quot;, &quot;persistent&quot; etc.)
</pre></div>
</div>
</dd>
<dt>TTL - TTL set on object</dt><dd>A TTL record is emitted whenever the ttl, grace or keep values for an object is set as well as whether the object is cacheable or not.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s %d %d %d %d [ %d %d %u %u ] %s
| | | | | | | | | |
| | | | | | | | | +- &quot;cacheable&quot; or &quot;uncacheable&quot;
| | | | | | | | +------ Max-Age from Cache-Control header
| | | | | | | +--------- Expires header
| | | | | | +------------ Date header
| | | | | +--------------- Age (incl Age: header value)
| | | | +-------------------- Reference time for TTL
| | | +----------------------- Keep
| | +-------------------------- Grace
| +----------------------------- TTL
+-------------------------------- &quot;RFC&quot;, &quot;VCL&quot; or &quot;HFP&quot;
</pre></div>
</div>
The four optional fields are only present in “RFC” headers.
Examples:
<div class="highlight-default notranslate"><div class="highlight"><pre>RFC 60 10 -1 1312966109 1312966109 1312966109 0 60 cacheable
VCL 120 10 0 1312966111 uncacheable
HFP 2 0 0 1312966113 uncacheable
</pre></div>
</div>
</dd>
<dt>Timestamp - Timing information</dt><dd>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 the TIMESTAMPS section below for information about the individual time stamps.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s: %f %f %f
| | | |
| | | +- Time since last timestamp
| | +---- Time since start of work unit
| +------- Absolute time of event
+----------- Event label
</pre></div>
</div>
</dd>
<dt>VCL_Error - VCL execution error message</dt><dd>Logs error messages generated during VCL execution.
</dd>
<dt>VCL_Log - Log statement from VCL</dt><dd>User generated log messages insert from VCL through std.log()
</dd>
<dt>VCL_acl - VCL ACL check results</dt><dd>ACLs with the <cite>+log</cite> flag emits this record with the result.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%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
</pre></div>
</div>
<ul class="simple">
<li>Fix info: either contains network/mask for non-canonical entries (see acl +pedantic flag) or <code class="docutils literal notranslate">folded</code> for entries which were the result of a fold operation (see acl +fold flag).</li>
<li><code class="docutils literal notranslate">MATCH</code> denotes an ACL match</li>
<li><code class="docutils literal notranslate">NO_MATCH</code> denotes that a checked ACL has not matched</li>
<li><code class="docutils literal notranslate">NO_FAM</code> denotes a missing address family and should not occur.</li>
</ul>
</dd>
<dt>VCL_call - VCL method called</dt><dd>Logs the VCL method name when a VCL method is called.
</dd>
<dt>VCL_return - VCL method return value</dt><dd>Logs the VCL method terminating statement.
</dd>
<dt>VCL_trace - VCL trace data</dt><dd>Logs VCL execution trace data.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s %u %u.%u.%u
| | | | |
| | | | +- VCL program line position
| | | +---- VCL program line number
| | +------- VCL program source index
| +---------- VCL trace point index
+------------- VCL configname
</pre></div>
</div>
NB: This log record is masked by default.
</dd>
<dt>VCL_use - VCL in use</dt><dd>Records the name of the VCL being used.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s [ %s %s ]
| | |
| | +- Name of label used to find it
| +---- &quot;via&quot;
+--------- Name of VCL put in use
</pre></div>
</div>
</dd>
<dt>VSL - VSL API warnings and error message</dt><dd>Warnings and error messages generated by the VSL API while reading the shared memory log.
</dd>
<dt>VdpAcct - Deliver filter accounting</dt><dd>Contains name of VDP and statistics.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s %d %d
| | |
| | +- Total bytes produced
| +---- Number of calls made
+------- Name of filter
</pre></div>
</div>
NB: This log record is masked by default.
</dd>
<dt>VfpAcct - Fetch filter accounting</dt><dd>Contains name of VFP and statistics.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%s %d %d
| | |
| | +- Total bytes produced
| +---- Number of calls made
+------- Name of filter
</pre></div>
</div>
NB: This log record is masked by default.
</dd>
<dt>Witness - Lock order witness records</dt><dd>Diagnostic recording of locking order.
</dd>
<dt>WorkThread - Logs thread start/stop events</dt><dd>Logs worker thread creation and termination events.
The format is:
<div class="highlight-default notranslate"><div class="highlight"><pre>%p %s
| |
| +- [start|end]
+---- Worker struct pointer
</pre></div>
</div>
NB: This log record is masked by default.
</dd>
</dl>
</section>
</section>
<section id="timestamps">
<h3>TIMESTAMPS<a class="headerlink" href="#timestamps" title="Link to this heading">¶</a></h3>
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() 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.
<section id="request-handling-timestamps">
<h4>Request handling timestamps<a class="headerlink" href="#request-handling-timestamps" title="Link to this heading">¶</a></h4>
<dl class="simple">
<dt>Start</dt><dd>The start of request processing (first byte received or
restart).
</dd>
<dt>Req</dt><dd>Complete client request received.
</dd>
<dt>ReqBody</dt><dd>Client request body processed (discarded, cached or passed to
the backend).
</dd>
<dt>Waitinglist</dt><dd>Came off waitinglist.
</dd>
<dt>Fetch</dt><dd>Fetch processing finished (completely fetched or ready for
streaming).
</dd>
<dt>Process</dt><dd>Processing finished, ready to deliver the client response.
</dd>
<dt>Resp</dt><dd>Delivery of response to the client finished.
</dd>
<dt>Restart</dt><dd>Client request is being restarted.
</dd>
<dt>Reset</dt><dd>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.
</dd>
</dl>
</section>
<section id="pipe-handling-timestamps">
<h4>Pipe handling timestamps<a class="headerlink" href="#pipe-handling-timestamps" title="Link to this heading">¶</a></h4>
The following timestamps are client timestamps specific to pipe transactions:
<dl class="simple">
<dt>Pipe</dt><dd>Opened a pipe to the backend and forwarded the request.
</dd>
<dt>PipeSess</dt><dd>The pipe session has finished.
</dd>
</dl>
The following timestamps change meaning in a pipe transaction:
<dl class="simple">
<dt>Process</dt><dd>Processing finished, ready to begin the pipe delivery.
</dd>
</dl>
</section>
<section id="backend-fetch-timestamps">
<h4>Backend fetch timestamps<a class="headerlink" href="#backend-fetch-timestamps" title="Link to this heading">¶</a></h4>
<dl class="simple">
<dt>Start</dt><dd>Start of the backend fetch processing.
</dd>
<dt>Fetch</dt><dd>Came off vcl_backend_fetch ready to send the backend request.
</dd>
<dt>Connected</dt><dd>Successfully established a backend connection, or selected a recycled
connection from the pool.
</dd>
<dt>Bereq</dt><dd>Backend request sent.
</dd>
<dt>Beresp</dt><dd>Backend response headers received.
</dd>
<dt>Process</dt><dd>Processing finished, ready to fetch the response body.
</dd>
<dt>BerespBody</dt><dd>Backend response body received.
</dd>
<dt>Retry</dt><dd>Backend request is being retried.
</dd>
<dt>Error</dt><dd>Backend request failed to vcl_backend_error.
</dd>
</dl>
</section>
</section>
<section id="notice-messages">
<h3>NOTICE MESSAGES<a class="headerlink" href="#notice-messages" title="Link to this heading">¶</a></h3>
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 <code class="docutils literal notranslate">vsl:</code>
for core Varnish generated messages, and VMOD authors are encouraged to
use <code class="docutils literal notranslate">vmod_&lt;name&gt;:</code> for their own notice messages. This matches the name
of the manual page where detailed descriptions of notice messages are
expected.
The core messages are described below.
<section id="conditional-fetch-wait-for-streaming-object">
<h4>Conditional fetch wait for streaming object<a class="headerlink" href="#conditional-fetch-wait-for-streaming-object" title="Link to this heading">¶</a></h4>
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.
</section>
<section id="high-number-of-variants">
<h4>High number of variants<a class="headerlink" href="#high-number-of-variants" title="Link to this heading">¶</a></h4>
Objects are primarily looked up from an index using the hash key computed from
the <code class="docutils literal notranslate">hash_data()</code> VCL function. When variants are involved, that is to say
when a backend response was stored with a <code class="docutils literal notranslate">Vary</code> 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.
</section>
</section>
<section id="history">
<h3>HISTORY<a class="headerlink" href="#history" title="Link to this heading">¶</a></h3>
This document was initially written by Poul-Henning Kamp, and later updated by
Martin Blix Grydeland.
</section>
<section id="see-also">
<h3>SEE ALSO<a class="headerlink" href="#see-also" title="Link to this heading">¶</a></h3>
<ul class="simple">
<li><a class="reference internal" href="varnishhist.html#varnishhist-1">varnishhist</a></li>
<li><a class="reference internal" href="varnishlog.html#varnishlog-1">varnishlog</a></li>
<li><a class="reference internal" href="varnishncsa.html#varnishncsa-1">varnishncsa</a></li>
<li><a class="reference internal" href="varnishtop.html#varnishtop-1">varnishtop</a></li>
</ul>
</section>
<section id="copyright">
<h3>COPYRIGHT<a class="headerlink" href="#copyright" title="Link to this heading">¶</a></h3>
This document is licensed under the same licence as Varnish
itself. See LICENCE for details.
<ul class="simple">
<li>Copyright (c) 2006 Verdens Gang AS</li>
<li>Copyright (c) 2006-2015 Varnish Software AS</li>
</ul>
</section>
</section>
</section>

<div class="clearer"></div>
 </div>
 </div>
 </div>
 <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
 <div class="sphinxsidebarwrapper">
 <div>
 <h3><a href="../index.html">Table of Contents</a></h3>
 <ul>
<li><a class="reference internal" href="#">VSL</a><ul>
<li><a class="reference internal" href="#varnish-shared-memory-logging">Varnish Shared Memory Logging</a><ul>
<li><a class="reference internal" href="#overview">OVERVIEW</a><ul>
<li><a class="reference internal" href="#vsl-tags">VSL tags</a></li>
</ul>
</li>
<li><a class="reference internal" href="#timestamps">TIMESTAMPS</a><ul>
<li><a class="reference internal" href="#request-handling-timestamps">Request handling timestamps</a></li>
<li><a class="reference internal" href="#pipe-handling-timestamps">Pipe handling timestamps</a></li>
<li><a class="reference internal" href="#backend-fetch-timestamps">Backend fetch timestamps</a></li>
</ul>
</li>
<li><a class="reference internal" href="#notice-messages">NOTICE MESSAGES</a><ul>
<li><a class="reference internal" href="#conditional-fetch-wait-for-streaming-object">Conditional fetch wait for streaming object</a></li>
<li><a class="reference internal" href="#high-number-of-variants">High number of variants</a></li>
</ul>
</li>
<li><a class="reference internal" href="#history">HISTORY</a></li>
<li><a class="reference internal" href="#see-also">SEE ALSO</a></li>
<li><a class="reference internal" href="#copyright">COPYRIGHT</a></li>
</ul>
</li>
</ul>
</li>
</ul>

</div>
 <div>
 <h4>Previous topic</h4>
 <a href="varnish-cli.html"
 title="previous chapter">varnish-cli</a>
 </div>
 <div>
 <h4>Next topic</h4>
 <a href="vsl-query.html"
 title="next chapter">vsl-query</a>
 </div>
 <div role="note" aria-label="source link">
 <h3>This Page</h3>
 <ul class="this-page-menu">
 <li><a href="../_sources/reference/vsl.rst.txt"
 rel="nofollow">Show Source</a></li>
 </ul>
 </div>
<div id="searchbox" style="display: none" role="search">
 <h3 id="searchlabel">Quick search</h3>
 <div class="searchformwrapper">
 <form class="search" action="../search.html" method="get">
 <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
 <input type="submit" value="Go" />
 </form>
 </div>
</div>
<script>document.getElementById('searchbox').style.display = "block"</script>
 </div>
 </div>
 <div class="clearer"></div>
 </div>
 <div class="related" role="navigation" aria-label="related navigation">
 <h3>Navigation</h3>
 <ul>
 <li class="right" style="margin-right: 10px">
 <a href="../genindex.html" title="General Index"
 >index</a></li>
 <li class="right" >
 <a href="vsl-query.html" title="vsl-query"
 >next</a> |</li>
 <li class="right" >
 <a href="varnish-cli.html" title="varnish-cli"
 >previous</a> |</li>
 <li class="nav-item nav-item-0"><a href="../index.html">Varnish version 7.5.0 documentation</a> &#187;</li>
 <li class="nav-item nav-item-1"><a href="index.html" >The Varnish Reference Manual</a> &#187;</li>
 <li class="nav-item nav-item-this"><a href="">VSL</a></li> 
 </ul>
 </div>
 <div class="footer" role="contentinfo">
 &#169; Copyright 2010-2014, Varnish Software AS.
 Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.2.6.
 </div>
 </body>
</html>

❌ Cancel

🗂️ Enhanced PHP File Manager

📊 Server Information

🔧 Quick Actions

✏️ Editing: vsl.html

📤 Upload File

📁 Create Folder

📄 Create File

✏️ Rename Item

🗑️ Delete Confirmation