rss· 投稿· 设为首页· 加入收藏· 繁體版
当前位置: 火魔网 » 应用技术 » Proxy服务器

squid 日志详解

更新: 2010-06-29字体: 【大 中 小】点击: 214

在squid中access访问日志最为重要，位于/var/log/squid/access.log，常用的记录格式如下例如:
1217559125.663     21 222.91.241.67 TCP_MEM_HIT/200 501 GET http://www.mytino.com/china/job_pop/marketplace_images/mp_listdivarr.gif - NONE/- image/gif
1217559124.993     17 59.92.59.232 TCP_IMS_HIT/304 274 GET http://www.mytino.com/images/attach_suc.gif - NONE/- image/gif
1217559125.629     94 222.91.241.67 TCP_MEM_HIT/200 501 GET http://www.mytino.com/china/job_pop/marketplace_images/mp_listdivarr.gif - NONE/- image/gif
1217559125.642     13 222.91.241.67 TCP_HIT/200 446 GET http://www.mytino.com/china/job_pop/marketplace_images/mp_listdivbg.gif - NONE/- image/gif

--------------------------------------------------------------------

access.log分析工具

access.log包含很多信息，远不止你简单的浏览该文件所见。为了完整的浏览，必须使用第三方的日志文件分析包。你可在Squid的web页面的链接里，找到它们的列表。或者直接访问：http://www.squid-cache.org/Scripts/.

最流行的工具之一是Calamaris -- 一个Perl脚本，解析日志文件并产生基于文本的或HTML的报告。它提供关于会话的详细分类包括请求方式、客户端IP地址、原始服务器域名、内容类型、文件名扩展、响应size、以及更多。Calamaris也报告ICP查询会话，甚至其他cache产品的日志分析。其站点是：.

Squeezer以及它的派生Squeezer2，是Squid专有的分析工具。它们提供许多统计，能帮助你了解Squid的性能，特别是在有邻居cache时。两者都产生HTML文件作为输出。squid-cache.org站点的Logfile Analysis页有这些程序的链接。

Webalyzer是另一个有用工具。它运行快速，并且产生带表格和柱形统计表的HTML页面。它原始是设计成分析原始服务器的访问日志的。尽管它能解析Squid的日志，但不会报告诸如命中率和响应时间的事件。它使用的某些条款不同于我的做法。例如，Webalyzer把任何请求叫做一个"命中"，这不同于cache命中。它也把"页面"和"文件"加以区别。更多信息请访问Webalyzer的主页：http://www.mrunix.net/webalyzer/.

13.3 store.log

store.log记录Squid关于存储或删除cache目标的决定。对每个存在cache里的目标、每个不可cache的目标、以及每个被轮换策略删除的目标，Squid都会创建相应的日志条目。该日志文件内容既包含了内存cache又包含了磁盘cache。

store.log提供了下述不能从access.log获取的内容：

  • 1）某个特定的响应是否被cache。
  • 2）cache目标的文件号。对UFS基础的存储机制，你可转换该文件号到路径名，并且检查cache文件的内容。
  • 3）响应的内容长度：包括Content-Length值和实际的body大小。
  • 4）Date, Last-Modified, 和Expires头部的值。
  • 5）响应的cache关键字（例如MD5哈希值）。

如你所见，这些都是相对低级的信息，在日常管理中可能用不上。除非你要做专业的分析，或打算debug某程序，否则store.log可有可无。可以如下来禁止它：


cache_store_log none

跟其他日志文件一样，Squid将最新的日志条目写到该文件的末尾。某个给定的URI可能出现在日志文件里多次。例如，它先被cache，然后删除，接着又cache住。仅仅最近来的日志条目才反映目标的当前值。


store.log是文本基础的，看起来如下：



1067299212.411 RELEASE -1 FFFFFFFF A5964B32245AC98592D83F9B6EA10B8D 206
    1067299212 1064287906 -1 application/octet-stream 6840/6840
    GET http://download.windowsupdate.com/msdownload/update/v3-19990518/cab...
