CN110275817A - 一种基于模型驱动的日志文件自动生成方法 - Google Patents

Abstract

本发明提出一种基于模型驱动的日志文件自动生成方法，属于软件体系结构建模和日志文件自动生成相结合的领域。包括：基于软件体系结构建模思想，对应用程序各层功能组成进行编码，采用自动化映射方式替换包含应用系统内部定义的日志信息。然后截获相应操作行为对应的用户信息，与其它必要的系统说明信息一起生成日志内容，以log文件或数据库文件的形式进行存储。同时，可通过修改配置文件的方式任意开始或停止日志信息的收集工作，也可根据实时需要对现有日志信息进行扩展或删减。本发明实现了日志系统与应用系统的物理分离与逻辑独立，而且保证了日志内容的全面、详实、可扩展性，可帮助维护应用系统，提高后续数据分析工作效率。

Description

一种基于模型驱动的日志文件自动生成方法

技术领域

本发明属于软件体系结构建模和日志文件自动生成相结合的领域，涉及软件体系结构建模过程中应用日志文件的规定与生成，具体涉及一种基于模型驱动的日志文件自动生成技术。

背景技术

随着人工智能、数据挖掘、推荐系统、软件工程等技术的逐步发展，越来越多的应用软件选择需要收集更加多维、更加全面的应用程序信息与用户行为信息来更好地了解应用程序及平台用户的动态，进而为应用使用者提供更好的服务，也为应用维护者的工作提供便利。而日志系统作为收集应用程序动态信息的主要渠道，如何能规范、扩展现有日志模式，丰富日志内容，并提供具有普适性、平台无关性的日志系统，具有极其重要的工程意义，也是必须要面对的问题。针对web应用系统，往往通过系统日志获取多种多样的信息。但随着业务需求的多样化、业务逻辑的复杂性，日志系统记录信息也错综复杂，为后续的应用维护和数据分析、平台优化工作都造成了极大的不便。为了解决这些问题，促进基于应用的新技术的发展，必须要实现一套规范、全面、普适的日志系统。虽然目前已经存在了一些日志生成方法，但它们都存在着一定的局限性，具体表现在如下几个方面：

1、现有web系统日志所包含信息过于简单。现有应用系统日志内容往往侧重于固定、单调的系统信息，而对用户操作行为收集不足，无法为后续系统分析、数据挖掘等工作提供足够的信息基础，落后于目前用户个性化定制服务的发展趋势。

2、难以通过日志内容准确定位应用系统逻辑错误。应用系统中，一个用户操作行为可能涉及多个后台接口。如果系统出现某些运行逻辑问题，即程序语言顺利执行，但执行结果与预期不符。此时，应用系统后台不会报错，通过现有系统日志无法直接定位出现问题的后台逻辑接口。

3、未实现日志系统与应用系统的物理分离。日志系统作为应用系统的一个延伸业务，现有日志系统介于其与应用系统的内容的强耦合，导致日志系统不易分离与迁移，尚未形成一个完整、通用、独立的日志系统。现在的web应用系统越来越强调各业务子系统之间的独立性与通用性，日志系统作为一个不容忽视的子系统，也应具有其独立性，即可任意迁移到其他不同业务的子系统中去的能力。

4、未实现日志系统与应用系统的逻辑分离。现在的日志内容多与应用系统具体业务内容强相关。也许日志文件的分析处理人员并未参与系统本身的开发，这就容易造成分析人员在参与伊始需要花费更多时间去了解业务逻辑以及其中具体的关系，加重分析人员的工作负担。

5、尚未形成统一的日志生成规范。现有应用系统日志格式不一，内容繁杂。在开发过程中，开发人员常因调试需要自行修改日志生成内容，最后造成生成日志内容极不规范，为后续数据分析人员的工作带来很大的挑战。

6、应用软件体系的设计与日志系统的设计实现完全独立，既增大了工作量，又导致本应统一为应用软件体系服务的两部分分离。

在对当前现存的日志文件生成方法及所含内容进行分析后发现，这些方法普遍存在日志信息过于简单、难以通过日志内容准确定位逻辑错误、未实现日志系统与应用系统的物理分离与逻辑分离、尚未形成统一的日志生成规范等问题。为更好地完善日志系统以适应其与新技术的融合，以上问题均亟待解决。

发明内容

为了克服现有方法存在的缺陷，丰富日志内容，增强应用系统逻辑错误的定位能力，实现日志系统与应用系统的物理分离与逻辑分离，并促进日志内容的规范化，本发明提出了一种基于模型驱动的日志文件自动生成方法。

