基于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 結語

本文通過調整日志模塊的結構,將日志模塊按等級和用途分類,重新定義日志記錄的描述方式,規范日志記錄,提高日志記錄的信息有效性。不但提高了軟件的開發質量,而且提高了問題分析和查找的效率,使得通過日志查找、定位、分析、解決問題的能力不再受制于開發人員。軟件維護人員,甚至到運營維護人員也可以通過規范、清晰易懂的語言描述,快速查找定位問題。