CN105099740A - 一种日志管理系统及日志采集方法 - Google Patents

Abstract

本发明提供了一种日志管理系统及日志采集方法，所述日志管理系统包括：多个数据源、数据库服务器、日志采集装置，其中，多个数据源，用于生成具有不同格式的日志；数据库服务器包括：无模式的数据库，用于存储具有不同格式的日志；日志采集装置包括：日志接口模块，用于为所述多个数据源提供日志接口，以使得所述多个数据源通过所述日志接口，将具有不同格式的日志发送至所述日志采集装置；日志持久化模块，用于将具有不同格式的日志发送至所述数据库服务器，以使得所述数据库服务器将所述具有不同格式的日志存储至无模式的数据库中。采用本发明提供的技术方案，无需进行日志格式的统一，减轻了应用系统接入改造的工作量。

Description

一种日志管理系统及日志采集方法

技术领域

本发明涉及计算机通信领域，尤其涉及一种日志管理系统及日志采集方法。

背景技术

在IT系统的运营过程中，为了监控系统运行的状态，或者是为了给业务操作留下记录以备事后审计，应用系统会产生各种各样的日志，包括：操作系统、中间件产生的系统日志、应用软件产生的业务操作日志等等。一般情况下，由于建设的先后顺序和需求不同，各个应用系统各自独立记录、存储自己的日志，各个应用系统的日志的格式通常是不统一的。

在IT系统规模日益扩大和SLA服务水平逐步提高时，通常需要建设日志管理系统，从各个应用系统中采集系统日志、应用软件的操作日志进行集中存储，并对外提供统一的日志查询和分析功能，满足业务分析、网络安全和业务审计的需要。如图1所示，对各类日志的管理一般分为采集、存储和利用等三个阶段。

为了实现对日志的管理，需要将各个应用系统接入日志服务器，一般分为下述几个步骤：

第一步：制订接入规范，梳理各个应用系统的日志记录的实现状况，根据业务、安全、审计等各方面的要求，制订应用系统日志记录的接入规范。

第二步：准备应用接入，各个应用系统根据日志规范，对各自系统的日志管理模块进行改造完善，主要是核对应用日志的各个字段，各个字段的格式和顺序等内容。

第三步：准备服务端，根据待接入的应用系统的日志现状，在服务器上完成应用标识等相应的配置，并根据实际情况进行服务端数据库表的新建或调整。

第四步：接入应用系统，各个应用系统根据日志服务器提供的接口和规范，通过主动推送或Agent采集等方式将日志提交到日志服务器存储。

各个应用系统的日志存储到日志服务器中后，即可进行后续的日志查询、统计分析、审计工作，甚至可以依据日志规则触发告警，以便进行相应的系统和业务处理。

日志管理有下述几个特点：

1.要求将日志实时写入数据库，但通常不会实时使用日志；

2.对日志的操作不会被包含在一个事务中；

3.日志的生产者不应当有修改日志的需求。

现有的应用系统与日志服务器的集成架构图如图2所示，日志服务器一般由日志接收应用和数据库组成，而应用系统可通过日志采集代理接入到日志服务器，也可以直接接入到日志服务器。采集日志的方式包括主动推送(Push)和被动采集(Pull)两种，前者是应用系统调用日志采集代理或日志服务器的接口，主动将日志推送给日志管理系统；后者是日志采集代理到应用系统中去抓取日志，然后发送到日志服务器，从应用系统的角度来看，就属于“被动采集”。

现有的日志服务器通常存在以下问题：

应用系统接入集成工作复杂：关系数据库的每个表都有Schema。日志管理系统存储来自多个应用系统的日志，日志对象的属性很可能各不相同，使用关系数据库存储日志，可以使用两种方法来对齐日志，一是在日志采集代理或日志接收应用中，进行日志格式的转换映射；二是为每种日志进行建表操作。由于日志的格式千差万别，在某应用系统接入时，可能这两种方法都要使用。随着日志种类的增多，应用系统的接入和程序开发会越来越复杂。

以邮件系统为例，其操作日志的结构比较复杂。一个邮件可能有多个收件人并且有多个附件，如果使用Oracle数据库，至少需要3个表来维护2个一对多的关系。

可用性和扩展性难以保障：由于日志管理过程涉及应用服务器和数据库服务器，为了满足高并发写入情况下的系统的可用性和扩展性，必须统筹考虑应用服务器、数据库服务器的架构，这个对于系统架构的设计和系统扩展来说是一个比较大的挑战。

发明内容

为了解决上述技术问题，本发明提供了一种日志管理系统及日志采集方法，对于来自多个应用系统的具有不同格式的日志，无需进行日志格式的统一，减轻了应用系统接入改造的工作量。

