日志在计算机系统中是一个非常广泛的概念,任何程序都有可能输出日志:操作系统内核、各种应用服务器等等。日志的内容、规模和用途也各不相同,很难一概而论。
本文讨论的日志处理方法中的日志,仅指Web日志。其实并没有精确的定义,可能包括但不限于各种前端Web服务器——apache、lighttpd、tomcat等产生的用户访问日志,以及各种Web应用程序自己输出的日志。
在Web日志中,每条日志通常代表着用户的一次访问行为,例如下面就是一条典型的apache日志:
211.87.152.44 – - [18/Mar/2005:12:21:42 +0800] “GET / HTTP/1.1″ 200 899 “” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon)”
从上面这条日志中,我们可以得到很多有用的信息,例如访问者的IP、访问的时间、访问的目标网页、来源的地址以及访问者所使用的客户端的UserAgent信息等。如果需要更多的信息,则要用其它手段去获取:例如想得到用户屏幕的分辨率,一般需要使用js代码单独发送请求;而如果想得到诸如用户访问的具体新闻标题等信息,则可能需要Web应用程序在自己的代码里输出。
为什么要分析日志
毫无疑问,Web日志中包含了大量人们——主要是产品分析人员会感兴趣的信息,最简单的,我们可以从中获取网站每类页面的PV值(PageView,页面访问量)、独立IP数(即去重之后的IP数量)等;稍微复杂一些的,可以计算得出用户所检索的关键词排行榜、用户停留时间最高的页面等;更复杂的,构建广告点击模型、分析用户行为特征等等。
既然这些数据是如此的有用,那么当然已经有无数现成的工具可以帮助我们来分析它们,例如awstats、Webalizer,都是专门用于统计分析Web服务器日志的免费程序。
另外还有一类产品,它们不分析直接日志,而是通过让用户在页面中嵌入js代码的方式来直接进行数据统计,或者说我们可以认为它是直接让日志输出到了它们的服务器。典型的代表产品——大名鼎鼎的Google Analytics,另外还有国内的cnzz、百度统计等。
很多人可能会说,既然如此,我们为什么还需要自己来分析日志,有必要吗?当然有。我们的用户(产品分析人员)需求是无穷尽的,上面说的这几类工具虽然很好很强大,但显然没办法满足全部的需求。
无论是本地分析的工具,还是在线的分析服务,它们虽然提很丰富的的统计分析功能,可以做一定程度的配置,但是依然很有限的。要进行稍复杂点的分析,或者要做基于日志的数据挖掘,依然需要自己来完成。
另外绝大多数日志分析工具都是只能用于单机的,数据量稍大就没辙了。同时那些提供在线分析的服务对于单个站点通常也都有最大流量的限制——这是很容易理解的,他们也需要考虑服务器的负载。
所以,很多时候还是得靠自己。
怎么进行日志分析
这并不是一个简单的问题。即使我们把“日志”限定为Web日志,依然包含了成千上万种可能的格式和数据,而是“分析”更是难以定义,也许是简单的统计值的计算,也许是复杂的数据挖掘算法。
下面并不打算讨论这些复杂的问题,而只是笼统的讨论如何构建进行日志分析工作的基础。有了这些基础会让基于日志的简单统计分析变得很简单,并让复杂的分析挖掘等变得可行。
少量数据的情况
先考虑最简单的情况,在数据规模比较小的时候,也许是几十MB、几百MB或者几十GB,总之就是在单机处理尚能忍受的时候。一切都很好办,现成的各种Unix/Linux工具——awk、grep、sort、join等都是日志分析的利器,如果仅仅是想知道某个页面的PV,一个wc+grep就能搞定。如果有稍复杂的逻辑,那就使用各种脚本语言,尤其是perl,配合伟大的正则表达式,基本就可以解决所有的问题。
例如,我们想从上面提到的apache日志中得到访问量最高前100个IP,实现很简单:
cat logfile | awk ‘{a[$1]++} END {for(b in a) print b”\t”a[b]}’|sort -k2 -r|head -n 100
不过当我们需要频繁去分析日志的时候,上面的做法在一段时间之后可能就会让我们头疼如何进行各种日志文件、用于分析的脚本文件、crontab文件等等的维护,并且可能会存在大量重复的代码来做数据格式的解析和清洗,这个时候也许就需要更合适的东西,比如——数据库。
文章评论 本文章有个评论