1067299212.422 SWAPOUT 02 0005FD5F 6F34570785CACABC8DD01ABA5D73B392 200
    1067299210 1057899600 -1 image/gif 1125/1125
    GET http://forum.topsportsnet.com/shf./images/nav_members1.gif
1067299212.641 RELEASE -1 FFFFFFFF B0616CB4B7280F67672A40647DD08474 200
    1067299212 -1 -1 text/html -1/67191
    GET http://www.tlava.com/
1067299212.671 RELEASE -1 FFFFFFFF 5ECD93934257594825659B596D9444BC 200
    1067299023 1034873897 1067299023 image/jpeg 3386/3386
    GET http://ebiz0.ipixmedia.com/abc/ebiz/_EBIZ_3922eabf57d44e2a4c3e7cd234a...
1067299212.786 RELEASE -1 FFFFFFFF B388F7B766B307ADEC044A4099946A21 200
    1067297755 -1 -1 text/html -1/566
    GET http://www.evenflowrocks.com/pages/100303pic15.cfm
1067299212.837 RELEASE -1 FFFFFFFF ABC862C7107F3B7E9FC2D7CA01C8E6A1 304
    1067299212 -1 1067299212 unknown -1/0
    GET http://ebiz0.ipixmedia.com/abc/ebiz/_EBIZ_3922eabf57d44e2a4c3e7cd234a...
1067299212.859 RELEASE -1 FFFFFFFF 5ED2726D4A3AD83CACC8A01CFDD6082B 304
    1066940882 1065063803 -1 application/x-javascript -1/0
    GET http://www.bellsouth.com/scripts/header_footer.js

每个日志条目包含如下13个域：


    

  • 
1. 时间戳事件何时发生，表现为Unix纪元以来的秒数，它是毫秒级的。

    • 

  • 
2. 动作

    • 

  • 
cache目标发生的动作。该域有3个可能值：SWAPOUT，RELEASE，和SO_FAIL。

      

    • 
1）SWAPOUT在Squid成功的存储目标到磁盘时发生。某些目标例如那些消极cache的，仅保存在内存而不是磁盘，Squid不会在store.log里记录它们。

      • 

    • 
2）SO_FAIL表明Squid不能完整的存储目标到磁盘。多半意味着存储机制拒绝以写方式打开新的磁盘文件。

      • 

    • 
3）RELEASE在Squid从cache里删除目标，或首先就决定响应不可存储时发生。 

      • 

    

    • 

  • 
3. 目录号

    • 

  • 
目录号是十进制小数形式，它是个到cache目录的7位索引。对没有存储到磁盘的目标，该域包含-1值。

    • 

  • 
4. 文件号

    • 

  • 
文件号是25位的标识符，内在的被squid使用。它被写成8字符的十六进制号。对UFS基础的存储机制，有算法可以转换文件号到路径名（见13.3.1节）。没有存储到磁盘的目标，没有有效的文件号。对这些目标，该域的值是FFFFFFFF。仅仅在RELEASE和SO_FAIL情况下才会出现这个值。

    • 

  • 
5. cache关键字Squid使用MD5哈希值作为主要的索引来定位目标。该关键字基于请求方式、URI、和其他可能的信息计算得来。可以从cache关键字来查找store.log条目。然而请注意，目标的cache关键字可能改变。当Squid在access.log里记录TCP_REFRESH_MISS请求时，这点会发生。情况类似如下： 

    
1065837334.045 SWAPOUT ... 554BACBD2CB2A0C38FF9BF4B2239A9E5 ... http://blah
1066031047.925 RELEASE ... 92AE17121926106EB12FA8054064CABA ... http://blah
1066031048.074 SWAPOUT ... 554BACBD2CB2A0C38FF9BF4B2239A9E5 ... http://blah
发生了什么呢？该目标原本cache在某个关键字下（554B...）。一段时间后，Squid接受到对该目标的另一请求，并转发确认请求到原始服务器。当响应以新内容返回时，Squid改变旧目标的cache关键字（92AE...），以便它能授予新目标正确的关键字（554B...）。然后旧目标删除，新目标存储到磁盘。

    • 

  • 