为了实现上述目的，本发明提供了一种日志管理系统，包括：多个数据源、数据库服务器、日志采集装置，其中，多个数据源，用于生成具有不同格式的日志；所述数据库服务器包括：无模式的数据库，用于存储具有不同格式的日志；所述日志采集装置包括：日志接口模块，用于为所述多个数据源提供日志接口，以使得所述多个数据源通过所述日志接口，将具有不同格式的日志发送至所述日志采集装置；日志持久化模块，用于将具有不同格式的日志发送至所述数据库服务器，以使得所述数据库服务器将所述具有不同格式的日志存储至无模式的数据库中。

上述日志管理系统，其中，所述日志采集装置还包括：日志转发代理模块，所述日志持久化模块，用于通过所述日志转发代理模块将具有不同格式的日志发送至所述数据库服务器；所述日志转发代理模块包括：接收子模块：用于接收日志操作指令及所述日志持久化模块发送的具有不同格式的日志；数据安全子模块，用于判断所述日志操作指令是否为将所述具有不同格式的日志写入数据库服务器的指令；数据交互子模块，用于在所述数据安全子模块判定所述日志操作指令为将所述具有不同格式的日志写入数据库服务器的指令时，将具有不同格式的日志发送至所述数据库服务器。

上述日志管理系统，其中，所述数据安全子模块进一步用于存储经过加密后的所述无模式的数据库的用户名和密码，并在所述接收子模块接收到具有不同格式的日志后，将所述加密后的用户名和密码进行解密；数据交互子模块，进一步用于在所述数据安全子模块判定所述操作指令为将所述具有不同格式的日志写入数据库服务器的指令时，将解密后的用户名和密码及具有不同格式的日志发送至所述数据库服务器，以使得所述数据库服务器根据解密后的用户名和密码将所述具有不同格式的日志存储至无模式的数据库中。

上述日志管理系统，其中，所述日志采集装置还包括：日志预处理模块，用于对所述具有不同格式的日志配置用于标识生成所述具有不同格式的日志的数据源的参数，并根据预设规则对所述具有不同格式的日志进行过滤；所述日志持久化模块，进一步用于将经过过滤后的具有不同格式的日志发送至所述数据库服务器。

上述日志管理系统，其中，所述日志采集装置还包括：异常处理模块及缓存模块，所述异常处理模块，用于分析所述日志采集装置与所述数据库服务器的链接是否符合预设指标，并在不符合时发送告警信息；当所述异常处理模块确定所述日志采集装置与所述数据库服务器的链接不符合预设指标时，所述日志持久化模块进一步用于将具有不同格式的日志存储至缓存模块。

上述日志管理系统，其中，所述数据库服务器还包括：统计数据库，用于存储根据预设的统计规则脚本及所述无模式的数据库中存储的具有不同格式的日志生成的统计数据。

上述日志管理系统，其中，所述日志采集装置还包括：日志抓取模块，用于从多个数据源中抓取具有不同格式的日志。

本发明还提供了一种日志采集方法，包括：第一接收步骤：通过日志接口接收数据源发送的具有不同格式的日志；日志持久化步骤：将具有不同格式的日志发送至数据库服务器，以使得所述数据库服务器将所述具有不同格式的日志存储至无模式的数据库。

上述日志采集方法，其中，在所述日志持久化步骤之前还包括：第二接收步骤：接收一日志操作指令；判断步骤：判断所述日志操作指令是否为将所述具有不同格式的日志写入数据库服务器的指令；所述日志持久化步骤进一步在所述判断步骤判定所述日志操作指令为将所述具有不同格式的日志写入数据库服务器的指令时，将具有不同格式的日志发送至所述数据库服务器。

上述日志采集方法，其中，所述数据库服务器的无模式的数据库的用户名和密码经过加密后存储，所述日志持久化步骤之前还包括：解密步骤：将所述加密后的用户名和密码进行解密；所述日志持久化步骤进一步在所述判断步骤判定所述日志操作指令为将所述具有不同格式的日志写入数据库服务器的指令时，将解密后的用户名和密码及预处理后具有不同格式的日志发送至所述数据库服务器，以使得所述数据库服务器根据解密后的用户名和密码将所述具有不同格式的日志存储至无模式的数据库中。

上述日志采集方法，其中，所述日志持久化步骤之前还包括：预处理步骤：对所述具有不同格式的日志配置用于标识生成所述具有不同格式的日志的数据源的参数，并根据预设规则对所述具有不同格式的日志进行过滤；所述日志持久化步骤进一步将经过过滤后的具有不同格式的日志发送至所述数据库服务器。

