竹磬网-邵珠庆の日记 生命只有一次,你可以用它来做些更多伟大的事情–Make the world a little better and easier


2812月/120

业界开源日志系统比较

发布在 邵珠庆

 

1. 背景介绍

许多公司的平台每天会产生大量的日志(一般为流式数据,如,搜索引擎的pv,查询等),处理这些日志需要特定的日志系统,一般而言,这些系统需要具有以下特征:

(1) 构建应用系统和分析系统的桥梁,并将它们之间的关联解耦;

(2) 支持近实时的在线分析系统和类似于Hadoop之类的离线分析系统;

(3) 具有高可扩展性。即:当数据量增加时,可以通过增加节点进行水平扩展。

本文从设计架构,负载均衡,可扩展性和容错性等方面对比了当今开源的日志系统,包括facebook的scribe,apache的chukwa,linkedin的kafka和cloudera的flume等。

2. FaceBook的Scribe

Scribe是facebook开源的日志收集系统,在facebook内部已经得到大量的应用。它能够从各种日志源上收集日志,存储到一个中央存储系统 (可以是NFS,分布式文件系统等)上,以便于进行集中统计分析处理。它为日志的“分布式收集,统一处理”提供了一个可扩展的,高容错的方案。

它最重要的特点是容错性好。当后端的存储系统crash时,scribe会将数据写到本地磁盘上,当存储系统恢复正常后,scribe将日志重新加载到存储系统中。

架构

scribe的架构比较简单,主要包括三部分,分别为scribe agent, scribe和存储系统。

(1) scribe agent

scribe agent实际上是一个thrift client。 向scribe发送数据的唯一方法是使用thrift client, scribe内部定义了一个thrift接口,用户使用该接口将数据发送给server。

(2) scribe

scribe接收到thrift client发送过来的数据,根据配置文件,将不同topic的数据发送给不同的对象。scribe提供了各种各样的store,如 file, HDFS等,scribe可将数据加载到这些store中。

(3) 存储系统

存储系统实际上就是scribe中的store,当前scribe支持非常多的store,包括file(文件),buffer(双层存储,一个主储存,一个副存储),network(另一个scribe服务器),bucket(包含多个 store,通过hash的将数据存到不同store中),null(忽略数据),thriftfile(写到一个Thrift TFileTransport文件中)和multi(把数据同时存放到不同store中)。

3. Apache的Chukwa

chukwa是一个非常新的开源项目,由于其属于hadoop系列产品,因而使用了很多hadoop的组件(用HDFS存储,用mapreduce处理数据),它提供了很多模块以支持hadoop集群日志分析。

需求:

(1) 灵活的,动态可控的数据源

(2) 高性能,高可扩展的存储系统

(3) 合适的框架,用于对收集到的大规模数据进行分析

架构

Chukwa中主要有3种角色,分别为:adaptor,agent,collector。

(1) Adaptor 数据源

可封装其他数据源,如file,unix命令行工具等

目前可用的数据源有:hadoop logs,应用程序度量数据,系统参数数据(如linux cpu使用流率)。

(2) HDFS 存储系统

Chukwa采用了HDFS作为存储系统。HDFS的设计初衷是支持大文件存储和小并发高速写的应用场景,而日志系统的特点恰好相反,它需支持高并发低速率的写和大量小文件的存储。需要注意的是,直接写到HDFS上的小文件是不可见的,直到关闭文件,另外,HDFS不支持文件重新打开。

(3) Collector和Agent

为了克服(2)中的问题,增加了agent和collector阶段。

Agent的作用:给adaptor提供各种服务,包括:启动和关闭adaptor,将数据通过HTTP传递给Collector;定期记录adaptor状态,以便crash后恢复。

Collector的作用:对多个数据源发过来的数据进行合并,然后加载到HDFS中;隐藏HDFS实现的细节,如,HDFS版本更换后,只需修改collector即可。

(4) Demux和achieving

直接支持利用MapReduce处理数据。它内置了两个mapreduce作业,分别用于获取data和将data转化为结构化的log。存储到data store(可以是数据库或者HDFS等)中。

4. LinkedIn的Kafka