6. 状态码

    • 

  • 
该域显示响应的HTTP状态码，跟access.log一样。表13.1是状态码列表。

    • 

  • 
7. 日期

    • 

  • 
HTTP响应的Date头部值，表现为Unix纪元以来的秒数。值-1表示Date头部不可解析，-2意味着头部完缺。

    • 

  • 
8. 最后修改时间

    • 

  • 
HTTP响应的Last-Modified头部值，表现为Unix纪元以来的秒数。值-1表示Last-Modified头部不可解析，-2意味着头部完缺。

    • 

  • 
9. 过期时间

    • 

  • 
HTTP响应的Expires头部值，表现为Unix纪元以来的秒数。值-1表示Expires头部不可解析，-2意味着头部完缺。

    • 

  • 
10. 内容类型

    • 

  • 
HTTP响应的Content-Type头部值，排除了任何media-type参数。假如Content-Type丢失了，Squid插入值unknown。

    • 

  • 
11. 内容长度/大小

    • 

  • 
该域包含2个数字，以斜杠分开。第一个是Content-Length头部值。-1表明Content-Length头部不存在。第二个是HTTP消息body的实际大小。你可使用这2个数字来部分的验证接受到的响应，并验证原始服务器是否不正确的计算了内容长度。大多数情形下，这2个数字相等。

    • 

  • 
12. 方式

    • 

  • 
请求目标的HTTP方式，跟access.log里的一样。

    • 

  • 
13. URI

    • 

  • 
最后一个域是请求URI，跟access.log里的一样。该域也有前述章节提到的空格问题。然而，这里不必为此担忧，因为你可安全的忽略任何多余的域。

    • 

  • 
对许多RELEASE的条目，在最后8个域出现的是疑问号(?)。这是因为这些域的大部分值来自squid称为MemObject的结构。该结构仅在目标已被接受时，或目标被完整存储在内存时，才会出现。Squid cache里的大部分目标没有MemObject结构，因为它们仅存在于磁盘。对这些情况，Squid在相应域放置一个疑问号。 

    • 


13.3.1 转换文件号到路径名

假如想要检查某个特定的cache文件，你可稍费工夫将文件号转换到路径名。另外目录号和L1和L2值也是必需的。在squid的源代码里，storeUfsDirFullPath( )函数做这个事情。可在src/fs/ufs/store_dir_ufs.c文件里找到它。如下短小的perl脚本模拟了当前算法：