本发明提供的基于模型驱动的日志文件自动生成方法，包括如下步骤：

步骤1，自定义生成对各应用系统的子系统、分模块、各接口的编码规则，并基于高阶类型化软件体系结构建模语言SAML和建模方法SAMM对一般WEB应用软件体系结构进行需求转化、分层建模，支持类型规则自动生成；

所述的步骤1中的编码规则，是对应用系统的子系统、分模块和接口进行重编码；各子系统对应的编码不重复，各子系统中的分模块、各分模块中的不同接口，满足“同父同级兄弟”之间编码不重复的规则。在记录日志文件时，对接口以“子系统名-分模块名-接口名”格式构成的字符串标识，用户操作行为通过编码构成树状结构。

步骤2，获取包含应用系统的动态信息和用户信息，对每条应用系统动态信息都记录对应的执行操作的用户信息；

步骤3，将所获取的应用程序的动态信息，针对每条可行路径中的各子系统、分模块和接口的名称，按步骤1所述的编码规则映射成对应的编码，根据用户需求个性化订制，形成完全面向用户的应用软件体系日志记录；

步骤4，将重编码后的应用程序动态信息、用户信息及必要的系统信息一同以log文件或数据库文件的形式保存，完成日志系统的生成工作。

所述的步骤3中的应用系统动态信息通过截获分析request数据来获取，是客户端请求信息所需执行操作涉及的可行路径。

本发明为了能够应对不同业务场景下web应用程序的日志生成需求，基于软件体系结构建模思想，对应用程序各层功能组成进行编码，采用自动化映射方式替换包含应用系统内部定义的日志信息。然后截获相应操作行为对应的用户信息，与其它必要的系统说明信息一起生成日志内容，以log文件或数据库文件的形式进行存储。同时，可通过修改配置文件的方式任意开始或停止日志信息的收集工作，也可根据实时需要对现有日志信息进行扩展或删减。相对于现有技术，本发明的优点与积极效果在于：

(1)本发明所生成日志内容包含应用的系统信息、运行信息、用户信息、用户操作信息等多种数据，为后续数据挖掘、用户推荐等工作提供了全面的数据基础；

(2)日志内容包含应用系统的子系统、分模块，并具体到逻辑实现的接口级。同时，可以通过修改配置文件的简单操作，任意开始或暂停日志收集工作。如图4所示，一次用户行为涉及到的所有调用关系信息都将被保存，日志系统记录的信息更加详实、立体。用户行为工作人员可通过日志内容快速定位应用系统的逻辑故障，本发明中提供的全面、详细、灵活的日志记录为应用程序的调试和维护提供了极大便利；

(3)本发明实现了日志系统与应用系统的物理分离。本发明为基于web应用系统的日志自动生成，但绝不依赖于任何一种web应用系统场景，具备独立性，可任意迁移到任何其它web应用系统中。对各种不同场景、不同业务下的web应用系统均具普适性。除此之外，该日志系统还具有良好的扩展性，当现有日志内容不足以满足当下对应用系统的描述需求时，可以根据需要扩展出新的日志内容；

(4)本发明实现了日志系统与应用系统的逻辑分离。本发明采用将应用系统中子系统、分模块、各接口进行重编码的形式，形成应用系统业务逻辑无关的一套表示方法。如图4所示，日志系统中日志内容也采用此套编码规则进行输出保存。这为日志内容的后续分析、数据处理工作提供了便利，后续工作人员无需了解应用系统内部定义，仅需针对日志文件进行分析，节约开发时间。

(5)基于模型驱动的日志生成方式将与系统的具体实现技术无关的功能规范及系统在特定平台上的实现相分离，使系统的核心功能规范不因系统在不同平台上具体实现的不同而改变。同时，软件体系结构模型为生成的日志内容提供了一套统一的规范，也为开发人员提供了日志内容模板，为之后日志内容的修改、扩展的统一性和规范化提供支持。

(6)将应用软件体系的设计与后期日志系统的设计通过模型融合在一起，减少工作量，并将应用软件体系结构从设计到维护的整个生命周期完全统一起来。

附图说明

图1为本发明提出的基于模型驱动的日志生成方法流程图；

图2为本发明中获取requset请求信息的方法流程图；

图3为未使用本发明时某系统的日志文件内容的一段截取示例图；

图4为使用本发明后某系统的日志文件内容的一段截取示例图。

具体实施方式

下面将结合附图和实施例对本发明作进一步的详细说明。

本发明提出了基于模型驱动的日志文件自动生成方法，规定应用系统中子系统、分模块、各接口的编码映射关系，获取应用系统动态信息、用户信息及必要的系统信息，并根据映射规则生成日志内容，以log文件或数据库文件的形式进行保存，实现日志系统的自动生成工作。该方法的核心思想是：

1)基于软件体系结构建模结果自定义应用系统各层组成部分的编码规则，采用自动化映射方法使日志内容独立于应用系统内部定义，但保持应用系统内部逻辑关系。这种解耦合的方式能够提升日志系统的应用范围，使得使用者可以根据业务需求灵活修改用户日志格式。

2)所采用的日志系统可生成包含应用系统动态信息、用户信息等完整的日志内容，并可通过配置文件任意开始或停止日志信息的收集工作，随时依据需要增加或减少日志内容条目，灵活性高；

3)通过对此套日志系统的封装，实现独立于应用系统的应用场景及业务逻辑的一套完整的基于模型驱动的日志文件的自动生成，对于不同业务场景，该日志系统均具通用性；

4)最终生成的日志内容可以用控制台打印、保存至log文件或数据库文件等多种方式输出，实现实时和长期的信息展现。

本发明通过以上几个关键设计思想实现的整套解决方案，将应用软件体系结构的日志生成和应用软件体系结构的设计结合在一起，即在设计阶段就根据SAML和SAMM形成一套包含应用软件体系结构构成需求和业务流程需求在内的系统设计表示，并同时解析生成XML描述文件，直接引用到日志生成里去，实现了日志系统与应用系统的物理分离与逻辑独立，而且保证了日志内容的全面、详实、可扩展性，可帮助维护应用系统，提高后续数据分析工作效率，总体实现了基于模型驱动实现日志系统自动生成的一种方法。

如图1，是本发明的基于模型驱动的日志文件自动生成方法的一个实施流程，下面说明各实现步骤。

步骤1，基于软件体系结构建模自定义的方式及BNF(巴斯克范式)，生成对应用系统各级功能组成的编码映射文件。

目前现存的日志系统普遍存在应用系统日志内容与应用系统内部定义强耦合的问题，后续的数据分析工作对于未参与应用系统开发过程的工作人员来讲，变得很棘手。为了解决此问题，本发明中提出一种编码规范，对应用系统的子系统、分模块、各接口进行重编码，通过编码表示应用系统各级功能组成。

本发明的重编码规则，基于高阶类型化软件体系结构建模语言SAML(SoftwareArchitecture Modeling Language)和建模方法SAMM(Software Architecture ModelingMethod)的基础生成。采用这个理论，即可对一般WEB应用软件体系结构进行需求转化、分层建模，支持类型规则自动生成。

根据应用软件体系结构刻画的目标及验证的特点，一般WEB应用软件体系结构需求可分为两部分，即结构构成需求和业务流程需求。

对于结构构成需求，将用户原始需求按照系统、子系统、模块的层次结构进行划分，使用SAML中的类型以及聚合关联关系对每个需求进行描述，例如，若某子系统层需求记作模块层需求记作两者间的聚合关系记作AggRelation表示聚合关系。

对于业务流程需求，针对结构构成需求中的每个子系统及模块下都有相应的功能设计，每个功能对应一定的方法，并包含方法的调用关系。其中，功能及方法使用与结构构成相同的方法表示，调用关系使用可达路径表示。由给定的Microsoft Visio模具画出可调用图，使用宏转换成XML文件，并经过解析生成。例如，某子模块的功能实现包含三个方法，分别记作且可调用 可调用经过调用图的转换，可生成一条可达路径表达式

结合上述两种需求转化，即可得到一棵按照系统、子系统、子模块、方法顺序、自顶向下的需求树及可达路径列表。

在利用SAML和SAMM进行建模时，为更简洁、方便地表述功能调用，需要对子系统层、模块层、接口层进行规范性编码。接口层中的每个一个接口是一个方法的接口，通过接口来表示方法调用关系。

为了尽可能的将建模方法与业务逻辑进行解耦，使得编码规则更加通用并且尽可能兼容复杂场景的描述，本发明中的编码规则基于BNF进行设计定义，其目的是为了解除编码规则与业务应用间的耦合，以抽象的、无二义性的规则去描述场景，同时增强规则本身的可扩展性。

具体编码规则上，对各子系统级别编码需要遵循单射规则，即各子系统对应编码不能重复。但对各子系统中的分模块，各分模块中的不同接口，只需满足“同父同级兄弟”之间编码不重复，而针对各“异父同级兄弟”之间编码的重复性不做要求。在日志内容生成时，可以通过以“子系统名-分模块名-接口名”格式构成的字符串具体标识某一接口，满足无二义性描述要求。用户操作行为通过编码构成树状结构，可标识各层级唯一性。

为方便理解，现结合业务场景举例说明，如对某政务系统，其中的“文化子系统”可编码成“Sy1”；此子系统下的“网上图书馆”模块可编码成“Mo1”；此子模块下的“获取图书列表”接口可编码成“Int1”，如此即可使用“Sy1_Mo1_Int1”唯一描述此条调用路径，表示用户在文化子平台的网上图书馆查看了图书列表。同时，同一政务系统的“政策法规子系统”可编码成“Sy2”；该子系统下的“行业政策”子模块可编码成“Mo1”；该子模块下的“查看政策列表”接口可编码成“Int1”。虽然子模块和接口编码均与文化平台编码重复，但通过“Sy2_Mo1_Int1”即可具体标识此条路径代表用户在政策子平台的行业政策查看了政策列表。采用上述各层级编码拼接方式，使得对于不同平台的同名API无歧义。

此套基于模型的编码规则即可延用至日志系统，如此可以保持系统设计与实现的统一性。“子系统-模块-接口”层级关系基本可以涵盖现在常用的应用程序实现逻辑，但保证系统的灵活性，具体编码范围可依不同应用系统实现而定。比如，若实际应用系统存在除“子系统-模块-接口”之外的组成层级，可按具体需求自定义扩展新的编码规则，最终组成一条至上而下的可循路径即可。

本发明获得的可达路径列表就是日志所要记录的内容，是从应用软件体系结构的角度出发，从需求阶段就开始建模的工作。

步骤2，获取包含应用系统的动态信息，用户信息等在内的日志文件所需信息。

本发明中获取应用系统动态信息是基于日志记录工具——Apache Log4j实现的。通过使用Log4j，可以控制日志信息输送的目的地是控制台、文件、GUI(图形用户界面)组件、甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；也可以控制日志的输出格式；通过定义日志信息的级别，能够将日志信息按级别分类存储。而以上操作均可通过修改一个配置文件实现。

如图2所示，为本发明中获取requset请求信息的方法流程。本发明通过截获分析request数据来获取用户的请求信息。在使用HTTP协议实现应用间接口通信时，服务端读取客户端请求过来的数据，只允许读取一次，无法多次读取。由于在日志采集时需要读取客户端请求信息，同时该请求信息在之后的应用逻辑还需要继续使用。本发明采用读取request再重新封装供后续逻辑使用的方式解决，即使用HttpServletRequestWrapper来包装HttpServletRequest，在MAPIHttpServletRequestWrapper中初始化读取request的InputStream数据，以byte[]形式缓存在其中，然后在Filter中将request转换为包装过的request。如此，便可以截获到所需解析的request数据。然后，通过request.getRequestURI()方法获取到执行该请求的操作涉及的可行路径。

本发明生成的每条应用系统动态信息记录都有与之对应的执行该操作的用户信息。为获取具体用户信息，本发明采用MDC(Mapped Diagnostic Context，映射调试上下文)技术。MDC是log4j和logback提供的一种方便在多线程条件下记录日志的功能。MDC中包含的内容可以被同一线程中执行的代码所访问。当前线程的子线程会继承其父线程中的MDC的内容。当需要记录日志时，只需要从MDC中获取所需的信息即可。MDC内部使用了类似map的机制来存储信息，利用MDC.put(key,value)来获得所需信息；在配置PatternLayout的时候使用：％x{key}来输出对应的value即可。此处的key指的是信息的名字，value指的是信息的取值。

为更好地对用户进行个性化分析，日志的内容并不是简单地增量生成，用户可根据自己的需求个性化订制日志内容。用户可修改范围包括日志的格式、日志的内容、日志的生成方式、日志的生成时间(一天一个文件或者文件到达一定大小后生成新的文件等)等。日志的格式、日志的生成方式、日志的生成时间都只需修改配置文件中的参数即可。日志的内容删除也可以通过修改配置文件中的参数，增加和修改需要同时在另外一个java文件中按固定格式存放。

步骤3，将所获取的日志内容以按编码规则映射后的新编码呈现，形成日志记录。

步骤1中的XML文件保存了日志内容编码规则。为方便统计及展示，将XML文件导入Excel文件中。Excel文件主要包含两列，第一列即应用系统各级功能的原名称，如“Culture”；第二列即与第一列分行对应的应用系统各级功能的新名称，如“Sy1”。