Kafka是2010年12月份开源的项目,采用scala语言编写,使用了多种效率优化机制,整体架构比较新颖(push/pull),更适合异构集群。

设计目标:

(1) 数据在磁盘上的存取代价为O(1)

(2) 高吞吐率,在普通的服务器上每秒也能处理几十万条消息

(3) 分布式架构,能够对消息分区

(4) 支持将数据并行的加载到hadoop


架构

Kafka实际上是一个消息发布订阅系统。producer向某个topic发布消息,而consumer订阅某个topic的消息,进而一旦有新的关于某个topic的消息,broker会传递给订阅它的所有consumer。 在kafka中,消息是按topic组织的,而每个topic又会分为多个partition,这样便于管理数据和进行负载均衡。同时,它也使用了zookeeper进行负载均衡。

Kafka中主要有三种角色,分别为producer,broker和consumer。

(1) Producer

Producer的任务是向broker发送数据。Kafka提供了两种producer接口,一种是low_level接口,使用该接口会向特定的broker的某个topic下的某个partition发送数据;另一种那个是high level接口,该接口支持同步/异步发送数据,基于zookeeper的broker自动识别和负载均衡(基于Partitioner)。

其中,基于zookeeper的broker自动识别值得一说。producer可以通过zookeeper获取可用的broker列表,也可以在zookeeper中注册listener,该listener在以下情况下会被唤醒:

a.添加一个broker

b.删除一个broker

c.注册新的topic

d.broker注册已存在的topic

当producer得知以上时间时,可根据需要采取一定的行动。

(2) Broker

Broker采取了多种策略提高数据处理效率,包括sendfile和zero copy等技术。

(3) Consumer

consumer的作用是将日志信息加载到中央存储系统上。kafka提供了两种consumer接口,一种是low level的,它维护到某一个broker的连接,并且这个连接是无状态的,即,每次从broker上pull数据时,都要告诉broker数据的偏移量。另一种是high-level 接口,它隐藏了broker的细节,允许consumer从broker上push数据而不必关心网络拓扑结构。更重要的是,对于大部分日志系统而言,consumer已经获取的数据信息都由broker保存,而在kafka中,由consumer自己维护所取数据信息。

5. Cloudera的Flume

Flume是cloudera于2009年7月开源的日志系统。它内置的各种组件非常齐全,用户几乎不必进行任何额外开发即可使用。

设计目标:

(1) 可靠性

当节点出现故障时,日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障,从强到弱依次分别为:end-to-end(收到数据agent首先将event写到磁盘上,当数据传送成功后,再删除;如果数据发送失败,可以重新发送。),Store on failure(这也是scribe采用的策略,当数据接收方crash时,将数据写到本地,待恢复后,继续发送),Best effort(数据发送到接收方后,不会进行确认)。

(2) 可扩展性

Flume采用了三层架构,分别问agent,collector和storage,每一层均可以水平扩展。其中,所有agent和collector由master统一管理,这使得系统容易监控和维护,且master允许有多个(使用ZooKeeper进行管理和负载均衡),这就避免了单点故障问题。

(3) 可管理性

所有agent和colletor由master统一管理,这使得系统便于维护。用户可以在master上查看各个数据源或者数据流执行情况,且可以对各个数据源配置和动态加载。Flume提供了web 和shell script command两种形式对数据流进行管理。

(4) 功能可扩展性

用户可以根据需要添加自己的agent,colletor或者storage。此外,Flume自带了很多组件,包括各种agent(file, syslog等),collector和storage(file,HDFS等)。

架构

正如前面提到的,Flume采用了分层架构,由三层组成,分别为agent,collector和storage。其中,agent和collector均由两部分组成:source和sink,source是数据来源,sink是数据去向。

(1) agent

agent的作用是将数据源的数据发送给collector,Flume自带了很多直接可用的数据源(source),如:

text(“filename”):将文件filename作为数据源,按行发送

tail(“filename”):探测filename新产生的数据,按行发送出去

fsyslogTcp(5140):监听TCP的5140端口,并且接收到的数据发送出去

同时提供了很多sink,如:

console[("format")] :直接将将数据显示在桌面上

