一、日志文件
1、cache.log
       cache.log包含多种消息，例如Squid的配置信息、性能警告、以及严重错误。
 
       每个cache.log条目以时间戳开始，指示消息何时产生。本示例里的日志报告了squid的版本（2.5.STABLE4），以及squid所运行的操作系统标识符（i386-unknown-freebsd4.8）。接下来是进程ID（18990）。许多cache.log条目看起来含义不明（例如Target number of buckets: 39）。大多数正常情形下，可以忽略这些不易理解的条目。另一方面，你也许该仔细看一下本质的配置细节，例如名字服务器的地址，或HTTP服务器地址。本示例日志最后陈述了Squid准备接受请求。此时Squid可以接受来自客户端的HTTP连接。
         通常，cache.log增长缓慢。然而，不正常的HTTP事务或类似的事件可以导致squid发布一个debug消息。假如这样的事件经常发生（例如DOS***、新的病毒、磁盘意外等），日志文件会增长很快。定期轮转日志减少了用光磁盘的风险。
主要的错误和异常条件最可能报告在cache.log里。我推荐存档这些日志，以便以后回查事件的源头。当在Squid的邮件列表或类似论坛描述这些故障时，相应的cache.log非常有用。某些情形下，你也许应该调大日志的debug级别，以便其他人能更好的理解和修正你的问题。
2、access.log
      Squid把关于HTTP事务的关键信息存放在access.log里。该文件是基于行的，也就是说每行对应一个客户端请求。squid记录客户端IP（或主机名）、请求URL、响应size、和其他信息。
        Squid在access.log里记录所有HTTP访问，除了那些在还没有发送数据前就断开的连接。Squid也记录所有的ICP（非HTCP）事务，除非你使用log_icp_queries指令关闭了这个功能。第13.2.4节描述了其他影响access日志的squid.conf指令。
默认的access.log格式包含了10个域
如下是对每个域的详细解释：
1).时间戳
请求完成时间，以Unix纪元（UTC 1970-01-01 00:00:00）以来的秒数表示，它是毫秒级的。squid使用这种格式而不是人工可读的时间格式，是为了简化某些日志处理程序的工作。
可以使用一个简单的perl命令来转化Unix时间戳到本地时间，例如：
perl -pe 's/^\d+\.\d+/localtime($&)/e;' access.log

2).响应时间
对HTTP事务来说，该域表明squid花了多少时间来处理请求。在squid接受到HTTP请求时开始计时，在响应完全送出后计时终止。响应时间是毫秒级的。
对ICP查询来说，响应时间通常是0。这是因为squid回答ICP查询非常迅速。甚至，squid在接受到ICP查询和发送完响应之间，不会更新进程时钟。
尽管时间值是毫秒级的，但是精度可能是10毫秒。在squid负载繁重时，计时变得没那么精确。
3).客户端地址
该域包含客户端的IP地址，或者是主机名--假如激活了log_fqdn。出于安全或隐私的理由，你可能需要使用client_netmask指令来掩盖客户端地址的一部分。然而，这样让来自同一客户端的组请求变得不可能。
4).结果/状态码
该域包含2个token，以斜杠分隔。第一个token叫结果码，它把协议和事务结果（例如TCP_HIT或UDP_DENIED）进行归类。这些是squid专有的编码，在13.2.1节里有定义。以TCP_开头的编码指HTTP请求，以UDP_开头的编码指ICP查询。
第2个token是HTTP响应状态码（例如200,304,404等）。状态码通常来自原始服务器。在某些情形下，squid可能有义务自己选择状态码。这些编码在HTTP的RFC里定义，在随后的Table 13-1里有概述。
5).传输size
该域指明传给客户端的字节数。严格的讲，它是squid告诉TCP/IP协议栈去发送给客户端的字节数。这就是说，它不包括TCP/IP头部的overhead。也请注意，传输size正常来说大于响应的Content-Length。传输size包括了HTTP响应头部，然而Content-Length不包括。
传输size可用于近似的带宽使用分析，但并非精确的HTTP实体size计算。假如需要了解响应的Content-Length，可在store.log里找到它。
6).请求方式
该域包含请求方式。因为squid客户端可能使用ICP或HTTP，请求方式就可能是HTTP-或ICP-这2种。最普通的HTTP请求方式是GET。ICP查询总以ICP_QUERY的形式被记载。请见6.1.2.8节关于squid了解的HTTP方式列表。
7).URI
该域包含来自客户端请求的URI。大多数记录下来的URI实际是URL（例如，它们有主机名）。
Squid对某些失败使用特殊的记录格式。例如Squid不能解析HTTP请求，或者不能决定URI，这时你可能见到类似于"error:invalid-request." 的字串出现在URI的位置。例如：
1066036250.603 310 192.0.34.70 NONE/400 1203 GET error:invalid-request - NONE/- -另外在该域里，也请留心URI里的空格字符。取决于uri_whitespace设置，squid可能在日志文件里打印URI时带空格字符。若发生这种情况，则阅读access.log文件的日志分析工具可能会遇到麻烦。
在记日志时，squid删掉了在第一个问号(?)之后的所有URI字符，除非禁用了strip_query_terms指令。
8).客户端身份
Squid有2种不同的办法来决定用户的身份。一种是RFC 1413身份协议，另一种来自HTTP验证头部。
Squid试图基于ident_lookup_access规则进行身份查询，假如有的话。另外，假如使用代理验证（或在代理人模式下的规范服务验证），squid会在该域放置给定的用户名。假如2者都提供给squid一个用户名，并且你使用了原始access.log格式，那么HTTP验证名字会记录下来，RFC 1413名字会忽略掉。普通日志文件格式会把两者都独立的记录。
9).对端编码/对端主机
对端信息包含了2个token，以斜杠分隔。它仅仅与cache丢失的请求有关。第一个token指示如何选择下一跳，第二个token是下一跳的地址。对端编码列在13.2.3节里。
当squid发送一个请求到邻居cache时，对端主机地址是邻居的主机名。假如请求是直接送到原始服务器的，则squid会写成原始服务器的IP地址或主机名--假如禁用了log_ip_on_direct。NONE/-这个值指明squid不转发该请求到任何其他服务器。
10).内容类型
原始access.log的默认的最后一个域，是HTTP响应的内容类型。squid从响应的Content-Type头部获取内容类型值。假如该头部丢失了，squid使用一个横杠(-)代替。
假如激活了log_mime_headers指令，squid在每行追加2个附加的域：
11).HTTP请求头部
Squid编码HTTP请求头部，并且在一对方括号之间打印它们。方括号是必须的，因为squid不编码空格字符。编码方案稍许奇怪。回车（ASCII 13）和换行（ASCII 10）分别打印成\r和\n。其他不可打印的字符以RFC 1738风格来编码，例如Tab（ASCII 9）变成了%09。
12).HTTP响应头部
Squid编码HTTP响应头部，并且在一对方括号之间打印它们。注意这些是发往客户端的头部，可能不同于从原始服务器接受到的头部。
Squid只有在整个响应发送到客户端完成以后，才写access.log日志。这点允许squid在日志文件里包含请求和响应两者信息。然而，需要花费数分钟甚至数小时才能完成的事务，请求期间的日志在access.log里不可见。当这类型的事务呈现出性能或策略问题时，access.log可能对你没有帮助。代替的，可使用cache管理器来浏览挂起事务的列表