上述日志采集方法，其中，还包括：异常处理步骤：分析所述日志采集装置与所述数据库服务器的链接是否符合预设指标，并在不符合时发送告警信息；所述日志持久化步骤进一步在所述异常处理步骤确定所述日志采集装置与所述数据库服务器的链接不符合预设指标时，将具有不同格式的日志存储至缓存模块。

上述日志采集方法，其中，所述日志持久化步骤之前还包括：获取步骤：从多个数据源中抓取具有不同格式的日志。

本发明的上述技术方案的有益效果如下：

本发明提供了一种日志管理系统及日志采集方法，对于来自多个应用系统的具有不同格式的日志，无需进行日志格式的统一，减轻了应用系统接入改造的工作量；

日志采集装置可以方便地集成在应用系统中，提高了日志管理系统的可用性和扩展性。

附图说明

图1为日志的管理所涉及各个阶段的系统架构图。

图2为现有的应用系统与日志服务器的集成架构图。

图3为本发明实施例1提供的日志管理系统的结构示意图。

图4为本发明实施例2提供的日志管理系统与应用系统的集成架构图。

图5为本发明实施例2提供的针对Java类应用系统的日志采集代理的架构图。

图6为本发明实施例2提供的日志采集代理的工作流程示意图。

图7为本发明实施例2提供的日志转发代理的架构图。

图8为Java类应用系统接入本发明实施例2提供的日志管理系统的流程示意图。

图9为本发明实施例2提供的针对封闭型应用系统的日志采集代理的架构图。

图10为采用本发明实施例提供的日志管理系统对邮件系统的日志存储格式。

图11为采用本发明实施例提供的日志管理系统对统一流程系统的日志存储格式。

图12为采用本发明实施例提供的日志管理系统对邮件系统的日志的查询结果示意图。

图13为采用本发明实施例提供的日志管理系统对统一流程系统的日志的查询结果示意图。

图14为本发明实施例提供的日志采集方法流程示意图。

具体实施方式

为使本发明要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。

本发明实施例针对现有技术中，应用系统接入集成到日志管理系统时，对于不同格式的日志，需要将日志的格式进行统一，从而造成应用系统接入工作复杂的问题，提供了一种日志管理系统及日志采集方法，对于来自多个应用系统的具有不同格式的日志，无需进行日志格式的统一，减轻了应用系统接入改造的工作量。

图3为本发明实施例1提供的日志管理系统的结构示意图，如图所示，所述日志管理系统30包括：

多个数据源31，用于生成具有不同格式的日志；

数据库服务器32包括：无模式的数据库321，用于存储具有不同格式的日志；

日志采集装置33包括：

日志接口模块331，用于为所述多个数据源提供日志接口，以使得所述多个数据源通过所述日志接口，将具有不同格式的日志发送至所述日志采集装置；

日志持久化模块332，用于将具有不同格式的日志发送至所述数据库服务器，以使得所述数据库服务器将所述具有不同格式的日志存储至无模式的数据库中。

日志管理系统中存储来自多个应用系统的各种日志，需要应对多种不同的格式。关系数据库最擅长的事务管理及对二维数据的数据操作功能对于日志存储并无用武之地，同时其性能和Schema的并不能很好地满足具有多种格式的日志存储的需求，因此，在对日志进行采集时，对于多种不同格式的日志，通常需要经过进行统一化后存储至关系数据库，即：将日志的数据格式进行统一，使统一后的日志能够满足关系数据库的存储要求。

而本发明实施例提供的日志管理系统通过采用无模式的无模式的数据库作为存储日志的数据库，能够很好地满足日志的格式复杂多变的存储需求，从而，避免了对来自于不同数据源的具有不同格式的日志进行格式统一的过程，取消了日志的数据格式统一的步骤，减轻了应用系统接入改造的工作量。

日志管理系统存储的多种类型的日志，有些日志能够用于分析应用系统，有些日志中可能会保存有敏感信息，当日志管理系统中存储的日志不准确时，在对应用系统分析时可能会导致错误的结论，而如果日志管理系统中的日志泄露，则有可能造成用户敏感信息的泄露。

因此，上述日志管理系统，其中，所述日志采集装置还可以包括：日志转发代理模块，所述日志持久化模块，用于通过所述日志转发代理模块将具有不同格式的日志发送至所述数据库服务器；所述日志转发代理模块包括：接收子模块：用于接收日志操作指令及所述日志持久化模块发送的具有不同格式的日志；数据安全子模块，用于判断所述日志操作指令是否为将所述日志写入数据库服务器的指令；数据交互子模块，用于在所述数据安全子模块判定所述日志操作指令为将所述日志写入数据库服务器的指令时，将具有不同格式的日志发送至所述数据库服务器。