text(“txtfile”):将数据写到文件txtfile中

dfs(“dfsfile”):将数据写到HDFS上的dfsfile文件中

syslogTcp(“host”,port):将数据通过TCP传递给host节点

(2) collector

collector的作用是将多个agent的数据汇总后,加载到storage中。它的source和sink与agent类似。

下面例子中,agent监听TCP的5140端口接收到的数据,并发送给collector,由collector将数据加载到HDFS上。

1
2
3
host : syslogTcp(5140) | agentSink("localhost",35853) ;
 
collector : collectorSource(35853) | collectorSink("hdfs://namenode/user/flume/ ","syslog");

一个更复杂的例子如下:

有6个agent,3个collector,所有collector均将数据导入HDFS中。agent A,B将数据发送给collector A,agent C,D将数据发送给collectorB,agent C,D将数据发送给collectorB。同时,为每个agent添加end-to-end可靠性保障(Flume的三种可靠性保障分别由agentE2EChain, agentDFOChain, and agentBEChain实现),如,当collector A出现故障时,agent A和agent B会将数据分别发给collector B和collector C。

下面是简写的配置文件片段:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
agentA : src | agentE2EChain("collectorA:35853","collectorB:35853");
 
agentB : src | agentE2EChain("collectorA:35853","collectorC:35853");
 
agentC : src | agentE2EChain("collectorB:35853","collectorA:35853");
 
agentD : src | agentE2EChain("collectorB:35853","collectorC:35853");
 
agentE : src | agentE2EChain("collectorC:35853","collectorA:35853");
 
agentF : src | agentE2EChain("collectorC:35853","collectorB:35853");
 
collectorA : collectorSource(35853) | collectorSink("hdfs://...","src");
 
collectorB : collectorSource(35853) | collectorSink("hdfs://...","src");
 
collectorC : collectorSource(35853) | collectorSink("hdfs://...","src");

此外,使用autoE2EChain,当某个collector 出现故障时,Flume会自动探测一个可用collector,并将数据定向到这个新的可用collector上。

(3) storage

storage是存储系统,可以是一个普通file,也可以是HDFS,HIVE,HBase等。

6. 总结

根据这四个系统的架构设计,可以总结出典型的日志系统需具备三个基本组件,分别为agent(封装数据源,将数据源中的数据发送给collector),collector(接收多个agent的数据,并进行汇总后导入后端的store中),store(中央存储系统,应该具有可扩展性和可靠性,应该支持当前非常流行的HDFS)。

下面表格对比了这四个系统:

7. 参考资料

scribe主页:https://github.com/facebook/scribe

chukwa主页:http://incubator.apache.org/chukwa/

kafka主页:http://sna-projects.com/kafka/

Flume主页:https://github.com/cloudera/flume/

原创文章,转载请注明: 转载自董的博客

本文链接地址: http://dongxicheng.org/search-engine/log-systems/

246月/100

Apache日志配置

发布在 邵珠庆

有时候我们需要定制Apache 默认日志的格式和内容,比如增加或减少日志所记录的信息、改变默认日志文件的格式等。本文介绍可以用日志记录的所有信息,以及如何设置Apache 使其记录这些信息。

一、定义日志格式(4月3日)

很久以前,日志文件只有一种格式,这就是“公共格式”,许多人已经习惯于使用这种格式。随后出现了定制日志格式,而且看起来定制日志格式更很受欢迎,即使 公共日志格式本身也重新用定制日志格式定义。本文介绍的就是如何随心所欲地定制日志文件的格式、如何让日志文件记录自己想要的信息。

定制日志文件的格式涉及到两个指令,即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”的日志格式,其中包括:远程主机,远程登录名字,远程用户,请求时间,请求的第一 行代码,请求状态,以及发送的字节数。

有时候我们只想在日志中记录某些特定的、已定义的信息,这时就要用到“...”。如果在“%”和变量之间放入了一个或者多个HTTP状态代码,则只有当请 求返回的状态代码属于指定的状态代码之一时,变量所代表的内容才会被记录。例如,如果我们想要记录的是网站的所有无效链接,那么可以使用:

LogFormat %404{Referer}i BrokenLinks

反之,如果我们想要记录那些状态代码不等于指定值的请求,只需加入一个“!”符号即可:

 

Apache 日志:访问日志(一)
想要知道什么人在什么时候浏览了网站的哪些内容吗?查看Apache 的访问日志就可以知道。访问日志是Apache 的标准日志,本文详细解释了访问日志的内容以及相关选项的配置。

一、访问日志的格式

Apache 内建了记录服务器活动的功能,这就是它的日志功能。这个《Apache 日志》系列文章介绍的就是Apache 的访问日志、错误日志,以及如何分析日志数据,如何定制Apache 日志,如何从日志数据生成统计报表等内容。

如果Apache 的安装方式是默认安装,服务器一运行就会有两个日志文件生成。这两个文件是access_log(在Windows上是access.log)和 error_log(在Windows上是error.log)。采用默认安装方式时,这些文件可以在/usr/local/apache /logs下找到;对于Windows系统,这些日志文件将保存在Apache 安装目录的logs子目录。不同的包管理器会把日志文件放到各种不同的位置,所以你可能需要找找其他的地方,或者通过配置文件查看这些日志文件配置到了什 么地方。

正如其名字所示,访问日志access_log记录了所有对Web服务器的访问活动。下面是访问日志中一个典型的记录:

216.35.116.91 - - [19/Aug/2000:14:47:37 -0400] "GET / HTTP/1.0" 200 654

这行内容由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,其他经常可能出现的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,它表示服务器已经成功地响应浏览器的请 求,一切正常。此处不准备给出状态代码的完整清单以及解释它们的含义,请参考相关资料了解这方面的信息。但一般地说,以2开头的状态代码表示成功,以3开 头的状态代码表示由于各种不同的原因用户请求被重定向到了其他位置,以4开头的状态代码表示客户端存在某种错误,以5开头的状态代码表示服务器遇到了某个 错误。

日志记录的第七项表示发送给客户端的总字节数。它告诉我们传输是否被打断(即,该数值是否和文件的大小相同)。把日志记录中的这些值加起来就可以得知服务 器在一天、一周或者一月内发送了多少数据。

二、配置访问日志

访问日志文件的位置实际上是一个配置选项。如果我们检查httpd.conf配置文件,可以看到该文件中有如下这行内容:

CustomLog /usr/local/apache /logs/access_log common
注意,对于版本较早的Apache 服务器,这行内容可能略有不同。它使用的可能不是CustomLog指令,而是TransferLog指令。如果你的服务器属于这类情况,建议你尽可能地 早日升级服务器。

CustomLog指令指定了保存日志文件的具体位置以及日志的格式。至于如何定制日志文件的格式以及内容,我们将在这个《Apache日志》系列文章的后面几篇讨论。上面这行指令指定的是common日志格式,自从有了Web服务器开始,common格式就是它的标准格式。由此我们也可 以理解,虽然几乎不再有任何客户程序向服务器提供用户的标识信息,但访问日志却还保留着第二项内容。

CustomLog指令中的路径是日志文件的路径。注意,由于日志文件是由HTTP用户打开的(用User指令指定),因此必须注意这个路径要有安全保 证,防止该文件被随意改写。

Apache 日志》系列文章的后面几篇将继续介绍:Apache 错误日志,定制日志的格式和内容,如何将日志内容写入指定的程序而不是文件,如何从日志文件获得一些非常有用的统计信息,等等。
Apache 日志:访问日志(二)

3. 进程统计

UNIX可以跟踪每个用户运行的每条命令,如果想知道昨晚弄乱了哪些重要的文件,进程统计子系统可以告诉 你。它对还跟踪一个侵入者有帮助。与连接时间日志不同,进程统计子系统缺省不激活,它必须启动。在Linux系统中启动进程统计使用accton命令,必 须用root身份来运行。Accton命令的形式accton file,file必须先存在。先使用touch命令来创建pacct文件:touch /var/log/pacct,然后运行accton: accton /var/log/pacct。一旦accton被激活,就可以使用lastcomm命令监测系统中任何时候执行的命令。若要关闭统计,可以使用不带任何 参数的accton命令。

lastcomm命令报告以前执行的文件。不带参数时,lastcomm命令显示当前统计文件生命周期内纪录的所有命令的有关信息。包括命令名、用 户、tty、命令花费的CPU时间和一个时间戳。如果系统有许多用户,输入则可能很长。下面的例子:

crond F root ?? 0.00 secs Sun Aug 20 00:16
promisc_check.s S root ?? 0.04 secs Sun Aug 20 00:16
promisc_check root ?? 0.01 secs Sun Aug 20 00:16
grep root ?? 0.02 secs Sun Aug 20 00:16
tail root ?? 0.01 secs Sun Aug 20 00:16
sh root ?? 0.01 secs Sun Aug 20 00:15
ping S root ?? 0.01 secs Sun Aug 20 00:15
ping6.pl F root ?? 0.01 secs Sun Aug 20 00:15
sh root ?? 0.01 secs Sun Aug 20 00:15
ping S root ?? 0.02 secs Sun Aug 20 00:15
ping6.pl F root ?? 0.02 secs Sun Aug 20 00:15
sh root ?? 0.02 secs Sun Aug 20 00:15
ping S root ?? 0.00 secs Sun Aug 20 00:15
ping6.pl F root ?? 0.01 secs Sun Aug 20 00:15
sh root ?? 0.01 secs Sun Aug 20 00:15
ping S root ?? 0.01 secs Sun Aug 20 00:15
sh root ?? 0.02 secs Sun Aug 20 00:15
ping S root ?? 1.34 secs Sun Aug 20 00:15
locate root ttyp0 1.34 secs Sun Aug 20 00:15
accton S root ttyp0 0.00 secs Sun Aug 20 00:15

进程统计的一个问题是pacct文件可能增长的十分迅速。这时需要交互式的或经过cron机制运行sa命令来保持日志数据在系统控制内。sa命令报告、 清理并维护进程统计文件。它能把/var/log/pacct中的信息压缩到摘要文件/var/log/savacct和/var/log /usracct中。这些摘要包含按命令名和用户名分类的系统统计数据。sa缺省情况下先读它们,然后读pacct文件,使报告能包含所有的可用信息。 sa的输出有下面一些标记项:

avio--每次执行的平均I/O操作次数
cp--用户和系统时间总和,以分钟计
cpu--和cp一样
k--内核使用的平均CPU时间,以1k为单位
k*sec--CPU存储完整性,以1k-core秒
re--实时时间,以分钟计
s--系统时间,以分钟计
tio--I/O操作的总数
u--用户时间,以分钟计

例如:

842 173.26re 4.30cp 0avio 358k
2 10.98re 4.06cp 0avio 299k find
9 24.80re 0.05cp 0avio 291k ***other
105 30.44re 0.03cp 0avio 302k ping
104 30.55re 0.03cp 0avio 394k sh
162 0.11re 0.03cp 0avio 413k security.sh*
154 0.03re 0.02cp 0avio 273k ls
56 31.61re 0.02cp 0avio 823k ping6.pl*
2 3.23re 0.02cp 0avio 822k ping6.pl
35 0.02re 0.01cp 0avio 257k md5sum
97 0.02re 0.01cp 0avio 263k initlog
12 0.19re 0.01cp 0avio 399k promisc_check.s
15 0.09re 0.00cp 0avio 288k grep
11 0.08re 0.00cp 0avio 332k awk

用户还可以根据用户而不是命令来提供一个摘要报告。例如sa -m显示如下:

885 173.28re 4.31cp 0avk
root 879 173.23re 4.31cp 0avk
alias 3 0.05re 0.00cp 0avk
qmailp 3 0.01re 0.00cp 0avk

4. Syslog设备

Syslog已被许多日志函数采纳,它用在许多保护措施中--任何程序都可以通过syslog 纪录事件。Syslog可以纪录系统事件,可以写到一个文件或设备中,或给用户发送一个信息。它能纪录本地事件或通过网络纪录另一个主机上的事件。

Syslog设备依据两个重要的文件:/etc/syslogd(守护进程)和/etc/syslog.conf配置文件,习惯上,多数syslog信 息被写到/var/adm或/var/log目录下的信息文件中(messages.*)。一个典型的syslog纪录包括生成程序的名字和一个文本信 息。它还包括一个设备和一个优先级范围(但不在日之中出现)。

每个syslog消息被赋予下面的主要设备之一:

LOG_AUTH--认证系统:login、su、getty等
LOG_AUTHPRIV--同LOG_AUTH,但只登录到所选择的单个用户可读的文件中
LOG_CRON--cron守护进程
LOG_DAEMON--其他系统守护进程,如routed
LOG_FTP--文件传输协议:ftpd、tftpd
LOG_KERN--内核产生的消息
LOG_LPR--系统打印机缓冲池:lpr、lpd
LOG_MAIL--电子邮件系统
LOG_NEWS--网络新闻系统
LOG_SYSLOG--由syslogd(8)产生的内部消息
LOG_USER--随机用户进程产生的消息
LOG_UUCP--UUCP子系统
LOG_LOCAL0~LOG_LOCAL7--为本地使用保留

Syslog为每个事件赋予几个不同的优先级:

LOG_EMERG--紧急情况
LOG_ALERT--应该被立即改正的问题,如系统数据库破坏
LOG_CRIT--重要情况,如硬盘错误
LOG_ERR--错误
LOG_WARNING--警告信息
LOG_NOTICE--不是错误情况,但是可能需要处理
LOG_INFO--情报信息
LOG_DEBUG--包含情报的信息,通常旨在调试一个程序时使用

syslog.conf文件指明syslogd程序纪录日志的行为,该程序在启动时查询配置文件。该文件由不同程序或消息分类的单个条目组成,每个占一 行。对每类消息提供一个选择域和一个动作域。这些域由tab隔开:选择域指明消息的类型和优先级;动作域指明syslogd接收到一个与选择标准相匹配的 消息时所执行的动作。每个选项是由设备和优先级组成。当指明一个优先级时,syslogd将纪录一个拥有相同或更高优先级的消息。所以如果指 明"crit",那所有标为crit、alert和emerg的消息将被纪录。每行的行动域指明当选择域选择了一个给定消息后应该把他发送到哪儿。例如, 如果想把所有邮件消息纪录到一个文件中,如下:

#Log all the mail messages in one place
mail.* /var/log/maillog

其他设备也有自己的日志。UUCP和news设备能产生许多外部消息。它把这些消息存到自己的日志(/var/log/spooler)中并把级别限 为"err"或更高。例如:

# Save mail and news errors of level err and higher in aspecial file.
uucp,news.crit /var/log/spooler

当一个紧急消息到来时,可能想让所有的用户都得到。也可能想让自己的日志接收并保存。

#Everybody gets emergency messages, plus log them on anther machine
*.emerg *
*.emerg @linuxaid.com.cn

alert消息应该写到root和tiger的个人账号中:

#Root and Tiger get alert and higher messages
*.alert root,tiger

有时syslogd将产生大量的消息。例如内核("kern"设备)可能很冗长。用户可能想把内核消息纪录到/dev/console中。下面的例子 表明内核日志纪录被注释掉了:

#Log all kernel messages to the console
#Logging much else clutters up the screen
#kern.* /dev/console

用户可以在一行中指明所有的设备。下面的例子把info或更高级别的消息送到/var/log/messages,除了mail以外。级 别"none"禁止一个设备:

#Log anything(except mail)of level info or higher
#Don't log private authentication messages!
*.info:mail.none;authpriv.none /var/log/messages

在有些情况下,可以把日志送到打印机,这样网络入侵者怎么修改日志都没有用了。通常要广泛纪录日志。Syslog设备是一个攻击者的显著目标。一个为 其他主机维护日志的系统对于防范服务器攻击特别脆弱,因此要特别注意。

有个小命令logger为syslog(3)系统日志文件提供一个shell命令接口,使用户能创建日志文件中的条目。用法:logger 例如:logger This is a test!

它将产生一个如下的syslog纪录:Aug 19 22:22:34 tiger: This is a test!

注意不要完全相信日志,因为攻击者很容易修改它的。

5. 程序日志

