应朋友们的要求，我还是写一篇关于服务器网站日志分析的原理及优缺点是什么。请朋友们注意，网站服务器日志法并不容易进行，初学者，以及在绝大多数情况下，进行以用户行为分析为核心的网站分析，用不到服务器日志法。不过，作为网站分析历史不可分割的一部分以及重要的基础篇章，服务器日志法仍然值得一书。下面的这篇文章也是我要撰写的书中截取的内容(我要快马加鞭快快写了，已经辜负了太多朋友的重托，抱歉抱歉!)。

　　【正文】

　　网站分析收集数据的方式其实有五、六种之多，我们最常见的有三种，分别是：服务器日志(Server Log)、页面标记(Page Tag)和客户端监测软件收集(Client End/Desktop)。

　　一. 服务器日志是什么

　　真正意义上的网站分析是从服务器日志开始的，而且直到今天，分析服务器(也称为server log file，或简称log file)日志仍然是网站分析的重要方法。

　　这里的服务器指的是网站服务器(Web Server)，而服务器日志跟飞机的黑匣子一样，是用来记录网站服务器的运行信息的，或者简单说，是用来记录服务器中的什么页面在什么时候被谁访问了。例如，如果你访问一次建站学网站：http://www.jzxue.com，那么一般情况下，网站服务器的日志就会记录在某时某刻来自某个IP的访问者索引了网页“/index.html”。当然，网站服务器日志还会记录其他许多内容，这些内容能够帮助我们分析网站的流量和访问者在网站上的行为。

　　下面这个图说明了网站日志是如何产生的。当用户访问一个网站的时候，事实上是访问这个网站的某一个具体的页面，我们假设这个页面叫Page 1。这时，我们的这个访问行为会请求服务器中Page 1的实际的文件，随之把这个文件下载到浏览器上。由于请求和下载行为都会引起服务器的响应和相应的行动，因此就有必要记录下服务器的这些行动。

　　你会问，为什么需要记录服务器的行动呢?原因很简单，因为我们不想让这个服务器变成“哈尔9000”(哈尔9000是库布里克《2001太空奥德赛》里面有了自我意识的电脑，它直接威胁到了电影中的宇航员)啊!这当然只是开玩笑，不过目的并无差别，就是能够通过服务器日志，对服务器的运行历史进行记录，这样当有任何异常情况发生的时候，我们都能够通过日志探寻问题发生的原因——跟记录飞机运行状态的黑匣子的作用十分类似。