上述结构的目的是保证日志的安全性与准确性，通过日志转发代理模块对日志采集装置获取到的日志进行转发至数据库服务器，而由于日志转发代理模块只提供将日志写入数据库服务器的操作，对于修改日志、删除日志等其他操作屏蔽，从而确保了存储的日志不会被篡改。

由于日志被存储至数据库中，如果存储日志的数据库的用户名和密码遭到泄露，则会带来安全问题。

因此，上述日志管理系统，其中，所述数据安全子模块进一步用于存储经过加密后的所述无模式的数据库的用户名和密码，并在所述接收子模块接收到具有不同格式的日志后，将所述加密后的用户名和密码进行解密；数据交互子模块，进一步用于在所述数据安全子模块判定所述操作指令为将所述日志写入数据库服务器的指令时，将解密后的用户名和密码及具有不同格式的日志发送至所述数据库服务器，以使得所述数据库服务器根据解密后的用户名和密码将所述具有不同格式的日志存储至无模式的数据库中。

上述结构的目的是防止数据源所对应的应用系统的管理员直接获取到无模式的数据库的用户名和密码，避免了用户名和密码泄露导致无模式的数据库中存储的日志被泄露或篡改的问题。

日志管理系统可以管理来自多个数据源的日志，即日志可以来自多个不同的应用系统，在不用的应用系统中都可能会有系统日志，如果不对这些日志标识其对应的应用系统，在对日志进行分析时，增大了分析难度。

上述日志管理系统，其中，所述日志采集装置还可以包括：日志预处理模块，用于对所述日志配置用于标识生成所述日志的数据源的参数，并根据预设规则对所述日志进行过滤；所述日志持久化模块，进一步用于将经过过滤后的具有不同格式的日志发送至所述数据库服务器。

上述结构的目的是为每个日志标识其对应的数据源，使得后续工作流程中，在对日志进行分析时，能够直接判断出每个日志对应的数据源。

通常来说，存储日志的数据库服务器通过网络与日志采集装置连接，即通过网络将日志发送至数据库服务器，当网络出现问题时，会导致日志发送失败，造成数据损失。

因此，上述日志管理系统，其中，所述日志采集装置还可以包括：异常处理模块及缓存模块，所述异常处理模块，用于分析所述日志采集装置与所述数据库服务器的链接是否符合预设指标，并在不符合时发送告警信息；当所述异常处理模块确定所述日志采集装置与所述数据库服务器的链接不符合预设指标时，所述日志持久化模块进一步用于将具有不同格式的日志存储至缓存模块。

上述结构的目的是，判断日志采集装置与数据库服务器的链接是否正常，即二者之间的网络是否通畅，当二者的链接出现问题时，如写入服务器速度过慢、链接失败次数过多等，可以发出告警信息，以便人工干预恢复网络通畅。

由于无模式的数据库中保存的日志具有不同的格式，这就给后续的查询分析工作带来了困难。

因此，上述日志管理系统，其中，所述数据库服务器还包括：统计数据库，用于存储根据预设的统计规则脚本及所述无模式的数据库中存储的日志生成的统计数据。

上述结构的目的是，通过根据预设的统计规则编写的脚本生成统计数据，如果统计分析的需求很明确，可以根据相应的需求生成中间数据，查询或统计时直接从中间数据中获取统计结果，从而，节省了查询分析的工作量。

由于日志管理系统中的日志来自多个数据源，即可以存储来自多个应用系统的日志，由于不同的应用系统具有不同的架构设计，日志的生成对应于不同的接口，日志采集装置提供的日志接口模块难于满足所有应用系统的接口需求。

因此，上述日志管理系统，其中，所述日志采集装置还包括：日志抓取模块，用于从多个数据源中抓取具有不同格式的日志。

上述结构的目的是，通过抓取方式去应用系统中获取日志。

本发明的具体实施例2提供了一种日志管理系统，采用MongoDB数据库，MongoDB是基于文档存取的NoSQL数据库，它具有高性能和无Schema的特性，能够很好地满足日志的数据格式复杂多变的存储需求。该日志管理系统针对Java应用和Domino等应用开发实现日志采集，应用系统只需少量改造即可将日志传输到数据库服务器，日志管理系统与应用系统的集成架构图如图4所示，其中，嵌入式采集代理及独立采集代理用于实现上述实施例中的日志接口模块、日志持久化模块及日志抓取模块的功能，日志转发代理用于实现上述实施例中日志转发模块的功能。

如图所示，针对的不同的应用系统，提供相应的方法进行日志采集，可以采用嵌入式采集代理进行日志采集，也可以采用独立采集代理进行日志采集，并导入到无模式的数据库，通过统计分析后生成统计数据库，以供统计分析、查询监控等应用。

