基于TIAS 系统的软件日志记录方法

李骊

(西安市轨道交通集团有限公司建设分公司,陕西西安 710018)

0 引言

北京地铁6号线于2012年12月30日正式开通运营,是国内首条采用TIAS(行车综合自动化系统)的线路。而正在建设中的北京3号线、12号线、17号线及19号线,其上层监控系统也都采用了T1AS[1]。TIAS 将自动列车监控系统(ATS)和综合监控系统(ISCS)深度集成,即集成了信号、机电、电力、通信等不同业务的应用功能,提供统一的人机界面,具有丰富的跨系统联动功能,极大地提高了调度的工作效率[1]。

日志记录作为TIAS 中不可或缺的功能,是目前最常见的故障信息载体[2],在故障问题分析和查找中发挥着重要作用。一般日志模块,仅提供日志文件名称、文件存储位置、文件大小、日志描述字符串、日志记录时间等接口。日志模块的使用人员通过设置日志文件名称、位置、大小对日志模块进行初始化操作后,通过写日志接口传递字符串描述参数,完成一条日志的记录。

由于上述方法仅以一个字符串参数描述日志的记录,未对日志记录的格式做出规范,因此受制于开发人员的编程习惯等因素,日志记录格式各异,当软件出现问题时,无法准确快速的定位问题。

开发人员用于软件自测跟踪、调试的日志,多数情况下,在软件正式上线后,应该屏蔽。但由于开发人员疏漏,这些日志在软件正式上线后,没有被删除或者屏蔽,导致这些日志被记录到了上线软件的日志中,与其他需要真正记录系统错误、警告等的日志混淆在一起,影响日志记录的有效性。

1 方案设计

1.1 日志模块中添加日志等级

按等级,将日志信息分为四类,分别为Debug级、Info级、Warn级、ERROR级、FATAL 级。Debug级,打印状态信息、提示信息等,以便开发过程中跟踪、调试,开发完成、正式上线后,日志系统将自动屏蔽这些信息的记录日志;Info级,记录应用中正常但有意义和有价值的事情,如用户登陆、数据库查询语句等;Warn级,属于比较轻微的“告警”,程序出现这些异常,影响不大,可以正常使用,程序正式上线后,日志系统将这些信息写入记录日志中;Error级,属于普通“错误”,不需要立即被处理,不会造成一连串的影响或巨大影响,但需要被记录且监控,程序正式上线后,日志系统将这些信息写入记录日志中;FATAL 级,属于严重的“错误”,如导致程序功能损坏,宕机等,程序正式上线后,日志系统将这些信息写入记录日志中。

日志文件格式如下:

程序名称—模块名称—自定义—等级名称.log

1.2 设计日志记录格式

通常我们做记录时,一般包括时间、地点、人物、事件、类型、等级等要素,因此,一条规范的日志记录,应包括序号、日期,程序名称、程序模块、等级名称、记录描述等,其中序号、日期,程序名称、程序模块、等级名称是一个日志记录不可或缺的。日志系统在设计时,一般也都会设计这部分。但记录描述,为了考虑其可扩展性和灵活性,一般仅以字符串作为输入参数,这就造成记录描述根据个人习惯去任意书写,记录描述五花八门,没有固定的格式,更没有标识易于日志查阅和分析。如图1 所示。

图1 传统日志记录Fig.1 Traditional logging

清晰的规范的记录描述,应有明确标识,规范化的语言,如图2所示。

图2 清晰的规范的日志记录Fig.2 Clear and canonical logging

为了满足不同日志记录格式的需求,规范日志记录格式的灵活性,增加记录模板。以规范日志的记录格式,便于阅读和查找。

记录模板由记录项列表组成,其中记录项包括记录描述、记录类型、记录数据三部分。日志系统对外写日志的接口参数由原来的字符串改为记录项列表。

如图2所示。记录模板的记录项列表如表1。

表1 记录项列表Tab.1 List of record items

为保证记录模板的可扩展性,“记录类型”除了字符串,整型外,也可以是布尔类型、浮点类型等常用数据类型。

当日志系统启动时,首先加载记录模板。当日志系统接收到新的记录项列表后,首先在记录模板中按“记录描述”字段进行查找,如果新记录项列表的描述在日志模板的描述中均被找到,则按照以下格式打印在日志中,否则不打印。

1.3 日志模块中添加调试开关

调试开关主要用于程序自测和调试。当程序开发阶段,调试阶段或者允许现场调试时,可以打开调试开关,显示Debug级、Info级、Warn级、ERROR级、FATAL级日志。调试开关默认为关闭状态。当程序正式运营后,关闭调试开关。

考虑到程序员的编写习惯和日志系统的灵活性,Debug级日志可以无需做规范性日志书写原则,因此不需在记录模板中进行记录字段的合法性检查,即可调试开关开放时,打印在日志中。

2 方案关键点

本方案技术关键点在于:(1)日志信息按等级划分,结合调试开关,可以使程序在正式上线后,自动屏蔽掉不必要的日志记录信息。可按等级查找问题,提高问题查找速度。(2)采用记录模板的方式,不但能灵活的添加各种记录字段描述,还可以规范日志打印格式。(3)写日志接口采用记录项作为参数,日志模块对输入参数以模板中记录的描述为参考进行筛选,防止开发人员随意输入日志描述。

3 日志系统结构设计

日志系统包括日志记录模块、日志检查模块、日志模板管理模块、日志输出模块四大部分。

日志记录模块主要负责日志的创建和日志记录管理(LogManager),由LogManager对象根据不同程序名称,模块名称,等级名称接收各种日志信息的日志对象。并同步将日志分派给日志检查模块。

日志检查模块主要负责除Debug级日志以外的其他等级日志合法性的检查。根据日志记录模块分派的日志,依据模板日志中记录项列表中的“记录描述”,检查日志记录的合法性,并将合法日志传输到日志输入模块。

日志管理模块主要负责日志记录项列表的增加、删除和修改以及存储。

日志输出模块则负责日志输出器(Appender)的创建和管理,以及日志的输出。系统中允许有多个不同的日志输出器,日志输出器负责将日志记录到存储介质当中。

系统结构如图3 所示。

图3 系统结构图Fig.3 System structure diagram

LogManager是整个日志系统结构的用户使用接口,程序员可以通过该接口记录日志。为了实现对日志进行分类,系统设计允许存在多个LogManager对象,每一个LogManager 负责一类日志的记录,如程序名称、程序模块、等级名称、自定义类型等属性。LogManager类同时实现了对其对象本身的管理,在客户端创建和发送日志时,这些属性会被使用到。LogManager对象在接收到客户端创建和发送的日志消息时,同时将该日志消息包装成日志系统内部所使用的日志对象LogItem,Debug级的日志对象除了发送端所发送的消息以外,还会包装诸如发送端类名、发送事件、发送方法名、发送行号等。这些额外的消息对于系统的跟踪和调试都非常有价值。包装好的LogItem最终被发送给日志输出器(Appender),由这些日志输出器负责将日志信息写入最终媒介,输出器的类型和个数均不固定,所有的输出器通过日志输出器管理对象进行管理,通常通过配置文件即可方便扩展出多个输出器。

4 方案优点

本方案具有以下优点:

(1)避免软件自测跟踪、调试的日志被打印到了正式上线的软件日志中。

(2)通过日志记录格式,规范日志打印格式,提高问题查找和分析的速度。

5 方案示例

以下为日志打印记录

42 25.07.2020.10.22.020 [初始化]开始加载设备状态配置文件

46 25.07.2020.10.22.030 [检查]配置文件

47 25.07.2020.10.22.100 [成功]结束加载设备状态配置文件

49 25.07.2020.10.23.000 [失败]网络连接[IP]191.128..50.101

6 结语

本文通过调整日志模块的结构,将日志模块按等级和用途分类,重新定义日志记录的描述方式,规范日志记录,提高日志记录的信息有效性。不但提高了软件的开发质量,而且提高了问题分析和查找的效率,使得通过日志查找、定位、分析、解决问题的能力不再受制于开发人员。软件维护人员,甚至到运营维护人员也可以通过规范、清晰易懂的语言描述,快速查找定位问题。