　　原理看起来并不复杂，不过log file实际上并不简单。为了让log file具有可读性，log file并不可以按照各个网站所有者的喜好随意记录的，而是有自己的规范。W3C组织定义了server log file的通用格式(如果你有兴趣，可以在这里看看这些格式都是如何定义的：http://www.w3.org/Daemon/User/Config/Logging.html#common_logfile_format)，而其他一些组织或者个人又根据自己的需要额外扩展了这个格式，使log file能够比较全面地记录网站服务器进行的各种活动。

　　一条标准的web server log记录通常包含如下信息：

　　l 远程主机(Remote Host)的IP地址/名字

l 登录名(Log Name)

　　l 登录全名(Full Name)

　　l 请求发生的日期(Date)

　　l 请求发生的时间(Time)

　　l 和标准格林威治时间的差值(GMT Offset)

　　l 请求的方法(Request Method)

　　l 请求的文件的地址(File)

　　l 请求遵守的协议(Protocol)

　　l 请求的状态(Status)

　　l 被请求文档的长度(Length)

　　下面是一条标准的log file记录：

　　202.71.113.38 – - [03/Jan/2010:01:56:12 +0800] “GET /Chinawebanalytics/Sidney.htm HTTP/1.0” 200 5122

　　从左到右，202.71.113.38就是远程主机的IP;而登录名和登录全名指的是发起这个请求的用户的名字，这个一般大家当然是不想要透露的了，所以远程主机会禁止给出这两个信息，log file当然就记录不下来了，用两个短中划线代替。然后，03/Jan/2010是请求发生的日期，01:56:12则是时间，之后的+0800是指比格林威治时间要晚8个小时，就是我们北京时间了。再之后的GET是请求的方法，另一种方法是POST，可以简单理解为GET就是索取，POST就是提交。接着：/Chinawebanalytics/Sidney.htm是被请求文件的地址，可以是绝对地址也可以是相对地址。HTTP/1.0是请求所遵守的协议，这里的协议是HTTP 1.0。整个记录的结尾是两个数字，其中200表示一种请求的状态，意思是请求一切正常。有时候这个数字会显示为404，相信大家一看到这个数字就头痛，它表示请求的文件无法找到(file not found);又有时候，这个数字会显示为301，表示页面被重新定向到了别的地址。最后的一个数字5593，表示所请求的文档的长度为5122 bytes。

　　通用格式其实很简单，但是里面的这11类记录往往不足够帮助我们进行更深入的分析，因此其他的一些记录被加入进来，其中最重要的一些是：

　　l 请求来源(Referrer)：指连接到被请求资源的网站的URL。如果请求时通过点击一个链接时发生，那么这个项目就会被记录;

　　l 客户端(User Agent)：记录用户的浏览器或者发出请求的程序的相关信息;

　　l 所需时间(Time Taken)：从请求的发出到请求的资源全部传输完毕所需花费的时间;

　　l Cookie。

　　看起来，网站服务器日志所记录的内容是很有限的，比起我们动辄上万行的编程实在是九牛一毛。但是，千万别认为网站服务器日志文件会很小，对于一些大网站，每分每秒都有很多访问者对网站服务器进行请求，所以日志文件会积少成多，成为巨型的数据文件。有时候，一个小时的记录就能超过数G。什么，你网站的服务器日志一个月才1M?要加油啊，没有人气的网站可没有生命力。

　　讲到这儿，该说说历史了。网站分析就是从网站服务器日志开始的，或者更准确的说，网站服务器日志自诞生之日起，就是为网站分析所用的。最早，人们可是把所有的记录都拿出来，然后导入到数据软件中去进行分析，辛苦程度自不用说;但这个痛苦的阶段不会持续太久，哪儿有痛苦，哪儿就有生意，所以网站日志分析软件就出现了，解决了很大的问题，以至于大小互联网服务提供商(ISP)们都为租用他们空间的用户提供一款免费的网站日志分析软件。尽管如此，分析网站日志一直都是一个相当不容易的事情，所以，人们不得不寻找一些更便利的方法，这样便发明了网站分析的新的数据获取方法，这是后话了。

　　如果你问我什么情况下选择用网站服务器日志来进行网站分析，我建议你如非必须，那么还是寻找一些更容易的方法能够事半功倍。看看后面的内容，你就能知道我为什么这么说。

　　二. 用网站服务器日志进行网站分析的优点

　　尽管是个技术活，但是利用网站服务器日志进行网站分析还是有不少好处的。

　　1. 网站服务器的日志是被你完全掌控的数据。

　　所谓放在自己手心最放心，这些日志在你的服务器中，如果不是黑客入侵，数据不可能被你不希望的人获取。而且，只要你不删除，它们永远都在那里，在任何时候你都可以回溯历史数据，无论这些数据有多么久远。有朝一日，你的网站大获成功，这些日志也是一份奋斗历史的见证。

　　2. 能够记录机器人/自动程序对网站的访问。

　　其次，前面讲过，网站服务器的日志是记录网站服务器行为的，因此任何服务器响应的请求都会被记录下来。这些响应可能是应答用户发出的请求，也完全可能是应答一些互联网上自动程序发出的请求。最常见的一种互联网上的自动程序是搜索引擎的机器人，例如Google的Googlebot，这意味着网站服务器日志能够用来分析搜索引擎的访问，并帮助我们优化搜索引擎对网站的访问。讲到这里，请大家注意，并不是每一种网站分析方法都能做到这一点，我们最常用的为网站页面加入标签的方法是不能获取搜索引擎流量的。

　　3. 终端无关

　　网站服务器的日志能够记录网站服务器全部响应行为的特点还延伸出另外一个优点，那就是无论是何种终端访问服务器，都能把相关数据记录下来。现在，能够访问网站的终端越来越多了，我无聊的时候也试着用Sony的PSP上网，用手机的GPRS也能轻松的浏览网页，这些形形色色的终端的访问，服务器日志都会忠实的记录，但页面加入标签的方法就可能完全行不通。

　　4. 能够探知文件是否完全下载

　　日志方法的另一个好处是能够记录文件下载的情况。如果你在网上下载一个MP3音乐，你在发出这个响应的时候，日志会记录一个状态;你在下载完全的时候，日志照样会记录一个状态;如果你没有下载完全，日志还是会记录下来。这个，我想对那些提供下载服务的网站很有用。

　　5. 数据获取不依赖于第三方

　　通过日志获取数据本身不需要额外的第三方的帮助。只要你的服务器在运转，日志就会源源不断的被创建、保存。不过，请注意，这里我所指的是数据的获取不需要额外的支持，但是数据的分析一般而言，还是需要第三方的帮助的。直接去用肉眼读日志文件中的数据进行分析是不可想象的。

　　6. 不怕防火墙

　　最后，日志方法不惧怕防火墙或客户端安全软件的屏蔽，因为数据都是从服务器端获取的。

　　看起来似乎不错，不过凡事有利有弊，日志方法也肯定有它不能克服的不足。

　　三. 用网站服务器日志方法进行网站分析的缺点

　　日志方法能够起到作用的前提是服务器要响应来自客户端的请求，如果客户端的请求不通过服务器就得到了响应(这其实是经常发生的)，那么服务器日志法就无能为力了。