The logs are a valuable source of information about Squid workloads and performance. The logs record not only access information, but also system configuration errors and resource consumption (eg, memory, disk space).
There are basically two formats for the access.log file: ``native'' and ``common.'' The Common Logfile Format is used by numerous HTTP servers. This format consists of the following seven fields:
remotehost rfc931 authuser [date] "method URL" status bytes
The native format is different for different major versions of Squid. For Squid-1.0 it is:
time elapsed remotehost code/status/peerstatus bytes method URL
For Squid-1.1, the information from the hierarchy.log was moved into access.log. The format is:
time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost
This logfile exists for Squid-1.0 only. The format is
[date] URL peerstatus peerhost
The store.log consists of the following fields:
time The time this entry was logged. The value is the raw Unix time plus milliseconds. action One of RELEASE, SWAPIN, or SWAPOUT. RELEASE means the object has been removed from the cache. SWAPOUT means the object has been saved to disk. SWAPIN means the object existed on disk and has been swapped into memory. status The HTTP reply code. The following three fields are timestamps parsed from the HTTP reply headers. All are expressed in Unix time. A missing header is represented with -2 and an unparsable header is represented as -1. datehdr The value of the HTTP Date: reply header. lastmod The value of the HTTP Last-Modified: reply header. expires The value of the HTTP Expires: reply header. type The HTTP Content-Type reply header. expect-len The value of the HTTP Content-Length reply header. Zero if Content-Length was missing. real-len The number of bytes of content actually read. If the expect-len is non-zero, and not equal to the real-len, the object will be released from the cache. method HTTP request method key The cache key. Often this is simply the URL. Cache objects which never become public will have cache keys that include a unique integer sequence number, the request method, and then the URL.
These are the definitions for the various log format components:
The IP address of the client host. In Squid-1.1, if the log_fqdn option is enabled, full hostnames will be logged when available.
The username associated with the client connection, determined from an Ident (RFC 931) server running on the client host. By default Ident lookups are not made, but may be enabled with the ident_lookup option.
Always NULL ("-") for Squid logs.
GET, HEAD, POST, etc. for HTTP requests. ICP_QUERY for ICP requests.
The requested URL.
The ``cache result'' of the request. This describes if the request was a cache hit or miss, and if the object was refreshed. See the full list of cache result codes.
HTTP status code: 200 for succesful actions, 000 for UDP requests, 403 for redirects, 500 for server errors, etc. See the HTTP status codes for a complete list.
The number of bytes delivered to the client.
A status code that explains how the request was forwarded, either too your peer (neighbor) caches, or directly to the origin server.
The host where the request was forwarded to.
Unix timestamp (since Jan 1, 1970) with millisecond resolution.
HTTP date format:
The time elapsed (milliseconds) during the client connection. For HTTP requests, this is the time between the accept() and close() system calls for the TCP socket. For ICP requests, this represents the time between scheduling the reply message for sending and actually sending it.
Note, TCP_ refers to requests on the HTTP port (3128).
A valid copy of the requested object was in the cache.
The requested object was not in the cache.
] The object was in the cache, but STALE. An If-Modified-Since request was made and a "304 Not Modified" reply was received.
The object was in the cache, but STALE. The request to validate the object failed, so the old (stale) object was returned.
The object was in the cache, but STALE. An If-Modified-Since request was made and the reply contained new content.
The client issued a request with the "no-cache" pragma.
The client issued an If-Modified-Since request and the object was in the cache and still fresh.
The client issued an If-Modified-Since request for a stale object.
The object was believed to be in the cache, but could not be accessed.
Access was denied for this request
"UDP_" refers to requests on the ICP port (3130) UDP_HIT A valid copy of the requested object was in the cache. UDP_HIT_OBJ Same as UDP_HIT, but the object data was small enough to be sent in the UDP reply packet. Saves the following TCP request. UDP_MISS The requested object was not in the cache. UDP_DENIED Access was denied for this request. UDP_INVALID An invalid request was received. UDP_RELOADING The ICP request was "refused" because the cache is busy reloading its metadata. "ERR_" refers to various types of errors for HTTP requests.
Hierarchy Data Tags DIRECT The object has been requested from the origin server. FIREWALL_IP_DIRECT The object has been requested from the origin server because the origin host IP address is inside your firewall. FIRST_PARENT_MISS The object has been requested from the parent cache with the fastest weighted round trip time. FIRST_UP_PARENT The object has been requested from the first available parent in your list. LOCAL_IP_DIRECT The object has been requested from the origin server because the origin host IP address matched your 'local_ip' list. SIBLING_HIT The object was requested from a sibling cache which replied with a UDP_HIT. NO_DIRECT_FAIL The object could not be requested because of firewall restrictions and no parent caches were available. NO_PARENT_DIRECT The object was requested from the origin server because no parent caches exist for the URL. PARENT_HIT The object was requested from a parent cache which replied with a UDP_HIT. SINGLE_PARENT The object was requested from the only parent cache appropriate for this URL. SOURCE_FASTEST The object was requested from the origin server because the 'source_ping' reply arrived first. PARENT_UDP_HIT_OBJ The object was received in a UDP_HIT_OBJ reply from a parent cache. SIBLING_UDP_HIT_OBJ The object was received in a UDP_HIT_OBJ reply from a sibling cache. PASSTHROUGH_PARENT The neighbor or proxy defined in the config option 'passthrough_proxy' was used. SSL_PARENT_MISS The neighbor or proxy defined in the config option 'ssl_proxy' was used. DEFAULT_PARENT No ICP queries were sent to any parent caches. This parent was chosen because it was marked as 'default' in the config file. ROUNDROBIN_PARENT No ICP queries were received from any parent caches. This parent was chosen because it was marked as 'default' in the config file and it had the lowest round-robin use count. CLOSEST_PARENT_MISS This parent was selected because it included the lowest RTT measurement to the origin server. This only appears with 'query_icmp on' set in the config file. CLOSEST_DIRECT The object was fetched directly from the origin server because this cache measured a lower RTT than any of the parent caches.
Almost any of these may be preceeded by 'TIMEOUT_' if the two-second (default) timeout occurs waiting for all ICP replies to arrive from neighbors.
These are taken from RFC 2068.
100 Continue 101 Switching Protocols 200 OK 201 Created 202 Accepted 203 Non-Authoritative Information 204 No Content 205 Reset Content 206 Partial Content 300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily 303 See Other 304 Not Modified 305 Use Proxy 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Time-out 409 Conflict 410 Gone 411 Length Required 412 Precondition Failed 413 Request Entity Too Large 414 Request-URI Too Large 415 Unsupported Media Type 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Gateway Time-out 505 HTTP Version not supported
This file has a rather unfortuntate name. It also is often called the swap log. It is a record of every cache object written to disk. It is read when Squid starts up to ``reload'' the cache. If you remove this file, you will effectively wipe out your cache contents.
For Squid-1.1, there are six fields:
The best way to maintain Squid log files is to send the squid process a USR1 signal. This causes the current log files to be closed and renamed. You can then remove any of the old log files. For example, if your squid.pid file is /usr/local/squid/logs/squid.pid/ (as defined in your squid.conf file) you would do:
kill -USR1 `cat /usr/local/squid/logs/squid.pid`
line in squid.conf makes it generally unnecessary to delete
logfiles by hand. Just set
logfile_rotate to the
number of old logs you want saved. Each time the value of
logfile_rotate is reached, the oldest log will be
deleted automatically. You may find it useful to simply set
logfile_rotate to the number of old logs you want,
and then set up a crontab to send squid the
The following crontab entry would tell Squid to rotate the logs
every day at midnight:
0 0 * * * /bin/kill -USR1 `cat /usr/local/squid/logs/squid.pid`
The only logfile you should never delete
is the file cleverly named
log which normally exists
in the first
cache_dir directory. This file contains
the meta data needed to rebuild the cache when squid starts up.
Deleting this file effectively wipes out your
This message means that the requested object was in ``Delete Behind'' mode and the user aborted the transfer. An object will go into ``Delete Behind'' mode if
This means that a timeout occurred while the object was being transferred. Most likely the retrieval of this object was very slow (or it stalled before finishing) and the user aborted the request. However, depending on your settings for quick_abort, Squid may have continued to try retrieving the object. Squid imposes a maximum amount of time on all open sockets, so after some amount of time the stalled request was aborted and logged win an ERR_LIFETIME_EXP message.
I've been asked to retrieve an object which was accidentally destroyed at the source for recovery. So, how do I figure out where the things are so I can copy them out and strip off the headers?
The following method applies only to the Squid-1.1 versions:
Use grep to find the named object (Url) in the cache/log file. The first filed in this file is an integer file number.
Then, find the file fileno-to-pathname.pl from the ``scripts'' directory of the Squid source distribution. The usage is
perl fileno-to-pathname.pl [-c squid.conf]file numbers are read on stdin, and pathnames are printed on stdout.