13.1 cache.logcache.log包含多种消息,例如Squid的配置信息、性能警告、以及严重错误。如下是cache.log的输出样本: 2003/09/29 12:09:45| Starting Squid Cache version 2.5.STABLE4 for i386- 每个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级别,以便其他人能更好的理解和修正你的问题。 13.1.1 debug级别debug_options指令控制cache.log的日志级别。默认值(ALL,1)通常是最佳选择。在更高级别上,不重要的消息会混淆视线。请参考16.2节关于debug_options指令的完整描述。 请注意最高级别的debug(9或10)会对每个请求产生数千行日志,快速消耗磁盘空间和显著影响squid的性能。 可以使用squid的-X命令行选项来对所有情形激活完整的debug。假如squid拒绝启动,并且squid.conf里的debug级别不足 以诊断问题时,该模式特别有用。这也是在配置文件解析器解析到debug_options指令之前,激活它的完整debug的好方法。在squid运行正 常时,请勿使用-X。 对运行的squid进程,可使用squid的-k debug命令行选项来立刻激活完整debug。这个命令是循环使用的:第一次调用打开完整debug,第二次调用则关闭它。请见第5章关于-k选项的通用讨论。 如前所述,完整debug会产生难以控制的日志增长。这会使squid和操作系统运行缓慢。在极端情形下,你会发现终端session在运行第一个 squid -k debug命令后,变得没有响应。在squid狂写日志的同时让操作无法进行,这情形并不好。如下技巧也许有用,它获取5秒钟的debug数据快照: % squid -k debug; sleep 5; squid -k debug 13.1.2 转发cache.log消息到系统日志为了让squid发送cache.log消息的拷贝到系统日志,请使用-s命令行选项。仅仅在debug级别0和1的消息会被转发。级别0的消息以 syslog级别LOG_WARNING记录,级别1的消息以syslog级别LOG_NOTICE记录。所有消息使用LOCAL4的syslog设备。 如下是配置syslogd的一个方法,以便这些消息能保存下来: local4.warning /var/log/squid.log 在维护多个squid主机时,使用syslog来记录cache.log特别方便。可以配置每个本地syslog进程,转发这些消息到中央日志主机,这样就可在一个地方统一浏览所有cache日志。例如,可在/etc/syslogd.conf里使用如下接口: local4.notice @192.168.45.1 13.1.3 dump cache.log消息到终端-d level命令行选项指示squid去dump cache.log消息到终端(例如stderr)。level参数指明dump出的消息的最大级别。注意你只会见到出现在cache.log里的消息, 它遵循于debug_options设置。例如,假如设置了debug_options ALL,1,然后运行squid -d2,你不会见到级别2的debug消息。 -d level和-N选项在debug squid问题或快速测试配置文件的改变时,特别有用。它们允许你容易启动squid和观察cache.log消息。在squid从crontab或类似 的设备启动时,该选项也有用,crontab会捕获squid的标准错误并将其报告回用户。例如,可能有如下crontab,它自动重配运行中的 squid进程: 15 */4 * * * /usr/local/squid/sbin/squid -d1 -k reconfigure 13.2 access.logSquid把关于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个域。如下是日志样本,长行分割并且缩进排版: 1066037222.011 126389 9.121.105.207 TCP_MISS/503 1055 如下是对每个域的详细解释: 1.时间戳 请求完成时间,以Unix纪元(UTC 1970-01-01 00:00:00)以来的秒数表示,它是毫秒级的。squid使用这种格式而不是人工可读的时间格式,是为了简化某些日志处理程序的工作。 可以使用一个简单的perl命令来转化Unix时间戳到本地时间,例如: perl -pe 's/^/d+/./d+/localtime(___FCKpd___6amp;)/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第13章 日志文件
最新推荐文章于 2020-07-14 16:08:54 发布
![](https://img-home.csdnimg.cn/images/20240711042549.png)
原贴: