CN101964795A

CN101964795A - 日志采集系统、日志采集方法和日志回收服务器

Info

Publication number: CN101964795A
Application number: CN2010105041989A
Authority: CN
Inventors: 杨利军; 郜时红; 姚永壮; 井卫军; 蒋建平
Original assignee: BEIJING CLOUDEX SOFTWARE SERVICE Co Ltd; BEIJING BANYANO DATA CENTER SOLUTIONS Ltd
Current assignee: Beijing Century Broadband Internet Data Center Co., Ltd.
Priority date: 2010-09-30
Filing date: 2010-09-30
Publication date: 2011-02-02

Abstract

本发明涉及一种日志采集系统、日志采集方法和日志回收服务器；其中，所述日志采集系统包括加速服务器、日志回收服务器和中心服务器；加速服务器用于产生日志文件，并将日志文件上传到日志回收服务器；日志回收服务器用于接收多个加速服务器上传的日志文件，并将接收的日志文件上传到中心服务器；中心服务器用于接收多个日志回收服务器上传的日志文件；其中，日志回收服务器的数量少于加速服务器的数量。采用本发明的日志采集系统、日志采集方法和日志回收服务器，可有效降低中心服务器的压力、降低网络开销，并且提高了传输效率。

Description

日志采集系统、日志采集方法和日志回收服务器

技术领域

本发明涉及日志处理技术，尤其涉及日志采集系统、日志采集方法和日志回收服务器。

背景技术

用户对互联网的访问，其实就是对某台服务器的访问。服务器一旦被访问，不可避免的会产生用户访问日志。为了便于日志得到处理，网络侧需要对日志进行采集(也可以称为回收)。参与日志采集工作的服务器可以组成一个日志采集系统。

目前的日志采集系统如图1所示，多个日志产生服务器都将日志上传到同一个中心服务器，由中心服务器对采集到的日志进行处理，其中，日志产生服务器是接受用户访问并产生日志的服务器。

本发明的发明人在仔细研究图1所示的日志采集系统后发现，图1所示的日志采集系统虽然能够完成日志的回收，但是，如果向中心服务器上传日志的日志产生服务器的数量较多，那么会给中心服务器造成很大的压力，严重时，可能会导致中心服务器的崩溃，进而造成日志产生服务器无法将日志上传到中心服务器或者上传日志严重延时。

发明内容

本发明提出一种日志采集系统、日志采集方法和日志回收服务器，用于解决现有的日志采集系统中的中心服务器压力大的问题。

本发明技术方案的实现过程如下：

一种日志采集系统，包括加速服务器、日志回收服务器和中心服务器；

加速服务器用于产生日志文件，并将日志文件上传到日志回收服务器；

日志回收服务器用于接收多个加速服务器上传的日志文件，并将接收的日志文件上传到中心服务器；

中心服务器用于接收多个日志回收服务器上传的日志文件；

其中，日志回收服务器的数量少于加速服务器的数量。

一种基于前述日志采集系统的日志采集方法，包括：

日志回收服务器获得加速服务器上传的日志文件；

日志回收服务器对加速服务器上传的日志文件进行处理；

日志回收服务器将处理后的日志文件上传到中心服务器。

一种日志回收服务器，设置在前述日志采集系统中，包括：

获得单元，用于获得加速服务器上传的日志文件；

处理单元，用于对加速服务器上传的日志文件进行处理；

上传单元，用于将处理后的日志文件上传到中心服务器。

在本发明的日志采集系统中，设置有介于加速服务器和中心服务器之间的日志回收服务器，加速服务器向日志回收服务器上传日志文件，日志回收服务器向中心服务器上传日志文件，而且日志回收服务器的数量少于加速服务器的数量，这样，日志回收服务器向中心服务器上传日志文件对中心服务器造成的压力要小于加速服务器直接向中心服务器上传日志文件对中心服务器造成的压力，从而解决了现有的日志采集系统中的中心服务器压力大的问题。

附图说明

为了更清楚地说明本发明或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为现有的日志采集系统的逻辑结构图；

图2为本发明的日志采集系统的逻辑结构图；

图3为本发明的日志采集方法的流程图；

图4为本发明的日志回收服务器的逻辑结构图。

具体实施方式

为了使本技术领域的人员更好地理解本发明实施例中的技术方案，并使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图对本发明中技术方案作进一步详细的说明。

首先介绍本发明的日志采集系统。

本发明的日志采集系统采用三层架构形式。底层为加速服务器，即供用户访问、产生日志的服务器，包括多种服务类型的web服务器。中间层为日志回收服务器，接收加速服务器上传的日志文件，在实际应用中，可以根据运营商的不同及运营商所在的省份、城市，将物理上位于一个区域的服务器归为一个物理节点，而且根据加速服务器的数量，在每个物理节点都部署至少一个日志回收服务器，例如部署1-3个日志回收服务器。中心层为中心服务器，接收日志回收服务器上传的日志文件。日志回收服务器的数量要少于加速服务器的数量。例如，在某个城市(即一个物理节点)部署某个运营商的数百台加速服务器，那么在这个城市可以部署这个运营商的数台日志回收服务器。

考虑到单点故障可能引发部分加速服务器的日志上传中断，在实际应用中，可以根据物理位置将整个网络(也可以称为全网)的物理节点划分为几大区域，具体可按照本地、城市、省份、大区进行划分，一旦某个物理节点的日志回收服务器发生故障，那么这个物理节点的加速服务器可以将日志文件上传到本区域内的其他物理节点的日志回收服务器。当然，如有必要，这个物理节点的加速服务器也可以将日志文件上传到其他区域内的日志回收服务器，或者，这个物理节点的加速服务器可先将日志文件上传到本区域内的其他物理节点的日志回收服务器，最后由其他区域内的日志回收服务器将日志文件上传到中心服务器。

下面结合图2，对本发明的日志采集系统进行详细说明。如图2所示，日志采集系统包括加速服务器(也可以称为Cache)、日志回收服务器(也可以称为Sitelog)和中心服务器(也可以称为Logserver)；加速服务器用于产生日志文件，并将日志文件上传到日志回收服务器；日志回收服务器用于接收多个加速服务器上传的日志文件，并将接收的日志文件上传到中心服务器；中心服务器用于接收多个日志回收服务器上传的日志文件；其中，日志回收服务器的数量少于加速服务器的数量。

优选的，日志回收服务器与向其上传日志文件的加速服务器位于同一个网络内，或者说，一个物理节点可以认为是一个网络，这样，日志回收服务器与向其上传日志文件的加速服务器之间的交互属于内网交互，可以有效的降低网络开销，提高传输效率。

在实际应用中，可以配置加速服务器的web服务，并通过shell脚本定时截取日志文件。具体的，通过修改加速服务器的在线服务的源代码和配置文件，使得各种web服务(包括apache服务、squid服务、nginx服务等)在正常对外提供服务的同时，利用shell脚本，调用服务本身的命令将服务日志文件定时(例如为每五分钟)移置到指定目录下，并以该加速服务器的唯一标识、当前时间(或时间戳的形式)及服务类型等信息拼装日志文件名。

在实际应用中，一个物理节点可能具有多个日志回收服务器，这种情况下，加速服务器在上传日志文件之前，可以从同一个网络(同一个物理节点)内的所有日志回收服务器中选择一个日志回收服务器，并向选中的日志回收服务器上传日志。如果加速服务器无法选择同一个网络内的日志回收服务器，则可以从全网的日志回收服务器中选择一个日志回收服务器，并向选中的日志回收服务器上传日志。

具体的，可以在每个加速服务器上运行一个获取日志回收服务器信息的脚本，脚本需要具备选择日志回收服务器的功能，这样不会因为某个日志回收服务器故障，而导致本网络(本物理节点)内的日志文件无法上传。脚本定时运行，具体功能如下：

判断是否有日志回收服务器的配置列表和日志堆积，这里的日志堆积是指有需要上传的日志文件；

如果没有日志回收服务器的配置列表，则先获取本网络内的日志回收服务器信息，并判断日志回收服务器的可用性，之后生成可用的日志回收服务器的配置列表，并从中选择一个日志回收服务器，将选中的日志回收服务器写入上传配置文件中。如果本网络内没有可用的日志回收服务器，则从中心服务器获取其他网络内的日志回收服务器信息，并判断这些日志回收服务器的可用性，之后生成可用的日志回收服务器的配置列表，并从中选择一个日志回收服务器，将选中的日志回收服务器写入上传配置文件中；

如果有日志回收服务器的配置列表，并且有日志堆积，则先判断配置列表中的日志回收服务器的可用性，从可用的日志回收服务器中选择一个日志回收服务器，将选中的日志回收服务器加入配置文件中；

如果有日志回收服务器的配置列表，但没有日志堆积，则结束脚本运行。

在实际应用中，加速服务器可以周期性的不间断的检查是否有新的日志文件产生，即会根据指定时间间隔不间断的检查是否有新的日志文件产生，如果有新的日志文件产生，则将新的日志文件上传到选中的日志回收服务器。另外，加速服务器可以将已上传的日志文件进行备份。

具体的，在加速服务器上运行一个守护进程，根据指定时间间隔不间断的到指定目录检查是否有新的日志文件产生，一旦有新的日志文件产生，就将新的日志文件传送至配置文件中记录的日志回收服务器。为了确保日志文件的正常传输，在传输过程中，将传输中的日志文件名后添加“.tmp”后缀，一旦日志文件传输完毕，则对日志文件进行重命名，去掉“.tmp”后缀，并将已上传的日志文件移至备份目录。由于加速服务器的存储空间有限，所以，每个加速服务器可以根据实际情况，保存最近几天的日志文件，例如保存最近1-3天的日志文件，以便于后期日志重算或者排除加速服务器故障等使用。

图2所示的日志回收服务器接收到日志文件后，可以对日志文件进行处理。例如，由于网络震荡或者加速服务器异常等原因，可能会造成某些日志文件不完整，对此，日志回收服务器可以将无法分析的日志文件进行清理。再例如，对于不同web服务日志，为了保证中心服务器处理逻辑的简单、统一，日志回收服务器可以对日志文件中的信息进行拆分和提取，将提取后的信息生成中心服务器文件格式的日志文件。

日志回收服务器处理完日志文件后，可以定时将处理后的日志文件上传到中心服务器。具体的上传过程如下：

日志回收服务器获得中心服务器的配置列表；

日志回收服务器从配置列表中选择一个中心服务器；

日志回收服务器向选中的中心服务器发起连接请求；

如果选中的中心服务器接受日志回收服务器的连接请求，则日志回收服务器与选中的中心服务器建立连接，这里的建立连接可以是指建立文件传输协议(FTP，File Transfer Protocol)文件传输通道；

日志回收服务器向选中的中心服务器上传日志文件；

上传结束后，日志回收服务器断开与选中的中心服务器的连接。

为保证正在上传的日志文件不被其他功能模块取走，在上传日志文件过程中，日志文件名可以加上“.tmp”后缀。在日志文件上传结束后，将日志文件重命名，去掉“.tmp”后缀。

另外，日志回收服务器可以将已上传的日志文件进行备份，具体的，可以将已上传的日志文件备份到指定的目录下。日志回收服务器可以保存多天的日志文件，例如保存7天的日志文件。这样，即使中心服务器出现故障，仍然能够根据备份的日志文件进行重算等操作。

图2所示的中心服务器负责全网内的日志备份，中心服务器可以将日志文件提供给分析系统或者提供给客户下载等。在实际应用中，中心服务器的数量可以是多个，每个中心服务器都接收一些日志回收服务器上传的日志文件，每个中心服务器对应的日志回收服务器的数量都少于现有的日志采集系统的中心服务器对应的日志产生服务器的数量，这样可以极大的减轻中心服务器的压力。

基于上述的日志采集系统，本发明还从日志回收服务器的角度，提供一种日志采集方法。如图3所示，这种方法包括：

S301：日志回收服务器获得加速服务器上传的日志文件；

S302：日志回收服务器对加速服务器上传的日志文件进行处理；

S303：日志回收服务器将处理后的日志文件上传到中心服务器。

S302包括：日志回收服务器将无法分析的日志文件进行清理；和/或，日志回收服务器对日志文件中的信息进行拆分和提取，将提取后的信息生成中心服务器文件格式的日志文件。

执行S303之前，日志回收服务器可以获得中心服务器的配置列表，从配置列表中选择一个中心服务器。这样，日志回收服务器将处理后的日志文件上传到中心服务器是指，将处理后的日志文件上传到选中的中心服务器。

S303包括：

日志回收服务器向选中的中心服务器发起连接请求；

如果选中的中心服务器接受日志回收服务器的连接请求，则日志回收服务器与选中的中心服务器建立连接；

日志回收服务器向选中的中心服务器上传日志文件；

执行S303后，日志回收服务器可以将已上传的日志文件进行备份。

关于日志采集方法的详细描述，可以参见上述的日志采集系统中的相关描述，这里不再赘述。

对应于上述的日志采集方法，本发明还提供一种设置在上述的日志采集系统中的日志回收服务器。如图4所示，这种日志回收服务器包括：获得单元401，用于获得加速服务器上传的日志文件；处理单元402，用于对加速服务器上传的日志文件进行处理；上传单元403，用于将处理后的日志文件上传到中心服务器。

处理单元402具体用于将无法分析的日志文件进行清理，和/或，对日志文件中的信息进行拆分和提取，将提取后的信息生成中心服务器文件格式的日志文件。

在上传单元403将处理后的日志文件上传到中心服务器之前，获得单元401获得中心服务器的配置列表。日志回收服务器还可以包括选择单元404，用于从配置列表中选择一个中心服务器。这样，上传单元403可以将处理后的日志文件上传到选中的中心服务器。

上传单元403可以包括：请求模块，用于向选中的中心服务器发起连接请求；连接模块，用于如果选中的中心服务器接受连接单元的连接请求，则与选中的中心服务器建立连接；上传模块，用于向选中的中心服务器上传日志文件；断开模块，用于在上传模块上传完日志文件后，断开与选中的中心服务器的连接。

日志回收服务器还可以包括备份单元405，用于在上传单元403将处理后的日志文件上传到中心服务器后，将已上传的日志文件进行备份。

关于日志回收服务器的详细描述，可以参见上述的日志采集系统中的相关描述，这里不再赘述。

综上所述，本发明的日志采集系统采用三层结构，处于中间层、并向中心服务器上传日志文件的日志回收服务器的数量少于处于底层、并向日志回收服务器上传日志文件的加速服务器的数量，这样可有效降低中心服务器的压力。

正常情况下，加速服务器会将日志文件上传到本网络(本物理节点)内的日志回收服务器，这样的文件上传过程属于内网传输过程，所以可以降低网络开销，并且传输效率较高。

如果加速服务器不断增多，那么可相应的增加日志回收服务器及中心服务器，当然，增加的日志回收服务器和中心服务器的数量远低于增加的加速服务器的数量。所以，本发明的日志采集系统的扩展性较强，

日志回收服务器可以对日志文件的格式进行统一化处理，这样便于中心服务器对日志文件的分析处理工作，降低了中心服务器分析处理的复杂度。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本发明可用于众多通用或专用的计算系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

虽然通过实施例描绘了本发明，本领域普通技术人员知道，本发明有许多变形和变化而不脱离本发明的精神，希望所附的权利要求包括这些变形和变化而不脱离本发明的精神。

Claims

1.一种日志采集系统，其特征在于，包括加速服务器、日志回收服务器和中心服务器；

中心服务器用于接收多个日志回收服务器上传的日志文件；

其中，日志回收服务器的数量少于加速服务器的数量。

2.如权利要求1所述的系统，其特征在于，日志回收服务器与向其上传日志文件的加速服务器位于同一个网络内。

3.如权利要求2所述的系统，其特征在于，加速服务器具体用于从同一个网络内的所有日志回收服务器中选择一个日志回收服务器，并向选中的日志回收服务器上传日志。

4.如权利要求3所述的系统，其特征在于，如果加速服务器无法选择同一个网络内的日志回收服务器，则从全网的日志回收服务器中选择一个日志回收服务器，并向选中的日志回收服务器上传日志。

5.如权利要求3或4所述的系统，其特征在于，加速服务器周期性的检查是否有新的日志文件产生，如果有新的日志文件产生，则将新的日志文件上传到选中的日志回收服务器。

6.如权利要求5所述的系统，其特征在于，加速服务器将已上传的日志文件进行备份。

7.如权利要求1-4任意一项所述的系统，其特征在于，日志回收服务器将无法分析的日志文件进行清理；和/或，

日志回收服务器对日志文件中的信息进行拆分和提取，将提取后的信息生成中心服务器文件格式的日志文件。

8.如权利要求1-4任意一项所述的系统，其特征在于，日志回收服务器获得中心服务器的配置列表，从配置列表中选择一个中心服务器，向选中的中心服务器发起连接请求，如果选中的中心服务器接受日志回收服务器的连接请求，则日志回收服务器与选中的中心服务器建立连接，向选中的中心服务器上传日志文件，上传结束后，断开与选中的中心服务器的连接。

9.如权利要求8所述的系统，其特征在于，日志回收服务器将已上传的日志文件进行备份。

10.一种基于权利要求1-9任意一项所述日志采集系统的日志采集方法，其特征在于，包括：

日志回收服务器获得加速服务器上传的日志文件；

日志回收服务器对加速服务器上传的日志文件进行处理；

日志回收服务器将处理后的日志文件上传到中心服务器。

11.如权利要求10所述的方法，其特征在于，日志回收服务器对加速服务器上传的日志文件进行处理包括：

日志回收服务器将无法分析的日志文件进行清理；和/或，

12.如权利要求10或11所述的方法，其特征在于，日志回收服务器将处理后的日志文件上传到中心服务器之前，获得中心服务器的配置列表，从配置列表中选择一个中心服务器。

13.如权利要求12所述的方法，其特征在于，日志回收服务器将处理后的日志文件上传到中心服务器具体为：日志回收服务器将处理后的日志文件上传到选中的中心服务器；

日志回收服务器将处理后的日志文件上传到选中的中心服务器包括：

日志回收服务器向选中的中心服务器发起连接请求；

日志回收服务器向选中的中心服务器上传日志文件；

14.如权利要求10所述的方法，其特征在于，日志回收服务器将处理后的日志文件上传到中心服务器后，将已上传的日志文件进行备份。

15.一种日志回收服务器，其特征在于，设置在权利要求1-9任意一项所述的日志采集系统中，所述日志回收服务器包括：

获得单元，用于获得加速服务器上传的日志文件；

处理单元，用于对加速服务器上传的日志文件进行处理；

上传单元，用于将处理后的日志文件上传到中心服务器。

16.如权利要求15所述的日志回收服务器，其特征在于，所述处理单元具体用于将无法分析的日志文件进行清理，和/或，对日志文件中的信息进行拆分和提取，将提取后的信息生成中心服务器文件格式的日志文件。

17.如权利要求15或16所述的日志回收服务器，其特征在于，在所述上传单元将处理后的日志文件上传到中心服务器之前，所述获得单元获得中心服务器的配置列表；

所述日志回收服务器还包括选择单元，用于从配置列表中选择一个中心服务器。

18.如权利要求17所述的日志回收服务器，其特征在于，所述上传单元具体用于将处理后的日志文件上传到选中的中心服务器；

所述上传单元包括：

请求模块，用于向选中的中心服务器发起连接请求；

连接模块，用于如果选中的中心服务器接受连接单元的连接请求，则与选中的中心服务器建立连接；

上传模块，用于向选中的中心服务器上传日志文件；

断开模块，用于在上传模块上传完日志文件后，断开与选中的中心服务器的连接。

19.如权利要求15所述的日志回收服务器，其特征在于，还包括备份单元，用于在所述上传单元将处理后的日志文件上传到中心服务器后，将已上传的日志文件进行备份。