利用Apache POI从Excel文件中读取含有各子系统、模块及重要接口的编码规则并存储进HashMap中。HashMap是基于哈希表的Map接口的实现，以Key-Value的形式存在。此处HashMap中存储的Key为应用系统各级功能的原名称，Value为应用系统各级功能的新名称。

对于步骤2中获取的应用系统的动态信息，针对每条可行路径，利用”/”进行分割获取各层级名称，各层级依照HashMap中存储的编码规则通过替换操作以新编码标识。如，原日志内容为“Culture-Books-getBookList”，代表用户在文化平台网上图书馆部分进行获取图书列表操作，经过基于BNF的编码规则映射，将以“Sy1_Mo1_Int1”的新编码形式替换掉旧版编码，并存储至日志文件中。

步骤4，将获取到的将重编码后的应用程序动态信息、用户信息及必要的系统信息进行拼接，生成日志记录并按需要的方式进行输出或存储。

借用Apache Log4j，日志将通过控制台打印和保存至文件两种形式输出。控制台将按时间顺序打印出所有日志信息。日志文件保存包括两种文件格式，分别为Log文件和数据库文件。

对于Log文件，将对日志信息进行分类保存，具体可分为三种类型——all、info、error。其中，all文件保存所有日志信息记录；info文件保存所有应用程序访问行为信息记录；error文件保存应用程序错误信息。同时，可以通过修改Apache Log4j的配置文件简单方便地开始或停止收集日志进程。日志文件按各子系统的不同，分别保存在各子系统对应目录下，如此应用程序日志可按各子系统分开存取。日志文件的生成方式多样，可按时间生成，即每天生成一个新的日志文件；也可按文件大小生成，即当日志文件大小到达一定容量阈值时，自动生成新的日志文件，并将新的记录继续保存至新文件中。而对于数据库文件，将直接按照时间戳进行存储。数据库文件将极大方便后续数据分析过程中对数据的增删查改操作，也将利于后续数据的可视化图形呈现及数据处理工作。

如图3所示，为某系统现有的一段日志文件内容，只记录了系统信息，而且，除error信息之外，不会具体到接口级的记录。利用本发明方法来对该系统进行记录，如图4所示，是按照应用系统的组成层级，根据编码规则将用户操作行为构成树状结构记录，记录信息包括从上之下的子系统、模块、接口等信息。由于本发明的日志文件保留了接口调用信息，所以能为定位逻辑错误提供了便利。

Claims (3)

1.一种基于模型驱动的日志文件自动生成方法，其特征在于，包括如下步骤：

步骤1，基于模型自定义生成对各应用系统的子系统、分模块、各接口的编码规则；

在WEB应用软件的设计阶段，将软件体系结构需求分为结构构成需求和业务流程需求，在结构构成需求方面，将用户需求按照系统、子系统、模块的层次结构进行划分，在业务流程需求方面，针对结构构成需求中的每个子系统及模块下都有相应的功能设计，每个功能对应一个方法，并包含方法的调用关系；根据业务流程需求的调用关系图获取XML文件，解析XML文件获得可达路径列表；可达路径列表就是日志所要记录的内容；

所述的编码规则是对应用系统的子系统、分模块和接口进行重编码，保存在一个Excel文件中；各子系统的编码不重复，各子系统中的分模块、各分模块中的不同接口，满足“同父同级兄弟”之间编码不重复的规则；在记录日志文件时，对接口以“子系统名-分模块名-接口名”格式构成的字符串标识，用户操作行为通过编码构成树状结构；

步骤2，通过截获分析request数据来获取客户端的请求信息，获得执行该请求的操作可行路径，并记录执行操作的用户信息；

步骤3，对获取的每条操作可行路径，对其中的各子系统、分模块和接口的名称，利用所述的编码规则映射成对应的编码，形成日志记录；

步骤4，将重编码后的应用程序动态信息、用户信息及必要的系统信息一同以log文件或数据库文件的形式保存。

2.根据权利要求1所述的方法，其特征在于，所述的步骤1中，若应用系统存在除“子系统-模块-接口”之外的组成层级，按需求扩展新的编码规则，最终对应用系统的组成层级形成一条至上而下的路径。

3.根据权利要求1所述的方法，其特征在于，所述的步骤3中，利用Apache POI从步骤1所述的Excel文件中读取各子系统、模块及接口的编码规则，并存储进HashMap中，对于步骤2中获取的应用系统的动态信息，针对每条可行路径，利用“/”进行分割获取各层级名称，各子系统、分模块和接口依照HashMap中存储的编码规则通过替换操作以新编码标识。