本发明实施例提供的应用系统与日志管理系统的集成架构，与现有技术的不同之处在于，对日志管理系统的架构进行了简化，日志管理系统上的日志接收应用被剥离，由日志采集装置(包括日志采集代理和日志转发代理)完成日志的采集、传送和入库。

日志采集装置封装了访问数据库服务器的接口，对外提供简单的日志接口，应用系统可在将日志记录到本地存储的基础上，同时通过异步调用日志采集装置将日志发送到数据库服务器中存储。日志采集装置统一解决日志缓存队列、异常检测和日志安全性等问题，应用系统无需考虑这些情况的处理，集成开发非常简单。下面针对不同的应用系统，介绍日志采集装置：

1、Java类应用系统

对于Java类应用系统，应用系统原有的将日志记录到本地磁盘的机制可保持不变，在此基础上，再通过本发明实施例提供的日志采集装置将日志同时记录到数据库服务器中。

Java类应用系统的日志可以分为两类：

第一种是应用日志，指应用系统中记录用户操作、应用系统数据状态改变等业务操作输出的日志。此类日志一般跟业务操作相关；

第二种是运行时日志，指应用系统运行时输出的日志，例如程序异常、程序运行状态等日志。此类日志一般与业务无关，而只是与系统运行情况相关。

针对第一种日志，应用系统一般会使用自定义的方式记录到本地磁盘的数据库或文件系统中；针对第二种日志，应用系统一般会使用log4j、logback或者JdkLogging记录。

日志采集装置由日志采集代理和日志转发代理组成，日志采集代理支持上述两种日志的采集，将日志采集代理部署到应用系统中后，通过简单改造即可嵌入到Java应用系统中，日志采集代理的架构图见图5。

如图所示，日志采集代理自上而下分为三层：

接口层：用于实现上述实施例中的日志接口模块的功能，提供给Java应用系统调用的API接口。其中，Logger接口API是针对第一种日志应用日志提供的日志记录接口，Java应用系统通过此接口创建日志对象并将日志发送到日志管理系统；而针对第二种日志运行时日志，在常见的log4j、logback、JdkLogging等日志框架下开发扩展的Appender或Handler，即日志输出保存的功能模块。仅需修改原有的配置文件而不用修改程序代码即可实现将运行时日志实时发送至日志管理系统。

预处理层：用于实现上述实施例中的日志预处理模块的功能，根据配置文件对日志进行预处理。日志采集代理提供多种可选的配置方式为日志管理系统提供参数，如应用系统名称、日志存储方式等，由日志配置模块负责解析；数据过滤模块根据配置选项，对日志对象进行过滤，验证即将保存到日志管理系统的日志对象是否符合要求，如必填项目是否完整等，仅将符合规则的日志对象传到持久化接口。

持久化层：用于实现上述实施例中的日志持久化模块、异常处理模块及缓存模块的功能，将日志采集装置采集到的日志进行持久化，发送到日志管理系统进行存储。任务调度模块选择日志的保存方法，即正常情况下将数据保存至服务器，而异常情况下将数据缓存到本地。应用系统使用异步方式提交日志给日志采集代理，日志首先会进入持久化队列，由异步持久化模块调用持久化队列管理模块，将日志从应用系统保存至服务器。持久化接口调用失败时，由任务调度模块启动异常处理机制，即调用本地缓存模块将数据暂存到本地，同时尝试连接远端服务，成功连接后将暂存的数据写入服务器。异常处理模块会对异常情况进行统计分析，当调用持久化接口失败的次数达到阈值，或者写入服务器的速度太慢，代理会通过email或告警平台发出告警信息，以便人工干预处理并尽快恢复故障。

上述日志采集代理的工作流程示意图如图6所示，包括：

步骤S600，获取应用系统的日志；

步骤S602，对日志进行预处理；

步骤Ｓ604，判断是否无法将日志保存到数据库服务器，如果是，进入步骤S606，否则，进入步骤S610；

步骤S606，发出异常告警；

步骤S608，将日志保存至本地缓存；

步骤S610，将日志通过转发交互模块发送至日志转发代理。

为了确保日志的安全性，日志采集代理不直接操作日志库，而是通过日志转发代理来提交日志。对于应用系统和日志采集代理来说，日志转发代理只能发送日志到日志管理系统，而不能修改或删除已经存储在日志管理系统中的日志。日志转发代理的架构见图7。

在J2EE环境下，日志转发代理以J2EE容器数据源的方式实现：

接收模块：为日志采集代理提供日志接收服务，日志采集代理通过JNDI来访问此接收模块保存日志；

