Apche日志分析
本文转载自http://www.cnblogs.com/xiaochaohuashengmi/archive/2011/04/24/2026559.html
本文分五个部分：访问日志、错误日志、定制日志、日志分析、其他用法。摘自 永远的Linux，做了一些修整。
Apche日志系列(1)：访问日志
想要知道什么人在什么时候浏览了网站的哪些内容吗？查看Apache的访问日志就可以知道。访问日志是Apache的标准日志，本文详细解释了访问日志的内容以及相关选项的配置。
一、访问日志的格式
Apache内建了记录服务器活动的功能，这就是它的日志功能。这个文章介绍的就是Apache的访问日志、错误日志，以及如何分析日志数据，如何定制Apache日志，如何从日志数据生成统计报表等内容。
如 果Apache的安装方式是默认安装，服务器一运行就会有两个日志文件生成。这两个文件是access_log和error_log（在Win上是 access.log和error.log）。采用默认安装方式时，这些文件可以在/usr/local/apache/logs下找到；对于 Windows系统，这些日志文件将保存在Apache安装目录的logs子目录。不同的包管理器会把日志文件放到各种不同的位置，所以你可能需要找找其 他的地方，或者通过配置文件查看这些日志文件配置到了什么地方。 【总结】 访问日志和错误日志的 位置 和 名字 ：
Windows: \logs\access.log | error.log
Linux: /usr/local/apache/logs/access_log | error_log
正如其名字所示，访问日志access_log记录了所有对Web服务器的访问活动。下面是访问日志中一个典型的记录：
例子：216.35.116.91 - - [19/Aug/2000:14:47:37 -0400] "GET / HTTP/1.0" 200 654
【总结】：日志名字段所代表的内容： 1.远程主机、2.空白(E-mail)、3.空白(登录名)、4.请求时间、5.方法+资源+协议、6.状态代码、7.发送字节数
这行内容由7项构成，上面的例子中有两项空白，但整行内容仍旧分成了7项。
第 一项信息是远程主机的地址，即它表明访问网站的究竟是谁。在上面的例子中，访问网站的主机是216.35.116.91。随便说一句，这个地址属于一台名 为si3001.inktomi.com的机器（要找出这个信息，可以使用nslookup工具查找DNS），inktomi.com是一家制作Web搜 索软件的公司。可以看出，仅仅从日志记录的第一项出发，我们就可以得到有关访问者的不少信息。
默认情况下，第一项信息只是远程主机的IP地址，但我们可以要求Apache查出所有的主机名字，并在日志文件中用主机名字来替代IP地址。然而，这种做法通常不值得推荐，因为它将极大地影响服务器记录日志的速度，从而也就减低了整个网站的效率。另外，有许多工具能够将日志文件中的IP地址转换成主机名字，因此要求Apache记录主机名字替代IP地址是得不偿失的。
然而，如果确实有必要让Apache找出远程主机的名字，那么我们可以使用指令“HostNameLookups on”。
如果HostNameLookups设置成double而不是on，日志记录程序将对它找到的主机名字进行反向查找，验证该主机名字确实指向了原来出现的IP地址。默认情况下HostNameLookups设置为off。
上例日志记录中的第二项是空白，用一个“-”占位符替代。实际上绝大多数时候这一项都是如此。这个位置用于记录浏览者的标识，这不只是浏览者的登录名字，而是浏览者的email地址或者其他唯一标识符。 这个信息由identd返回，或者直接由浏览器返回。很早的时候，那时Netscape 0.9还占据着统治地位，这个位置往往记录着浏览者的email 地址。然而，由于有人用它来收集邮件地址和发送垃圾邮件，所以它未能保留多久，很久之前市场上几乎所有的浏览器就取消了这项功能。因此，到了今天，我们在 日志记录的第二项看到email地址的机会已经微乎其微了。
日志记录的第三项也是空白。这个位置用于记录浏览者进行身份验证时提供的名字。当然，如果网站的某些内容要求用户进行身份验证，那么这项信息是不会空白的。但是，对于大多数网站来说，日志文件的大多数记录中这一项仍旧是空白的。
日志记录的第四项是请求的时间。这个信息用方括号包围，而且采用所谓的“公共日志格式”或“标准英文格式”。因此，上例日志记录表示请求的时间是2000年8月19日星期三14:47:37。时间信息最后的“-0400”表示服务器所处时区位于UTC之前的4小时。
日志记录的第五项信息或许是整个日志记录中最有用的信息，它告诉我们服务器收到的是一个什么样的请求。该项信息的典型格式是“METHOD RESOURCE PROTOCOL”，即“方法 资源 协议”。
【总结】
METHOD: GET、POST、HEAD、……
RESOURCE: /、index.html、/default/index.php、……（请求的文件）
PROTOCOL: HTTP+版本号
在上例中，METHOD是GET，其他经常可能出现的METHOD还有POST和HEAD。此外还有不少可能出现的合法METHOD，但主要就是这三种。
RESOURCE是指浏览者向服务器请求的文档，或URL。在这个例子中，浏览者请求的是“/”，即网站的主页或根。大多数情况下，“/”指向DocumentRoot目录的index.html文档，但根据服务器配置的不同它也可能指向其他文件。
PROTOCOL 通常是HTTP，后面再加上版本号。版本号或者是1.0，或者是1.1，但出现1.0的时候比较多。我们知道，HTTP协议是Web得以工作的基 础，HTTP/1.0是HTTP协议的早期版本，而1.1是最近的版本。当前大多数Web客户程序仍使用1.0版本的HTTP协议。
日志记录的第六项信息是状态代码。它告诉我们请求是否成功，或者遇到了什么样的错误。大多数时候，这项值是200，它表示服务器已经成功地响应浏览器的请求，一切正常。状态代码的完整清单可以参考 维基百科中的HTTP状态码。一般地说，以2开头的状态代码表示成功，以3开头的状态代码表示由于各种不同的原因用户请求被重定向到了其他位置，以4开头的状态代码表示客户端存在某种错误，以5开头的状态代码表示服务器遇到了某个错误。
日志记录的第七项表示发送给客户端的总字节数。它告诉我们传输是否被打断（即，该数值是否和文件的大小相同）。把日志记录中的这些值加起来就可以得知服务器在一天、一周或者一月内发送了多少数据。
二、配置访问日志
访问日志文件的位置实际上是一个配置选项。如果我们检查httpd.conf配置文件，可以看到该文件中有如下这行内容：
CustomLog /usr/local/apache/logs/access_log common 注意，对于版本较早的Apache服务器，这行内容可能略有不同。它使用的可能不是CustomLog指令，而是TransferLog指令。如果你的服务器属于这类情况，建议你尽可能地早日升级服务器。
CustomLog指令指定了保存日志文件的具体位置以及日志的格式。上面这行指令指定的是common日志格式，自从有了Web服务器开始，common格式就是它的标准格式。由此我们也可以理解，虽然几乎不再有任何客户程序向服务器提供用户的标识信息，但访问日志却还保留着第二项内容。
CustomLog指令中的路径是日志文件的路径，由于日志文件是由HTTP用户打开的（用User指令指定），因此必须注意这个路径要有安全保证，防止该文件被随意改写。
Apche日志系列(2)：错误日志
错误日志和访问日志一样也是Apache的标准日志。本文分析错误日志的内容，介绍如何设置和错误日志相关的选项，文档错误和CGI错误的分类，以及如何方便地查看日志内容，等等。
一、文件名和位置
错误日志无论在格式上还是在内容上都和访问日志不同。然而，错误日志和访问日志一样也提供丰富的信息，我们可以利用这些信息分析服务器的运行情况、哪里出现了问题。 错误日志的文件名字是error_log（Windows平台是error.log）。错误日志的位置可以通过ErrorLog指令设置：
ErrorLog logs/error.log
除非文件位置用“/”开头，否则这个 文件位置是相对于ServerRoot目录的相对路径。 如果Apache采用默认安装方式安装，那么错误日志的位置应该在/usr/local/apache/logs下。但是，如果Apache用某种包管理 器安装，错误日志很可能在其他位置。 正如其名字所示，错误日志记录了服务器运行期间遇到的各种错误，以及一些普通的诊断信息，比如服务器何时启 动、何时关闭等。
我们可以设置日志文件记录信息级别的高低，控制日志文件记录信息的数量和类型。这是通过LogLevel指令设置的，该指令默认设置的级别是error，即记录称得上错误的事件。有关该指令中允许设置的各种选项的完整清单，请参见 http://www.apache.org/docs/mod/core.html#loglevel的Apache文档。
大多数情况下，我们在日志文件中见到的内容分属两类：文档错误和CGI错误。但是，错误日志中偶尔也会出现配置错误，另外还有前面提到的服务器启动和关闭信息。
二、文档错误
文档错误和服务器应答中的400系列代码相对应，最常见的就是404错误——Document Not Found（文档没有找到）。除了404错误以外，用户身份验证错误也是一种常见的错误。
404错误在用户请求的资源（即URL）不存在时出现，它可能是由于用户输入的URL错误，或者由于服务器上原来存在的文档因故被删除或移动。
顺便说一下，按照Jakob Nielson的意见， 在不提供重定向或者其他补救措施的情况下，我们永远不应该移动或者删除Web网站的任何资源。Nielson的更多文章，请参见 http://www.zdnet.com/devhead/alertbox/。 当用户不能打开服务器上的文档时，错误日志中出现的记录如下所示：
[Fri Aug 18 22:36:26 2000] [error] [client 192.168.1.6] File does not exist: /usr/local/apache/bugletdocs/Img/south-korea.gif 【说明】1.日期和时间、2.记录等级、3.客户IP、4.错误信息。
可以看到，正如访问日志access_log文件一样， 错误日志记录也分成多个项。 错误记录的开头是日期/时间标记，注意它们的格式和access_log中日期/时间的格式不同。access_log中的格式被称为“标准英文格式”，这或许是历史跟我们开的一个玩笑，但现在要改变它已经太迟了。
错误记录的第二项是当前记录的级别，它表明了问题的严重程度。这个级别信息可能是LogLevel指令的文档中所列出的任一级别（参见前面LogLevel的链接），error级别处于warn级别和crit级别之间。404属于error错误级别，这个级别表示确实遇到了问题，但服务器还可以运行。
错误记录的第三项表示用户发出请求时所用的IP地址。
记录的最后一项才是真正的错误信息。 对于404错误，它还给出了完整路径指示服务器试图访问的文件。当我们料想某个文件应该在目标位置却出现了404错误时，这个信息是非常有用的。此时产生 这种错误的原因往往是由于服务器配置错误、文件实际所处的虚拟主机和我们料想的不同，或者其他一些意料不到的情况。
由于用户身份验证问题而出现的错误记录如下所示：
[Tue Apr 11 22:13:21 2000] [error] [client 192.168.1.3] user rbowen＠rcbowen.com : authentication failure for "/cgi- bin/hirecareers/company.cgi" : password mismatch
注意，由于文档错误是用户请求的直接结果，因此它们在访问日志中也会有相应的记录。
三、CGI错误
错误日志最主要的用途或许是诊断行为异常的CGI程序。为了进一步分析和处理方便，CGI程序输出到STDERR（Standard Error，标准错误设备）的所有内容都将直接进入错误日志。这意味着，任何编写良好的CGI程序，如果出现了问题，错误日志就会告诉我们有关问题的详细信息。
然而，把CGI程序错误输出到错误日志也有它的缺点，错误日志中将出现许多没有标准格式的内容，这使得用错误日志自动分析程序从中分析出有用的信息变得相当困难。
下面是一个例子，它是调试Perl CGI代码时，错误日志中出现的一个错误记录：
[Wed Jun 14 16:16:37 2000] [error] [client 192.168.1.3] Premature
end of script headers: /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi
Global symbol "$rv" requires explicit package name at
/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 81.
Global symbol "�tails" requires explicit package name at
/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 84.
Global symbol "$Config" requires explicit package name at
/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 133.
Execution of /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi
aborted due to compilation errors. 可以看到，CGI错误和前面的404错误格式相同，包含日期/时间、错误级别以及客户地址、错误信息。但这个CGI错误的错误信息有好几行，这往往会干扰一些错误日志分析软件的工作。
有了这个错误信息，即使是对Perl不太熟悉的人也能够找出许多有关错误的信息，例如至少可以方便地得知是哪几行代码出现了问题。Perl在报告程序错误方面的机制是相当完善的。当然，不同的编程语言输出到错误日志的信息会有所不同。
由于CGI程序运行环境的特殊性，如果没有错误日志的帮助，大多数CGI程序的错误都将很难解决。
有 不少人在邮件列表或者新闻组中抱怨说自己有一个CGI程序，当打开网页时服务器却返回错误，比如“Internal Server Error”。我们可 以肯定，这些人还没有看过服务器的错误日志，或者根本不知道错误日志的存在。决多大多数情况下，错误日志能够精确地指出CGI错误的所在以及如何修正这个 错误。
四、查看日志文件
我常常告诉别人说，在进行开发的同时我会不断地检查服务器的日志，以便能够立即知道哪儿出了问题。但我得到的回答却往往是沉默。起先我以为这种沉默意味着“你当然得这样做”，后来我才发现这种沉默的真正含义是“我不知道别人的做法，但我自己是不干的。”
虽然如此，下面我们还是要看看如何方便地查看服务器日志文件。用telnet连接到服务器，然后输入下面的命令：
tail -f /usr/local/apache/logs/error_log //动态显示文件后几行内容 【补充】 tail命令是用来显示linux系统的文本文件的最后几行的工具。和 head命令正好相反。
该命令将显示出日志文件的最后几行内容，如果有新的内容加入到日志文件，它还会立即显示出新加入的内容。 Windows用户也同样可以使用这种方法，比如可以使用各种为Windows提供的Unix工具软件包。我个人爱好一个称为AINTX的工具，它可以在 http://maxx.mc.net/~jlh/nttools/index.htm找到。
还有一种替代方法是使用下面的Perl代码，它利用了一个称为File::Tail的模块：
use File::Tail;
$file=File::Tail->new("/some/log/file");
while (defined($line=$file->read)) {
print "$line";
}
无论具体采用的是哪一种方法，同时打开多个终端窗口都是一种好习惯：比如在一个窗口中显示错误日志，在另一个窗口中显示访问日志。这样，我们就能够随时获知网站上发生的事情并立即予以解决。
Apche日志系列(3)：定制日志
有时候我们需要定制Apache默认日志的格式和内容，比如增加或减少日志所记录的信息、改变默认日志文件的格式等。本文介绍可以用日志记录的所有信息，以及如何设置Apache使其记录这些信息。
一、定义日志格式
很 久以前，日志文件只有一种格式，这就是“公共格式”，许多人已经习惯于使用这种格式。随后出现了定制日志格式，而且看起来定制日志格式更很受欢迎，即使公 共日志格式本身也重新用定制日志格式定义。本文介绍的就是如何随心所欲地定制日志文件的格式、如何让日志文件记录自己想要的信息。
定制日志文件的格式涉及到两个指令，即LogFormat指令和CustomLog指令。默认httpd.conf文件提供了关于这两个指令的几个示例。
LogFormat指令：定义格式并为格式指定一个名字，以后我们就可以直接引用这个名字。
CustomLog指令：设置日志文件，并指明日志文件所用的格式（通常通过格式的名字）。
LogFormat指令的功能是定义日志格式并为它指定一个名字。例如，在默认的httpd.conf文件中，我们可以找到下面这行代码：
LogFormat "%h %l %u %t "%r" %>s %b" common
该指令创建了一种名为“common”的日志格式，日志的格式在双引号包围的内容中指定。格式字符串中的每一个变量代表着一项特定的信息，这些信息按照格式串规定的次序写入到日志文件。 Apache文档已经给出了所有可用于格式串的变量及其含义，下面是其译文：
%a: 远程IP地址
%A: 本地IP地址
%B: 已发送的字节数，不包含HTTP头
%b: CLF格式的已发送字节数量，不包含HTTP头。例如当没有发送数据时，写入‘-’而不是0。
%{FOOBAR}e: 环境变量FOOBAR的内容
%f: 文件名字
%h: 远程主机
%H 请求的协议
%Foobar}i: Foobar的内容，发送给服务器的请求的标头行。
%l: 远程登录名字（来自identd，如提供的话）
%m: 请求的方法
%{Foobar}n: 来自另外一个模块的注解“Foobar”的内容
%{Foobar}o: Foobar的内容，应答的标头行
%p: 服务器响应请求时使用的端口
%P: 响应请求的子进程ID。
%q: 查询字符串（如果存在查询字符串，则包含“?”后面的部分；否则，它是一个空字符串。）
%r: 请求的第一行
%s: 状态。对于进行内部重定向的请求，这是指*原来*请求的状态。如果用%...>s，则是指后来的请求。
%t: 以公共日志时间格式表示的时间（或称为标准英文格式）
%{format}t: 以指定格式format表示的时间
%T: 为响应请求而耗费的时间，以秒计
%u: 远程用户（来自auth；如果返回状态（%s）是401则可能是伪造的）
%U: 用户所请求的URL路径
%v: 响应请求的服务器的ServerName
%V: 依照UseCanonicalName设置得到的服务器名字
分析前面来自默认httpd.conf文件的LogFormat指令示例，可以看出它创建了一种名为“common”的日志格式，其中包括：远程主机，远程登录名字，远程用户，请求时间，请求的第一行代码，请求状态，以及发送的字节数。 LogFormat "%V %h %l %u %t "%r" %>s %b" common
【补充】"<"和">"修饰符可以用来指定对于已被内部重定向的请求是选择原始的请求还是选择最终的请求。默认情况下，%s, %U, %T, %D, %r 使用原始请求，而所有其他格式串则选择最终请求。例如， %>s 可以用于记录请求的最终状态，而 %
如果在“%”和变量之间放入了一个或者多个HTTP状态代码，则只有当请求返回的状态代码属于指定的状态代码之一时，变量所代表的内容才会被记录。例如，如果我们想要记录的是网站的所有无效链接，那么可以使用：
LogFormat @4{Referer}i BrokenLinks
反之，如果我们想要记录那些状态代码不等于指定值的请求，只需加入一个“!”符号即可：
LogFormat %!200U SomethingWrong
Apche日志系列(4)：日志分析
尽管日志文件中包含着大量有用的信息，但这些信息只有在经过深入挖掘之后才能够最大限度地发挥作用。本文首先讨论了能够从日志文件获得的信息以及不能从日志文件获得的信息，然后介绍了几种优秀的日志分析工具以及如何自己编程分析日志文件。
一、可以得到哪些信息(4月4日)
虽 然日志文件中包含了大量的信息，但这些信息对于我们管理、规划网站却没有多少直接的帮助。为了管理和规划网站，我们需要知道：有多少人浏览了网站，他们在 看些什么，停留了多长时间，他们从哪里得知这个网站，等等。所有这些信息就隐藏于（或者可能隐藏于）日志文件之中。
就网站的经营者而言， 他们还希望知道浏览者的姓名、地址、鞋子大小，甚至还有浏览者的信用卡号码，但这些信息都不可能从日志文件中得到。为此，作为技术人员的我们就必须知道如 何向这些经营者解释清楚：这部分信息不仅不可能从日志文件获得，而且要获得这些信息的唯一方法是直接向浏览者本人询问，并作好被拒绝的准备。
有许多信息可以用日志文件来记录，其中包括：
1.远程机器的地址：“远程机器的地址”和“谁在浏览网站”差不多，但并不等同。具体地说，远程机器的地址告诉我们浏览者来自何方，比如它可能是buglet.rcbowen.com或者proxy01.aol.com。
2.浏览时间：浏 览者何时开始访问网站？从这个问题的答案中我们能够了解不少情况。如果网站的大多数浏览者都在早上9:00和下午4:00之间访问网站，那么可以相信网站 的浏览者大多数总在工作时间进行访问；如果访问记录大多出现在下午7:00到午夜之间，我们可以肯定浏览者一般在家里上网。 当然，从单个访问记录能够得 到的信息非常有限，但如果从数千个访问记录出发，我们就可以得到非常有用和重要的统计信息。
3.用户所访问的资源：网 站的哪些部分最受用户欢迎？这些最受欢迎的部分就是我们应该继续加以发展的部分。网站的哪些部分总是受到冷落？网站中这些受到冷落的部分或许隐藏得太深， 或许它们确实没有什么意思，此时我们就得想办法加以改进。当然，网站还有的内容，比如法律上的声明，虽然很少有人访问，但却不应该随便地改动它们。
4.无效链接：当 然，日志文件还能够告诉我们哪些东西不能按照我们所想象地运行。网站中是否存在错误的链接？其他网站链接过来时有没有搞错URL？是否存在不能正常运行的 CGI程序？是否有搜索引擎检索程序每秒发出数千个请求，从而影响了本网站的正常服务？这些问题的答案都可以从日志文件找到线索。
Apche日志系列(5)：其他用法
这篇讨论三个问题：1.如何将日志记录写入指定的程序而不是日志文件，2.如何轮换日志防止磁盘空间不足，3.多虚拟主机环境下的日志文件管理。
一、把日志记录写入到指定程序
日志记录并非只能写入到文件，它还可以写入到指定的进程。当我们想要把日志信息写入数据库、或者是某些能够实时显示网站流量统计信息的程序时，这一点是非常有用的。 那么，如何实现这一点呢？使用TransferLog或者CustomLog指令，我们能够指定“|”，后面再加上接收日志信息的程序名字。例如：
CustomLog | /usr/bin/apachelog.pl common
其中/usr/bin/apachelog.pl是一个程序， 这个程序知道如何处理Apache日志文件的记录。事实上，这个程序非常简单，比如它可以是一个按照某种方式处理日志记录的Perl程序，或者是一个将日 志记录写入数据库的程序。 在采用这种记录日志数据的方法时，安全问题是最必须关注的问题。日志文件是以启动服务器的用户所具有的权限打开的，通常 是root。对于将日志记录写入数据库的程序，这一点也同样有效，所以应当确保用于记录日志数据的程序具有充分的安全保证。
如果日志数据 通过一个不安全的程序记录（这个程序可能被非root用户侵入和修改），那么系统就面临着日志记录程序被其他怀有恶意的程序替换的危险。例如，如果 /usr/bin/apachelog.pl可被全世界的用户修改，那么任何用户都将能够编辑这个文件关闭Web服务器，把密码文件发送到某个信箱，或者 删除某些重要的文件，因为root用户具有进行所有这些操作的权限。
如果你要把日志记录写入到某个程序，建议先找找是否有现成的具备自己想要功能的模块。请访问 http://modules.apache.org/，该网站收集了许多面向Apache完成各类实际任务的模块。
二、轮换日志
日志文件会越来越大，如果不小心把日志文件放到了/var之类位置，日志文件可能写满分区，从而导致服务器被迫停止运行。这种事情确实曾经发生过。
防 止出现这种问题的办法是，在日志文件变得太大之前把它们移到其他具有足够空间的位置。这可以通过几种方法实现。某些Unix变种提供一个 logrotate脚本，它能够帮助我们完成这个任务。例如RedHat就已经预先配置，它会根据日志文件的大小或者日志文件的使用时间，每隔几日轮换日 志文件。
如果要自己实现这方面的功能，我们可以使用称为Logfile::Rotate的Perl模块（可从CPAN下载）。下面的代码就具有这种功能，它由cron按照一定的间隔周期（比如一星期）运行，为了节省空间。每一个备份的日志文件都经过压缩。
use Logfile::Rotate;
$logfile = new Logfile::Rotate(
File => &single;/usr/local/apache/logs/access_log&single;,
Count => 5,
Gzip => &single;/bin/gzip&single;,
Signal => sub {
`/usr/local/apache/bin/apachectl restart`;
}
);
代码不多，Perl模块Logfile::Rotate负责了所有具体操作任务。运行这个程序，我们将得到名为access_log.1.gz、 access_log.2.gz等的文件。它可以帮助我们避免磁盘空间的不足，使得我们能够保存任意多的档案文件。
三、多个虚拟主机的日志
曾经有好几个人问起，当同一台机器上运行着多个虚拟主机时应该如何分析日志？我想，他们是先把所有虚拟主机的日志记录都保存到了同一台机器，然后又企图把这个日志文件按照虚拟主机的不同分割成多个部分。
彻底解决这个问题的方法是一开始就不要把所有虚拟主机的日志记录都写入到同一个文件。虽然我知道确实存在这样的工具，它们能够把多个虚拟主机混合的日志记录根据虚拟主机配置分开，指出哪些请求针对哪个虚拟主机发出，然后分别生成报表。然而，这种方法看起来实在是太麻烦了。
为每一个虚拟主机分别指定日志文件时，我们只需在每个VirtualHost区域指定该主机的日志文件。此后，当需要制作报表时，我们就可以分别地处理各个日志文件。
但 这里必须注意一下可用文件句柄的问题。也就是说，如果某台服务器上运行的虚拟主机多达数百个，每个虚拟主机都有单独的日志文件，系统可能会出现可用文件句 柄不足的问题，它可能导致系统不稳定甚至导致系统崩溃。然而，只有当服务器上运行的虚拟主机数量非常庞大时，我们才有关注这个问题的必要。
本文摘自 永远的unix(注意链接地址中的日期^_^)：
Apche日志系列(1)： 访问日志 http://fanqiang.chinaunix.net/a6/b1/20010516/11000199.html
Apche日志系列(2)： 错误日志 http://fanqiang.chinaunix.net/a6/b1/20010516/10080098.html
Apche日志系列(3)： 定制日志 http://fanqiang.chinaunix.net/a6/b1/20010516/09150097.html
Apche日志系列(4)： 日志分析 http://fanqiang.chinaunix.net/a6/b1/20010516/121001100.html Apche日志系列(5)： 高级技术 http://fanqiang.chinaunix.net/a6/b1/20010516/130400101.html
＜完＞
Apche日志系列(1)：访问日志
想要知道什么人在什么时候浏览了网站的哪些内容吗？查看Apache的访问日志就可以知道。访问日志是Apache的标准日志，本文详细解释了访问日志的内容以及相关选项的配置。
一、访问日志的格式
Apache内建了记录服务器活动的功能，这就是它的日志功能。这个文章介绍的就是Apache的访问日志、错误日志，以及如何分析日志数据，如何定制Apache日志，如何从日志数据生成统计报表等内容。
如 果Apache的安装方式是默认安装，服务器一运行就会有两个日志文件生成。这两个文件是access_log和error_log（在Win上是 access.log和error.log）。采用默认安装方式时，这些文件可以在/usr/local/apache/logs下找到；对于 Windows系统，这些日志文件将保存在Apache安装目录的logs子目录。不同的包管理器会把日志文件放到各种不同的位置，所以你可能需要找找其 他的地方，或者通过配置文件查看这些日志文件配置到了什么地方。 【总结】 访问日志和错误日志的 位置 和 名字 ：
Windows: \logs\access.log | error.log
Linux: /usr/local/apache/logs/access_log | error_log
正如其名字所示，访问日志access_log记录了所有对Web服务器的访问活动。下面是访问日志中一个典型的记录：
例子：216.35.116.91 - - [19/Aug/2000:14:47:37 -0400] "GET / HTTP/1.0" 200 654
【总结】：日志名字段所代表的内容： 1.远程主机、2.空白(E-mail)、3.空白(登录名)、4.请求时间、5.方法+资源+协议、6.状态代码、7.发送字节数
这行内容由7项构成，上面的例子中有两项空白，但整行内容仍旧分成了7项。
第 一项信息是远程主机的地址，即它表明访问网站的究竟是谁。在上面的例子中，访问网站的主机是216.35.116.91。随便说一句，这个地址属于一台名 为si3001.inktomi.com的机器（要找出这个信息，可以使用nslookup工具查找DNS），inktomi.com是一家制作Web搜 索软件的公司。可以看出，仅仅从日志记录的第一项出发，我们就可以得到有关访问者的不少信息。
默认情况下，第一项信息只是远程主机的IP地址，但我们可以要求Apache查出所有的主机名字，并在日志文件中用主机名字来替代IP地址。然而，这种做法通常不值得推荐，因为它将极大地影响服务器记录日志的速度，从而也就减低了整个网站的效率。另外，有许多工具能够将日志文件中的IP地址转换成主机名字，因此要求Apache记录主机名字替代IP地址是得不偿失的。
然而，如果确实有必要让Apache找出远程主机的名字，那么我们可以使用指令“HostNameLookups on”。
如果HostNameLookups设置成double而不是on，日志记录程序将对它找到的主机名字进行反向查找，验证该主机名字确实指向了原来出现的IP地址。默认情况下HostNameLookups设置为off。
上例日志记录中的第二项是空白，用一个“-”占位符替代。实际上绝大多数时候这一项都是如此。这个位置用于记录浏览者的标识，这不只是浏览者的登录名字，而是浏览者的email地址或者其他唯一标识符。 这个信息由identd返回，或者直接由浏览器返回。很早的时候，那时Netscape 0.9还占据着统治地位，这个位置往往记录着浏览者的email 地址。然而，由于有人用它来收集邮件地址和发送垃圾邮件，所以它未能保留多久，很久之前市场上几乎所有的浏览器就取消了这项功能。因此，到了今天，我们在 日志记录的第二项看到email地址的机会已经微乎其微了。
日志记录的第三项也是空白。这个位置用于记录浏览者进行身份验证时提供的名字。当然，如果网站的某些内容要求用户进行身份验证，那么这项信息是不会空白的。但是，对于大多数网站来说，日志文件的大多数记录中这一项仍旧是空白的。
日志记录的第四项是请求的时间。这个信息用方括号包围，而且采用所谓的“公共日志格式”或“标准英文格式”。因此，上例日志记录表示请求的时间是2000年8月19日星期三14:47:37。时间信息最后的“-0400”表示服务器所处时区位于UTC之前的4小时。
日志记录的第五项信息或许是整个日志记录中最有用的信息，它告诉我们服务器收到的是一个什么样的请求。该项信息的典型格式是“METHOD RESOURCE PROTOCOL”，即“方法 资源 协议”。
【总结】
METHOD: GET、POST、HEAD、……
RESOURCE: /、index.html、/default/index.php、……（请求的文件）
PROTOCOL: HTTP+版本号
在上例中，METHOD是GET，其他经常可能出现的METHOD还有POST和HEAD。此外还有不少可能出现的合法METHOD，但主要就是这三种。
RESOURCE是指浏览者向服务器请求的文档，或URL。在这个例子中，浏览者请求的是“/”，即网站的主页或根。大多数情况下，“/”指向DocumentRoot目录的index.html文档，但根据服务器配置的不同它也可能指向其他文件。
PROTOCOL 通常是HTTP，后面再加上版本号。版本号或者是1.0，或者是1.1，但出现1.0的时候比较多。我们知道，HTTP协议是Web得以工作的基 础，HTTP/1.0是HTTP协议的早期版本，而1.1是最近的版本。当前大多数Web客户程序仍使用1.0版本的HTTP协议。
日志记录的第六项信息是状态代码。它告诉我们请求是否成功，或者遇到了什么样的错误。大多数时候，这项值是200，它表示服务器已经成功地响应浏览器的请求，一切正常。状态代码的完整清单可以参考 维基百科中的HTTP状态码。一般地说，以2开头的状态代码表示成功，以3开头的状态代码表示由于各种不同的原因用户请求被重定向到了其他位置，以4开头的状态代码表示客户端存在某种错误，以5开头的状态代码表示服务器遇到了某个错误。
日志记录的第七项表示发送给客户端的总字节数。它告诉我们传输是否被打断（即，该数值是否和文件的大小相同）。把日志记录中的这些值加起来就可以得知服务器在一天、一周或者一月内发送了多少数据。
二、配置访问日志
访问日志文件的位置实际上是一个配置选项。如果我们检查httpd.conf配置文件，可以看到该文件中有如下这行内容：
CustomLog /usr/local/apache/logs/access_log common 注意，对于版本较早的Apache服务器，这行内容可能略有不同。它使用的可能不是CustomLog指令，而是TransferLog指令。如果你的服务器属于这类情况，建议你尽可能地早日升级服务器。
CustomLog指令指定了保存日志文件的具体位置以及日志的格式。上面这行指令指定的是common日志格式，自从有了Web服务器开始，common格式就是它的标准格式。由此我们也可以理解，虽然几乎不再有任何客户程序向服务器提供用户的标识信息，但访问日志却还保留着第二项内容。
CustomLog指令中的路径是日志文件的路径，由于日志文件是由HTTP用户打开的（用User指令指定），因此必须注意这个路径要有安全保证，防止该文件被随意改写。
Apche日志系列(2)：错误日志
错误日志和访问日志一样也是Apache的标准日志。本文分析错误日志的内容，介绍如何设置和错误日志相关的选项，文档错误和CGI错误的分类，以及如何方便地查看日志内容，等等。
一、文件名和位置
错误日志无论在格式上还是在内容上都和访问日志不同。然而，错误日志和访问日志一样也提供丰富的信息，我们可以利用这些信息分析服务器的运行情况、哪里出现了问题。 错误日志的文件名字是error_log（Windows平台是error.log）。错误日志的位置可以通过ErrorLog指令设置：
ErrorLog logs/error.log
除非文件位置用“/”开头，否则这个 文件位置是相对于ServerRoot目录的相对路径。 如果Apache采用默认安装方式安装，那么错误日志的位置应该在/usr/local/apache/logs下。但是，如果Apache用某种包管理 器安装，错误日志很可能在其他位置。 正如其名字所示，错误日志记录了服务器运行期间遇到的各种错误，以及一些普通的诊断信息，比如服务器何时启 动、何时关闭等。
我们可以设置日志文件记录信息级别的高低，控制日志文件记录信息的数量和类型。这是通过LogLevel指令设置的，该指令默认设置的级别是error，即记录称得上错误的事件。有关该指令中允许设置的各种选项的完整清单，请参见 http://www.apache.org/docs/mod/core.html#loglevel的Apache文档。
大多数情况下，我们在日志文件中见到的内容分属两类：文档错误和CGI错误。但是，错误日志中偶尔也会出现配置错误，另外还有前面提到的服务器启动和关闭信息。
二、文档错误
文档错误和服务器应答中的400系列代码相对应，最常见的就是404错误——Document Not Found（文档没有找到）。除了404错误以外，用户身份验证错误也是一种常见的错误。
404错误在用户请求的资源（即URL）不存在时出现，它可能是由于用户输入的URL错误，或者由于服务器上原来存在的文档因故被删除或移动。
顺便说一下，按照Jakob Nielson的意见， 在不提供重定向或者其他补救措施的情况下，我们永远不应该移动或者删除Web网站的任何资源。Nielson的更多文章，请参见 http://www.zdnet.com/devhead/alertbox/。 当用户不能打开服务器上的文档时，错误日志中出现的记录如下所示：
[Fri Aug 18 22:36:26 2000] [error] [client 192.168.1.6] File does not exist: /usr/local/apache/bugletdocs/Img/south-korea.gif 【说明】1.日期和时间、2.记录等级、3.客户IP、4.错误信息。
可以看到，正如访问日志access_log文件一样， 错误日志记录也分成多个项。 错误记录的开头是日期/时间标记，注意它们的格式和access_log中日期/时间的格式不同。access_log中的格式被称为“标准英文格式”，这或许是历史跟我们开的一个玩笑，但现在要改变它已经太迟了。
错误记录的第二项是当前记录的级别，它表明了问题的严重程度。这个级别信息可能是LogLevel指令的文档中所列出的任一级别（参见前面LogLevel的链接），error级别处于warn级别和crit级别之间。404属于error错误级别，这个级别表示确实遇到了问题，但服务器还可以运行。
错误记录的第三项表示用户发出请求时所用的IP地址。
记录的最后一项才是真正的错误信息。 对于404错误，它还给出了完整路径指示服务器试图访问的文件。当我们料想某个文件应该在目标位置却出现了404错误时，这个信息是非常有用的。此时产生 这种错误的原因往往是由于服务器配置错误、文件实际所处的虚拟主机和我们料想的不同，或者其他一些意料不到的情况。
由于用户身份验证问题而出现的错误记录如下所示：
[Tue Apr 11 22:13:21 2000] [error] [client 192.168.1.3] user rbowen＠rcbowen.com : authentication failure for "/cgi- bin/hirecareers/company.cgi" : password mismatch
注意，由于文档错误是用户请求的直接结果，因此它们在访问日志中也会有相应的记录。
三、CGI错误
错误日志最主要的用途或许是诊断行为异常的CGI程序。为了进一步分析和处理方便，CGI程序输出到STDERR（Standard Error，标准错误设备）的所有内容都将直接进入错误日志。这意味着，任何编写良好的CGI程序，如果出现了问题，错误日志就会告诉我们有关问题的详细信息。
然而，把CGI程序错误输出到错误日志也有它的缺点，错误日志中将出现许多没有标准格式的内容，这使得用错误日志自动分析程序从中分析出有用的信息变得相当困难。
下面是一个例子，它是调试Perl CGI代码时，错误日志中出现的一个错误记录：
[Wed Jun 14 16:16:37 2000] [error] [client 192.168.1.3] Premature
end of script headers: /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi
Global symbol "$rv" requires explicit package name at
/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 81.
Global symbol "�tails" requires explicit package name at
/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 84.
Global symbol "$Config" requires explicit package name at
/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 133.
Execution of /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi
aborted due to compilation errors. 可以看到，CGI错误和前面的404错误格式相同，包含日期/时间、错误级别以及客户地址、错误信息。但这个CGI错误的错误信息有好几行，这往往会干扰一些错误日志分析软件的工作。
有了这个错误信息，即使是对Perl不太熟悉的人也能够找出许多有关错误的信息，例如至少可以方便地得知是哪几行代码出现了问题。Perl在报告程序错误方面的机制是相当完善的。当然，不同的编程语言输出到错误日志的信息会有所不同。
由于CGI程序运行环境的特殊性，如果没有错误日志的帮助，大多数CGI程序的错误都将很难解决。
有 不少人在邮件列表或者新闻组中抱怨说自己有一个CGI程序，当打开网页时服务器却返回错误，比如“Internal Server Error”。我们可 以肯定，这些人还没有看过服务器的错误日志，或者根本不知道错误日志的存在。决多大多数情况下，错误日志能够精确地指出CGI错误的所在以及如何修正这个 错误。
四、查看日志文件
我常常告诉别人说，在进行开发的同时我会不断地检查服务器的日志，以便能够立即知道哪儿出了问题。但我得到的回答却往往是沉默。起先我以为这种沉默意味着“你当然得这样做”，后来我才发现这种沉默的真正含义是“我不知道别人的做法，但我自己是不干的。”
虽然如此，下面我们还是要看看如何方便地查看服务器日志文件。用telnet连接到服务器，然后输入下面的命令：
tail -f /usr/local/apache/logs/error_log //动态显示文件后几行内容 【补充】 tail命令是用来显示linux系统的文本文件的最后几行的工具。和 head命令正好相反。
该命令将显示出日志文件的最后几行内容，如果有新的内容加入到日志文件，它还会立即显示出新加入的内容。 Windows用户也同样可以使用这种方法，比如可以使用各种为Windows提供的Unix工具软件包。我个人爱好一个称为AINTX的工具，它可以在 http://maxx.mc.net/~jlh/nttools/index.htm找到。
还有一种替代方法是使用下面的Perl代码，它利用了一个称为File::Tail的模块：
use File::Tail;
$file=File::Tail->new("/some/log/file");
while (defined($line=$file->read)) {
print "$line";
}
无论具体采用的是哪一种方法，同时打开多个终端窗口都是一种好习惯：比如在一个窗口中显示错误日志，在另一个窗口中显示访问日志。这样，我们就能够随时获知网站上发生的事情并立即予以解决。
Apche日志系列(3)：定制日志
有时候我们需要定制Apache默认日志的格式和内容，比如增加或减少日志所记录的信息、改变默认日志文件的格式等。本文介绍可以用日志记录的所有信息，以及如何设置Apache使其记录这些信息。
一、定义日志格式
很 久以前，日志文件只有一种格式，这就是“公共格式”，许多人已经习惯于使用这种格式。随后出现了定制日志格式，而且看起来定制日志格式更很受欢迎，即使公 共日志格式本身也重新用定制日志格式定义。本文介绍的就是如何随心所欲地定制日志文件的格式、如何让日志文件记录自己想要的信息。
定制日志文件的格式涉及到两个指令，即LogFormat指令和CustomLog指令。默认httpd.conf文件提供了关于这两个指令的几个示例。
LogFormat指令：定义格式并为格式指定一个名字，以后我们就可以直接引用这个名字。
CustomLog指令：设置日志文件，并指明日志文件所用的格式（通常通过格式的名字）。
LogFormat指令的功能是定义日志格式并为它指定一个名字。例如，在默认的httpd.conf文件中，我们可以找到下面这行代码：
LogFormat "%h %l %u %t "%r" %>s %b" common
该指令创建了一种名为“common”的日志格式，日志的格式在双引号包围的内容中指定。格式字符串中的每一个变量代表着一项特定的信息，这些信息按照格式串规定的次序写入到日志文件。 Apache文档已经给出了所有可用于格式串的变量及其含义，下面是其译文：
%a: 远程IP地址
%A: 本地IP地址
%B: 已发送的字节数，不包含HTTP头
%b: CLF格式的已发送字节数量，不包含HTTP头。例如当没有发送数据时，写入‘-’而不是0。
%{FOOBAR}e: 环境变量FOOBAR的内容
%f: 文件名字
%h: 远程主机
%H 请求的协议
%Foobar}i: Foobar的内容，发送给服务器的请求的标头行。
%l: 远程登录名字（来自identd，如提供的话）
%m: 请求的方法
%{Foobar}n: 来自另外一个模块的注解“Foobar”的内容
%{Foobar}o: Foobar的内容，应答的标头行
%p: 服务器响应请求时使用的端口
%P: 响应请求的子进程ID。
%q: 查询字符串（如果存在查询字符串，则包含“?”后面的部分；否则，它是一个空字符串。）
%r: 请求的第一行
%s: 状态。对于进行内部重定向的请求，这是指*原来*请求的状态。如果用%...>s，则是指后来的请求。
%t: 以公共日志时间格式表示的时间（或称为标准英文格式）
%{format}t: 以指定格式format表示的时间
%T: 为响应请求而耗费的时间，以秒计
%u: 远程用户（来自auth；如果返回状态（%s）是401则可能是伪造的）
%U: 用户所请求的URL路径
%v: 响应请求的服务器的ServerName
%V: 依照UseCanonicalName设置得到的服务器名字
分析前面来自默认httpd.conf文件的LogFormat指令示例，可以看出它创建了一种名为“common”的日志格式，其中包括：远程主机，远程登录名字，远程用户，请求时间，请求的第一行代码，请求状态，以及发送的字节数。 LogFormat "%V %h %l %u %t "%r" %>s %b" common
【补充】"<"和">"修饰符可以用来指定对于已被内部重定向的请求是选择原始的请求还是选择最终的请求。默认情况下，%s, %U, %T, %D, %r 使用原始请求，而所有其他格式串则选择最终请求。例如， %>s 可以用于记录请求的最终状态，而 %
如果在“%”和变量之间放入了一个或者多个HTTP状态代码，则只有当请求返回的状态代码属于指定的状态代码之一时，变量所代表的内容才会被记录。例如，如果我们想要记录的是网站的所有无效链接，那么可以使用：
LogFormat @4{Referer}i BrokenLinks
反之，如果我们想要记录那些状态代码不等于指定值的请求，只需加入一个“!”符号即可：
LogFormat %!200U SomethingWrong
Apche日志系列(4)：日志分析
尽管日志文件中包含着大量有用的信息，但这些信息只有在经过深入挖掘之后才能够最大限度地发挥作用。本文首先讨论了能够从日志文件获得的信息以及不能从日志文件获得的信息，然后介绍了几种优秀的日志分析工具以及如何自己编程分析日志文件。
一、可以得到哪些信息(4月4日)
虽 然日志文件中包含了大量的信息，但这些信息对于我们管理、规划网站却没有多少直接的帮助。为了管理和规划网站，我们需要知道：有多少人浏览了网站，他们在 看些什么，停留了多长时间，他们从哪里得知这个网站，等等。所有这些信息就隐藏于（或者可能隐藏于）日志文件之中。
就网站的经营者而言， 他们还希望知道浏览者的姓名、地址、鞋子大小，甚至还有浏览者的信用卡号码，但这些信息都不可能从日志文件中得到。为此，作为技术人员的我们就必须知道如 何向这些经营者解释清楚：这部分信息不仅不可能从日志文件获得，而且要获得这些信息的唯一方法是直接向浏览者本人询问，并作好被拒绝的准备。
有许多信息可以用日志文件来记录，其中包括：
1.远程机器的地址：“远程机器的地址”和“谁在浏览网站”差不多，但并不等同。具体地说，远程机器的地址告诉我们浏览者来自何方，比如它可能是buglet.rcbowen.com或者proxy01.aol.com。
2.浏览时间：浏 览者何时开始访问网站？从这个问题的答案中我们能够了解不少情况。如果网站的大多数浏览者都在早上9:00和下午4:00之间访问网站，那么可以相信网站 的浏览者大多数总在工作时间进行访问；如果访问记录大多出现在下午7:00到午夜之间，我们可以肯定浏览者一般在家里上网。 当然，从单个访问记录能够得 到的信息非常有限，但如果从数千个访问记录出发，我们就可以得到非常有用和重要的统计信息。
3.用户所访问的资源：网 站的哪些部分最受用户欢迎？这些最受欢迎的部分就是我们应该继续加以发展的部分。网站的哪些部分总是受到冷落？网站中这些受到冷落的部分或许隐藏得太深， 或许它们确实没有什么意思，此时我们就得想办法加以改进。当然，网站还有的内容，比如法律上的声明，虽然很少有人访问，但却不应该随便地改动它们。
4.无效链接：当 然，日志文件还能够告诉我们哪些东西不能按照我们所想象地运行。网站中是否存在错误的链接？其他网站链接过来时有没有搞错URL？是否存在不能正常运行的 CGI程序？是否有搜索引擎检索程序每秒发出数千个请求，从而影响了本网站的正常服务？这些问题的答案都可以从日志文件找到线索。
Apche日志系列(5)：其他用法
这篇讨论三个问题：1.如何将日志记录写入指定的程序而不是日志文件，2.如何轮换日志防止磁盘空间不足，3.多虚拟主机环境下的日志文件管理。
一、把日志记录写入到指定程序
日志记录并非只能写入到文件，它还可以写入到指定的进程。当我们想要把日志信息写入数据库、或者是某些能够实时显示网站流量统计信息的程序时，这一点是非常有用的。 那么，如何实现这一点呢？使用TransferLog或者CustomLog指令，我们能够指定“|”，后面再加上接收日志信息的程序名字。例如：
CustomLog | /usr/bin/apachelog.pl common
其中/usr/bin/apachelog.pl是一个程序， 这个程序知道如何处理Apache日志文件的记录。事实上，这个程序非常简单，比如它可以是一个按照某种方式处理日志记录的Perl程序，或者是一个将日 志记录写入数据库的程序。 在采用这种记录日志数据的方法时，安全问题是最必须关注的问题。日志文件是以启动服务器的用户所具有的权限打开的，通常 是root。对于将日志记录写入数据库的程序，这一点也同样有效，所以应当确保用于记录日志数据的程序具有充分的安全保证。
如果日志数据 通过一个不安全的程序记录（这个程序可能被非root用户侵入和修改），那么系统就面临着日志记录程序被其他怀有恶意的程序替换的危险。例如，如果 /usr/bin/apachelog.pl可被全世界的用户修改，那么任何用户都将能够编辑这个文件关闭Web服务器，把密码文件发送到某个信箱，或者 删除某些重要的文件，因为root用户具有进行所有这些操作的权限。
如果你要把日志记录写入到某个程序，建议先找找是否有现成的具备自己想要功能的模块。请访问 http://modules.apache.org/，该网站收集了许多面向Apache完成各类实际任务的模块。
二、轮换日志
日志文件会越来越大，如果不小心把日志文件放到了/var之类位置，日志文件可能写满分区，从而导致服务器被迫停止运行。这种事情确实曾经发生过。
防 止出现这种问题的办法是，在日志文件变得太大之前把它们移到其他具有足够空间的位置。这可以通过几种方法实现。某些Unix变种提供一个 logrotate脚本，它能够帮助我们完成这个任务。例如RedHat就已经预先配置，它会根据日志文件的大小或者日志文件的使用时间，每隔几日轮换日 志文件。
如果要自己实现这方面的功能，我们可以使用称为Logfile::Rotate的Perl模块（可从CPAN下载）。下面的代码就具有这种功能，它由cron按照一定的间隔周期（比如一星期）运行，为了节省空间。每一个备份的日志文件都经过压缩。
use Logfile::Rotate;
$logfile = new Logfile::Rotate(
File => &single;/usr/local/apache/logs/access_log&single;,
Count => 5,
Gzip => &single;/bin/gzip&single;,
Signal => sub {
`/usr/local/apache/bin/apachectl restart`;
}
);
代码不多，Perl模块Logfile::Rotate负责了所有具体操作任务。运行这个程序，我们将得到名为access_log.1.gz、 access_log.2.gz等的文件。它可以帮助我们避免磁盘空间的不足，使得我们能够保存任意多的档案文件。
三、多个虚拟主机的日志
曾经有好几个人问起，当同一台机器上运行着多个虚拟主机时应该如何分析日志？我想，他们是先把所有虚拟主机的日志记录都保存到了同一台机器，然后又企图把这个日志文件按照虚拟主机的不同分割成多个部分。
彻底解决这个问题的方法是一开始就不要把所有虚拟主机的日志记录都写入到同一个文件。虽然我知道确实存在这样的工具，它们能够把多个虚拟主机混合的日志记录根据虚拟主机配置分开，指出哪些请求针对哪个虚拟主机发出，然后分别生成报表。然而，这种方法看起来实在是太麻烦了。
为每一个虚拟主机分别指定日志文件时，我们只需在每个VirtualHost区域指定该主机的日志文件。此后，当需要制作报表时，我们就可以分别地处理各个日志文件。
但 这里必须注意一下可用文件句柄的问题。也就是说，如果某台服务器上运行的虚拟主机多达数百个，每个虚拟主机都有单独的日志文件，系统可能会出现可用文件句 柄不足的问题，它可能导致系统不稳定甚至导致系统崩溃。然而，只有当服务器上运行的虚拟主机数量非常庞大时，我们才有关注这个问题的必要。
本文摘自 永远的unix(注意链接地址中的日期^_^)：
Apche日志系列(1)： 访问日志 http://fanqiang.chinaunix.net/a6/b1/20010516/11000199.html
Apche日志系列(2)： 错误日志 http://fanqiang.chinaunix.net/a6/b1/20010516/10080098.html
Apche日志系列(3)： 定制日志 http://fanqiang.chinaunix.net/a6/b1/20010516/09150097.html
Apche日志系列(4)： 日志分析 http://fanqiang.chinaunix.net/a6/b1/20010516/121001100.html Apche日志系列(5)： 高级技术 http://fanqiang.chinaunix.net/a6/b1/20010516/130400101.html
＜完＞
摘自：http://containerbag.blog.163.com/blog/static/1638961022010411102536581/
本文转自;http://www.cnblogs.com/xiaochaohuashengmi/archive/2011/04/24/2026559.html