许多程序通过维护日志来反映系统的安全状态。su命令允许用户获得另一个用户的权限,所以它的安全很重要,它的文件为sulog。同样的还有 sudolog。另外,想Apache 有两个日志:access_log和error_log。

26月/100

apache的日志access_log分析

发布在 邵珠庆

当网站出问题时分析日志,第一步一般都不会是看访问日志。但是也不能忽视它,在访问日志中记录了很多的客户信息,如果你有心,可以从这个日志中获得很多有 用的信息!

访问日志access_log记录了所有对Web服务器的访问活动。
正如其名字所示,访问日志access_log记录了所有对Web服务器的访问活动。

下面是访问日志中一个典型的记录:

10.1.1.95 - e800 [18/Mar/2005:12:21:42 +0800] "GET /stats/awstats.pl?config=e800 HTTP/1.1" 200 899 "http://10.1.1.1/pv/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon)"

这行内容由9项构成,上面的例子中有两项空白,但整行内容仍旧分成了9项。

第一项信息是远程主机的地址。如果你想知道这个IP地址的域名,可通过nslookup或者host命令来查看。如果你想让Apache自己找出这个IP 的主机名,可以打开这个开关:HostnameLookups。(建议最好不要打开,会影响Apache记录服务器日志的速度)

第二项是空白,用一个"-"占位符替代。实际上绝大多数时候这一项都是如此。这个位置用于记录浏览者的标识,这不只是浏览者的登录名字,而是浏览者的 email地址或者其他唯一标识符。这个信息由identd返回,或者直接由浏览器返回。很早的时候,那时Netscape 0.9还占据着统治地位,这个位置往往记录着浏览者的email地址。然而,由于有人用它来收集邮件地址和发送垃圾邮件,所以它未能保留多久,很久之前市 场上几乎所有的浏览器就取消了这项功能。因此,到了今天,我们在日志记录的第二项看到email地址的机会已经微乎其微了。

第三项也是e800。这个位置用于记录浏览者进行身份验证时提供的名字。当然,如果网站的某些内容要求用户进行身份验证,那么这项信息是不会空白的。但 是,对于大多数网站来说,日志文件的大多数记录中这一项仍旧是空白的。

日志记录的第四项是请求的时间。这个信息用方括号包围,而且采用所谓的"公共日志格式"或"标准英文格式"。因此,上例日志记录表示请求的时间是2005 年3月18日12:21:42。时间信息最后的"+0800"表示服务器所处时区位于UTC之后的8小时。

日志记录的第五项信息或许是整个日志记录中最有用的信息,它告诉我们服务器收到的是一个什么样的请求。该项信息的典型格式是"METHOD RESOURCE PROTOCOL",即"方法 资源 协议"。

RESOURCE是指浏览者向服务器请求的文档,或URL。在这个例子中,浏览者请求的是"/stats/awstats.pl?config=e800 "。

在上例中,METHOD是GET,其他经常可能出现的METHOD还有POST和HEAD。此外还有不少可能出现的合法METHOD,但主要就是这三种。

PROTOCOL通常是HTTP,后面再加上版本号。

日志记录的第六项信息是状态代码。它告诉我们请求是否成功,或者遇到了什么样的错误。大多数时候,这项值是200,它表示服务器已经成功地响应浏览器的 请求,一切正常。一般地说,以2开头的状态代码表示成功,以3开头的状态代码表示由于各种不同的原因用户请求被重定向到了其他位置,以4开头的状态代码表 示客户端存在某种错误,以5开头的状态代码表示服务器遇到了某个错误。

日志记录的第七项表示发送给客户端的总字节数。它告诉我们传输是否被打断(即,该数值是否和文件的大小相同)。把日志记录中的这些值加起来就可以得知服务 器在一天、一周或者一月内发送了多少数据。

日志记录的第八项记录的是客户在提出请求时所在的目录或URL。这次的是"http://10.1.1.1/pv/"即10.1.1.1的pv目录下的首 页。大多数情况下,首页会是在httpd.conf中DocumentRoot 指令后面规定的那些类型和名字的web文件。

日志记录的第九项表示客户端的详细信息,这样你就不难理解为什么有些网站能够在页面中显示你的IP、OS、Browser了。