数据安全模块：该模块主要完成两方面的安全控制，一是对外只提供insert操作，而update、delete等其他操作被屏蔽，这样就确保已存储的日志不会被篡改；二是MongoDB数据库的用户名密码以加密方式保存，应用系统管理员无法直接获取，在接收到日志时，该模块将解密后的用户名密码提交给数据交互模块，完成日志的提交；

数据交互模块：使用MongoDB的驱动API开发，将接收到的日志写入到MongoDB数据库中；其它数据库交互模块与此类似。

Java类应用系统接入日志管理系统的流程如图8所示：

应用标识分配：在应用系统接入时，日志管理系统服务端给应用系统分配应用标识，并根据IP地址白名单，对应用系统进行审核，其中，IP地址白名单中包括了允许接入的IP地址，即只有当IP地址白名单中包括该应用系统的IP地址时，该应用系统才被允许接入。

日志转发代理配置：在应用服务器上部署本发明实施例提供的日志转发代理，即在应用系统对应的J2EE容器上配置数据源，该数据源确保应用系统只能insert日志到数据库，而不能修改删除日志。

日志采集代理部署和初始化：在应用系统中部署日志采集代理，并做好初始化相关配置。

应用系统改造：在应用系统引入日志采集代理后，对应用系统进行相应改造以实现调用日志采集代理发送日志。

日志采集和集中存储：应用系统通过日志采集装置将日志发送到数据库服务器，数据库服务器将各个应用系统的日志集中存储，并提供查询、统计和分析利用。

以合同系统为例说明Java应用的日志采集过程。

第一步：在合同系统接入时，服务端合同系统分配的应用标识是contract，并根据IP地址白名单，验证应用系统端是否按照既定的规范接入。

第二步：在合同系统所在的J2EE容器上加载本发明实施例所提供的MongoDB数据源，使得日志采集代理通过日志转发代理以只写的方式访问数据库。

第三步：合同系统改造：

合同系统的应用日志。首先，需要对整个项目进行配置，引入日志采集代理，依赖并修改相关配置文件，使得合同系统可以调用统一日志的API；然后，在审批操作的服务方法中构造一个日志对象并调用API接口发送该对象。

合同系统的运行时日志原本采用log4j记录，日志文件保存在本地磁盘的文件系统中。接入日志管理系统时，修改配置文件中的配置参数，以能够将运行时日志导入日志管理系统。

对于非J2EE系统，例如PHP应用环境，日志采集的方式与Java应用的日志采集方式是类似的，不再赘述。

2、封闭型应用系统

对于封闭型无法做改造开发的应用系统，可使用独立的日志采集代理来完成。

针对封闭型应用系统的日志采集代理的架构图见图9，其架构与图5类似，以下仅对其特有部分加以说明：

日志抓取模块：根据应用系统的日志提供方式，获取日志，供下一步使用。抓取方式主要是访问数据库、解析日志文件或使用应用系统日志API等多种方式。

例如Domino邮件操作日志、EMCIRM文档安全系统操作日志和文档操作日志的采集，由日志采集装置定时抓取，并转换为统一日志中的日志类型，发送至统一日志服务器：

针对Domino邮件系统，日志采集装置可以部署在单独的接口机上，也可以部署在日志管理系统上，使用Domino的JavaAPI从邮件系统中获取日志记录，每条记录是一个XML文档，将其封装为一个日志对象，然后调用日志管理系统的API保存日志对象。

EMCIRM文档安全系统的系统日志以XML文件的形式保存在服务器上，日志采集装置通过HTTP方式获取XML文件并进行解析和上传。而EMCIRM文档安全系统的应用日志则保存在数据库中，日志采集装置通过数据库接口获取并保存日志记录。

本发明实施例提供的日志管理系统架构非常简单，可以充分利用无模式的数据库，例如NoSQL数据库的高性能和易扩展的特性，在访问量增大时，只需对NoSQL数据库群集进行扩展即可满足要求。相对于传统的“应用服务器+数据库”的日志管理系统架构，本发明实施例提供的日志管理系统的架构对硬件资源的需求及架构复杂性要求大幅度降低，在系统架构设计、系统部署、扩展和运维方面，极大地降低了难度和工作量。

当选择MongoDB作为日志管理系统的数据库服务器，还可以利用MongoDB的分片和复制集的架构。分片是MongoDB数据库系统水平扩展的技术，而复制集提高了系统的可靠性和数据冗余备份。系统规模扩大时，可以通过增加分片进行水平扩展以满足性能要求，分片内的复制集可以设置为主从读写分离从而提高读写性能。

在应用系统接入时，日志管理系统需要分配应用和模块的标识，并做好接入系统的审核工作，验证应用系统是按照既定的规范接入日志管理系统的。日志管理系统无需变更表设计，也无需进行日志的过滤和格式化，整个配合工作非常简单。

本发明实施例也可支持其它的NoSQL数据库，一般来说，常见的NoSQL数据库都具有较好的性能、可靠性和扩展性，如果使用其它的NoSQL数据库，应用系统的接入以及日志管理系统本身的性能、扩展性和可靠性保障与本发明实施例所述内容类似，不再赘述。

关系型数据库本身以二维表的存储数据，在做查询统计尤其是按条件和分组查询时非常方便；而MongoDB本身是一个文档型的数据库，每条日志记录是一个文档，当要求输出二维表格式的查询统计结果时，相对于关系型数据库而言代码量稍大一些。

因此，为了更方便地查找日志，本发明实施例提供的日志管理系统中数据库服务器包括：无模式的数据库和统计数据库，二者在同一个MongoDB集群中，分属于不同的库，类似于一个ORACLE实例的两个用户或Schema。根据既定的统计规则编写脚本执行生成统计数据。

如果统计分析的需求很明确，在做日志收集的过程中，即可生成中间数据，系统定时或实时整理新增的数据，根据统计目标产生中间数据，查询或统计时直接从中间表计算统计结果，使得查询的效率有大幅提升。

经过验证，使用MongoDB作为数据库之后，对于日志管理系统的统计应用是增加了开发工作量的，对于应用系统的接入，是节省了工作量的。

以邮件系统为例，接入本发明实施例的日志管理系统，比接入现有的使用ORACLE的日志管理系统，其集成开发的工作量分别为：

统计分析方面增加的工作量大约是5人天，而前面应用集成的时节省的工作量是15人天，整体接入比使用ORACLE的日志管理系统节约了大约25％的工作量。

邮件系统、统一流程系统的日志记录示例如图10至图13所示。

本发明还提供了一种日志采集方法，如图14所示，具体包括：

步骤S1400，第一接收步骤：通过日志接口接收数据源发送的具有不同格式的日志；

步骤S1402，日志持久化步骤：将具有不同格式的日志发送至数据库服务器，以使得所述数据库服务器将所述具有不同格式的日志存储至无模式的数据库。

上述日志采集方法，其中，在所述日志持久化步骤之前还包括：第二接收步骤：接收一日志操作指令；判断步骤：判断所述日志操作指令是否为将所述日志写入数据库服务器的指令；所述日志持久化步骤进一步在所述判断步骤判定所述日志操作指令为将所述日志写入数据库服务器的指令时，将具有不同格式的日志发送至所述数据库服务器。

上述日志采集方法，其中，所述数据库服务器的无模式的数据库的用户名和密码经过加密后存储，所述日志持久化步骤之前还包括：解密步骤：将所述加密后的用户名和密码进行解密；所述日志持久化步骤进一步在所述判断步骤判定所述日志操作指令为将所述日志写入数据库服务器的指令时，将解密后的用户名和密码及预处理后具有不同格式的日志发送至所述数据库服务器，以使得所述数据库服务器根据解密后的用户名和密码将所述具有不同格式的日志存储至无模式的数据库中。

上述日志采集方法，其中，所述日志持久化步骤之前还包括：预处理步骤：对所述日志配置用于标识生成所述日志的数据源的参数，并根据预设规则对所述日志进行过滤；所述日志持久化步骤进一步将经过过滤后的具有不同格式的日志发送至所述数据库服务器。

上述日志采集方法，其中，还包括：异常处理步骤：分析所述日志采集装置与所述数据库服务器的链接是否符合预设指标，并在不符合时发送告警信息；所述日志持久化步骤进一步在所述异常处理步骤确定所述日志采集装置与所述数据库服务器的链接不符合预设指标时，将具有不同格式的日志存储至缓存模块。

上述日志采集方法，其中，所述日志持久化步骤之前还包括：获取步骤：从数据源中抓取具有不同格式的日志。

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明所述原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (13)

1.一种日志管理系统，其特征在于，包括：多个数据源、数据库服务器、日志采集装置，其中，

多个数据源，用于生成具有不同格式的日志；

所述数据库服务器包括：

无模式的数据库，用于存储具有不同格式的日志；

所述日志采集装置包括：

日志接口模块，用于为所述多个数据源提供日志接口，以使得所述多个数据源通过所述日志接口，将具有不同格式的日志发送至所述日志采集装置；

日志持久化模块，用于将具有不同格式的日志发送至所述数据库服务器，以使得所述数据库服务器将所述具有不同格式的日志存储至无模式的数据库中。

2.如权利要求1所述日志管理系统，其特征在于，所述日志采集装置还包括：日志转发代理模块，