#!/usr/bin/perl
$L1 = 16;
$L2 = 256;
while (<>) {
    $filn = hex(第13章 日志文件
13.1 cache.log

cache.log包含多种消息，例如Squid的配置信息、性能警告、以及严重错误。如下是cache.log的


输出样本：



2003/09/29 12:09:45| Starting Squid Cache version 2.5.STABLE4 for i386-
    
unknown-freebsd4.8...
    
2003/09/29 12:09:45| Process ID 18990
    
2003/09/29 12:09:45| With 1064 file descriptors available
    
2003/09/29 12:09:45| Performing DNS Tests...
    
2003/09/29 12:09:45| Successful DNS name lookup tests...
    
2003/09/29 12:09:45| DNS Socket created at 0.0.0.0, port 1154, FD 5
    
2003/09/29 12:09:45| Adding nameserver 24.221.192.5 from /etc/resolv.conf
    
2003/09/29 12:09:45| Adding nameserver 24.221.208.5 from /etc/resolv.conf
    
2003/09/29 12:09:45| helperOpenServers: Starting 5 'redirector.pl' processes
    
2003/09/29 12:09:45| Unlinkd pipe opened on FD 15
    
2003/09/29 12:09:45| Swap maxSize 10240 KB, estimated 787 objects
    
2003/09/29 12:09:45| Target number of buckets: 39
    
2003/09/29 12:09:45| Using 8192 Store buckets
    
2003/09/29 12:09:45| Max Mem  size: 8192 KB
    
2003/09/29 12:09:45| Max Swap size: 10240 KB
    
2003/09/29 12:09:45| Rebuilding storage in /usr/local/squid/var/cache (CLEAN)
    
2003/09/29 12:09:45| Using Least Load store dir selection
    
2003/09/29 12:09:45| Set Current Directory to /usr/local/squid/var/cache
    
2003/09/29 12:09:45| Loaded Icons.
    
2003/09/29 12:09:45| Accepting HTTP connections at 0.0.0.0, port 3128, FD 16.
    
2003/09/29 12:09:45| Accepting ICP messages at 0.0.0.0, port 3130, FD 17.
    
2003/09/29 12:09:45| WCCP Disabled.
    
2003/09/29 12:09:45| Ready to serve requests.

每个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
下面来看看意思
logformat squid  %ts.%03tu %6tr %>a %Ss/%03Hs %<st %rm %ru %un %Sh/%<A %mt


解释如下:
Seconds since epoch; subsecond time (milliseconds);  Response time (milliseconds); Client source IP address;  Squid request status (TCP_MISS etc); HTTP status code; Reply size including HTTP headers;  Request method (GET/POST etc) ; Request URL;  User name;  Squid hierarchy status (DEFAULT_PARENT etc);  Client FQDN;  MIME content type


squid的日志很重要。常常要了解的，其中最重要的就是命中率啦，不然反向代理做的用就不大。


#cat access.log|gawk ‘{print $4}’|sort|uniq -c|sort -nr


9568 TCP_IMS_HIT/304
6313 TCP_HIT/200
2133 TCP_MISS/200
1568 TCP_MISS/206
587 TCP_MEM_HIT/200
531 TCP_MISS/304
207 TCP_REFRESH_HIT/200
152 TCP_REFRESH_HIT/304
86 TCP_NEGATIVE_HIT/404
69 TCP_MISS/404
9 TCP_MISS/000
4 TCP_MISS/503
1 TCP_REFRESH_MISS/000
1 TCP_DENIED/400


可以使用上面的方法，大约的分析一下命令中比。什么意思就看下面的详解.


#cat /var/log/squid/access.log |grep TCP_MEM_HIT


如果看到很多的TCP_MEM_HIT ，这表明该文件是从内存缓存读取的，squid已经起作用了！你再用浏览器打开该文件，应该是快如闪电了。。呵呵，大功告成了！还有其他类型的HIT，如 TCP_HIT等等，这些是从磁盘读取的，我觉得加速的意义不大，只不过缓解了apache的压力而已。


相应于HTTP请求，下列标签可能出现在access.log文件的第四个域。


TCP_HIT


Squid发现请求资源的貌似新鲜的拷贝，并将其立即发送到客户端。


TCP_MISS


Squid没有请求资源的cache拷贝。


TCP_REFERSH_HIT


Squid发现请求资源的貌似陈旧的拷贝，并发送确认请求到原始服务器。原始服务器返回304（未修改）响应，指示squid的拷贝仍旧是新鲜的。


TCP_REF_FAIL_HIT


Squid发现请求资源的貌似陈旧的拷贝，并发送确认请求到原始服务器。然而，原始服务器响应失败，或者返回的响应Squid不能理解。在此情形下，squid发送现有cache拷贝（很可能是陈旧的）到客户端。


TCP_REFRESH_MISS


Squid发现请求资源的貌似陈旧的拷贝，并发送确认请求到原始服务器。原始服务器响应新的内容，指示这个cache拷贝确实是陈旧的。


TCP_CLIENT_REFRESH_MISS


Squid发现了请求资源的拷贝，但客户端的请求包含了Cache-Control: no-cache指令。Squid转发客户端的请求到原始服务器，强迫cache确认。


TCP_IMS_HIT


客户端发送确认请求，Squid发现更近来的、貌似新鲜的请求资源的拷贝。Squid发送更新的内容到客户端，而不联系原始服务器。

TCP_SWAPFAIL_MISS


Squid发现请求资源的有效拷贝，但从磁盘装载它失败。这时squid发送请求到原始服务器，就如同这是个cache丢失一样。


TCP_NEGATIVE_HIT


在对原始服务器的请求导致HTTP错误时，Squid也会cache这个响应。在短时间内对这些资源的重复请求，导致了否命中。 negative_ttl指令控制这些错误被cache的时间数量。请注意这些错误只在内存cache，不会写往磁盘。下列HTTP状态码可能导致否定 cache（也遵循于其他约束）： 204, 305, 400, 403, 404, 405, 414, 500, 501, 502, 503, 504。


TCP_MEM_HIT


Squid在内存cache里发现请求资源的有效拷贝，并将其立即发送到客户端。注意这点并非精确的呈现了所有从内存服务的响应。例如，某些cache在内存里，但要求确认的响应，会以TCP_REFRESH_HIT, TCP_REFRESH_MISS等形式记录。


TCP_DENIED


因为http_access或http_reply_access规则，客户端的请求被拒绝了。注意被http_access拒绝的请求在第9域的值是NONE/-，然而被http_reply_access拒绝的请求，在相应地方有一个有效值。


TCP_OFFLINE_HIT


当offline_mode激活时，Squid对任何cache响应返回cache命中，而不用考虑它的新鲜程度。


TCP_REDIRECT


重定向程序告诉Squid产生一个HTTP重定向到新的URI（见11.1节）。正常的，Squid不会记录这些重定向。假如要这样做，必须在编译squid前，手工定义LOG_TCP_REDIRECTS预处理指令。


NONE


无分类的结果用于特定错误，例如无效主机名。


相应于ICP查询，下列标签可能出现在access.log文件的第四域。


UDP_HIT


Squid在cache里发现请求资源的貌似新鲜的拷贝。


UDP_MISS


Squid没有在cache里发现请求资源的貌似新鲜的拷贝。假如同一目标通过HTTP请求，就可能是个cache丢失。请对比UDP_MISS_NOFETCH。


UDP_MISS_NOFETCH


跟UDP_MISS类似，不同的是这里也指示了Squid不愿去处理相应的HTTP请求。假如使用了-Y命令行选项，Squid在启动并编译其内存索引时，会返回这个标签而不是UDP_MISS。


UDP_DENIED


因为icp_access规则，ICP查询被拒绝。假如超过95%的到某客户端的ICP响应是UDP_DENIED，并且客户端数据库激活了（见附录A），Squid在1小时内，停止发送任何ICP响应到该客户端。若这点发生，你也可在cache.log里见到一个警告。


UDP_INVALID


Squid接受到无效查询（例如截断的消息、无效协议版本、URI里的空格等）。Squid发送UDP_INVALID响应到客户端。

   

   

    
    
   

            

    标签：
        squid
        日志
       

      
   
     

   

    
顶一下

    
(1)

   

   

    
踩一下

    
(0)

   

  
   

  

  
 

 
 

     

  

   
相关文章

   

    
   

  

 
  
  
   

  

   
最新文章

   

    
   

  

 
  
  
     

  

   
更多内容

   

    
   

  

 
   










 

  关于我们 | 免责条款 | 联系我们 | 广告服务 | 网站地图
 

 

 © 2006-2012 火魔网 Huomo.cn 做最棒的IT技术网站 沪ICP备10214240号
 - TOP -