所述日志持久化模块，用于通过所述日志转发代理模块将具有不同格式的日志发送至所述数据库服务器；

所述日志转发代理模块包括：

接收子模块：用于接收日志操作指令及所述日志持久化模块发送的具有不同格式的日志；

数据安全子模块，用于判断所述日志操作指令是否为将所述具有不同格式的日志写入数据库服务器的指令；

数据交互子模块，用于在所述数据安全子模块判定所述日志操作指令为将所述具有不同格式的日志写入数据库服务器的指令时，将具有不同格式的日志发送至所述数据库服务器。

3.如权利要求2所述日志管理系统，其特征在于，所述数据安全子模块进一步用于存储经过加密后的所述无模式的数据库的用户名和密码，并在所述接收子模块接收到具有不同格式的日志后，将所述加密后的用户名和密码进行解密；

数据交互子模块，进一步用于在所述数据安全子模块判定所述操作指令为将所述具有不同格式的日志写入数据库服务器的指令时，将解密后的用户名和密码及具有不同格式的日志发送至所述数据库服务器，以使得所述数据库服务器根据解密后的用户名和密码将所述具有不同格式的日志存储至无模式的数据库中。

4.如权利要求1所述日志管理系统，其特征在于，所述日志采集装置还包括：

日志预处理模块，用于对所述具有不同格式的日志配置用于标识生成所述具有不同格式的日志的数据源的参数，并根据预设规则对所述具有不同格式的日志进行过滤；

所述日志持久化模块，进一步用于将经过过滤后的具有不同格式的日志发送至所述数据库服务器。

5.如权利要求1所述日志管理系统，其特征在于，所述日志采集装置还包括：异常处理模块及缓存模块，

所述异常处理模块，用于分析所述日志采集装置与所述数据库服务器的链接是否符合预设指标，并在不符合时发送告警信息；

当所述异常处理模块确定所述日志采集装置与所述数据库服务器的链接不符合预设指标时，所述日志持久化模块进一步用于将具有不同格式的日志存储至缓存模块。

6.如权利要求1所述日志管理系统，其特征在于，所述数据库服务器还包括：

统计数据库，用于存储根据预设的统计规则脚本及所述无模式的数据库中存储的具有不同格式的日志生成的统计数据。

7.如权利要求1所述日志管理系统，其特征在于，所述日志采集装置还包括：日志抓取模块，用于从多个数据源中抓取具有不同格式的日志。

8.一种日志采集方法，其特征在于，包括：

第一接收步骤：通过日志接口接收数据源发送的具有不同格式的日志；

日志持久化步骤：将具有不同格式的日志发送至数据库服务器，以使得所述数据库服务器将所述具有不同格式的日志存储至无模式的数据库。

9.如权利要求8所述方法，其特征在于，在所述日志持久化步骤之前还包括：

第二接收步骤：接收一日志操作指令；

判断步骤：判断所述日志操作指令是否为将所述具有不同格式的日志写入数据库服务器的指令；

所述日志持久化步骤进一步在所述判断步骤判定所述日志操作指令为将所述具有不同格式的日志写入数据库服务器的指令时，将具有不同格式的日志发送至所述数据库服务器。

10.如权利要求9所述方法，其特征在于，所述数据库服务器的无模式的数据库的用户名和密码经过加密后存储，所述日志持久化步骤之前还包括：

解密步骤：将所述加密后的用户名和密码进行解密；

所述日志持久化步骤进一步在所述判断步骤判定所述日志操作指令为将所述具有不同格式的日志写入数据库服务器的指令时，将解密后的用户名和密码及预处理后具有不同格式的日志发送至所述数据库服务器，以使得所述数据库服务器根据解密后的用户名和密码将所述具有不同格式的日志存储至无模式的数据库中。

11.如权利要求8所述方法，其特征在于，所述日志持久化步骤之前还包括：

预处理步骤：对所述具有不同格式的日志配置用于标识生成所述具有不同格式的日志的数据源的参数，并根据预设规则对所述具有不同格式的日志进行过滤；

所述日志持久化步骤进一步将经过过滤后的具有不同格式的日志发送至所述数据库服务器。

12.如权利要求8所述方法，其特征在于，还包括：

异常处理步骤：分析所述日志采集装置与所述数据库服务器的链接是否符合预设指标，并在不符合时发送告警信息；

所述日志持久化步骤进一步在所述异常处理步骤确定所述日志采集装置与所述数据库服务器的链接不符合预设指标时，将具有不同格式的日志存储至缓存模块。

13.如权利要求8所述方法，其特征在于，所述日志持久化步骤之前还包括：

获取步骤：从多个数据源中抓取具有不同格式的日志。