李驪
(西安市軌道交通集團有限公司建設分公司,陜西西安 710018)
北京地鐵6號線于2012年12月30日正式開通運營,是國內首條采用TIAS(行車綜合自動化系統(tǒng))的線路。而正在建設中的北京3號線、12號線、17號線及19號線,其上層監(jiān)控系統(tǒng)也都采用了T1AS[1]。TIAS 將自動列車監(jiān)控系統(tǒng)(ATS)和綜合監(jiān)控系統(tǒng)(ISCS)深度集成,即集成了信號、機電、電力、通信等不同業(yè)務的應用功能,提供統(tǒng)一的人機界面,具有豐富的跨系統(tǒng)聯動功能,極大地提高了調度的工作效率[1]。
日志記錄作為TIAS 中不可或缺的功能,是目前最常見的故障信息載體[2],在故障問題分析和查找中發(fā)揮著重要作用。一般日志模塊,僅提供日志文件名稱、文件存儲位置、文件大小、日志描述字符串、日志記錄時間等接口。日志模塊的使用人員通過設置日志文件名稱、位置、大小對日志模塊進行初始化操作后,通過寫日志接口傳遞字符串描述參數,完成一條日志的記錄。
由于上述方法僅以一個字符串參數描述日志的記錄,未對日志記錄的格式做出規(guī)范,因此受制于開發(fā)人員的編程習慣等因素,日志記錄格式各異,當軟件出現問題時,無法準確快速的定位問題。
開發(fā)人員用于軟件自測跟蹤、調試的日志,多數情況下,在軟件正式上線后,應該屏蔽。但由于開發(fā)人員疏漏,這些日志在軟件正式上線后,沒有被刪除或者屏蔽,導致這些日志被記錄到了上線軟件的日志中,與其他需要真正記錄系統(tǒng)錯誤、警告等的日志混淆在一起,影響日志記錄的有效性。
按等級,將日志信息分為四類,分別為Debug級、Info級、Warn級、ERROR級、FATAL 級。Debug級,打印狀態(tài)信息、提示信息等,以便開發(fā)過程中跟蹤、調試,開發(fā)完成、正式上線后,日志系統(tǒng)將自動屏蔽這些信息的記錄日志;Info級,記錄應用中正常但有意義和有價值的事情,如用戶登陸、數據庫查詢語句等;Warn級,屬于比較輕微的“告警”,程序出現這些異常,影響不大,可以正常使用,程序正式上線后,日志系統(tǒng)將這些信息寫入記錄日志中;Error級,屬于普通“錯誤”,不需要立即被處理,不會造成一連串的影響或巨大影響,但需要被記錄且監(jiān)控,程序正式上線后,日志系統(tǒng)將這些信息寫入記錄日志中;FATAL 級,屬于嚴重的“錯誤”,如導致程序功能損壞,宕機等,程序正式上線后,日志系統(tǒng)將這些信息寫入記錄日志中。
日志文件格式如下:
程序名稱—模塊名稱—自定義—等級名稱.log
通常我們做記錄時,一般包括時間、地點、人物、事件、類型、等級等要素,因此,一條規(guī)范的日志記錄,應包括序號、日期,程序名稱、程序模塊、等級名稱、記錄描述等,其中序號、日期,程序名稱、程序模塊、等級名稱是一個日志記錄不可或缺的。日志系統(tǒng)在設計時,一般也都會設計這部分。但記錄描述,為了考慮其可擴展性和靈活性,一般僅以字符串作為輸入參數,這就造成記錄描述根據個人習慣去任意書寫,記錄描述五花八門,沒有固定的格式,更沒有標識易于日志查閱和分析。如圖1 所示。
圖1 傳統(tǒng)日志記錄Fig.1 Traditional logging
清晰的規(guī)范的記錄描述,應有明確標識,規(guī)范化的語言,如圖2所示。
圖2 清晰的規(guī)范的日志記錄Fig.2 Clear and canonical logging
為了滿足不同日志記錄格式的需求,規(guī)范日志記錄格式的靈活性,增加記錄模板。以規(guī)范日志的記錄格式,便于閱讀和查找。
記錄模板由記錄項列表組成,其中記錄項包括記錄描述、記錄類型、記錄數據三部分。日志系統(tǒng)對外寫日志的接口參數由原來的字符串改為記錄項列表。
如圖2所示。記錄模板的記錄項列表如表1。
表1 記錄項列表Tab.1 List of record items
為保證記錄模板的可擴展性,“記錄類型”除了字符串,整型外,也可以是布爾類型、浮點類型等常用數據類型。
當日志系統(tǒng)啟動時,首先加載記錄模板。當日志系統(tǒng)接收到新的記錄項列表后,首先在記錄模板中按“記錄描述”字段進行查找,如果新記錄項列表的描述在日志模板的描述中均被找到,則按照以下格式打印在日志中,否則不打印。
調試開關主要用于程序自測和調試。當程序開發(fā)階段,調試階段或者允許現場調試時,可以打開調試開關,顯示Debug級、Info級、Warn級、ERROR級、FATAL級日志。調試開關默認為關閉狀態(tài)。當程序正式運營后,關閉調試開關。
考慮到程序員的編寫習慣和日志系統(tǒng)的靈活性,Debug級日志可以無需做規(guī)范性日志書寫原則,因此不需在記錄模板中進行記錄字段的合法性檢查,即可調試開關開放時,打印在日志中。
本方案技術關鍵點在于:(1)日志信息按等級劃分,結合調試開關,可以使程序在正式上線后,自動屏蔽掉不必要的日志記錄信息??砂吹燃壊檎覇栴},提高問題查找速度。(2)采用記錄模板的方式,不但能靈活的添加各種記錄字段描述,還可以規(guī)范日志打印格式。(3)寫日志接口采用記錄項作為參數,日志模塊對輸入參數以模板中記錄的描述為參考進行篩選,防止開發(fā)人員隨意輸入日志描述。
日志系統(tǒng)包括日志記錄模塊、日志檢查模塊、日志模板管理模塊、日志輸出模塊四大部分。
日志記錄模塊主要負責日志的創(chuàng)建和日志記錄管理(LogManager),由LogManager對象根據不同程序名稱,模塊名稱,等級名稱接收各種日志信息的日志對象。并同步將日志分派給日志檢查模塊。
日志檢查模塊主要負責除Debug級日志以外的其他等級日志合法性的檢查。根據日志記錄模塊分派的日志,依據模板日志中記錄項列表中的“記錄描述”,檢查日志記錄的合法性,并將合法日志傳輸到日志輸入模塊。
日志管理模塊主要負責日志記錄項列表的增加、刪除和修改以及存儲。
日志輸出模塊則負責日志輸出器(Appender)的創(chuàng)建和管理,以及日志的輸出。系統(tǒng)中允許有多個不同的日志輸出器,日志輸出器負責將日志記錄到存儲介質當中。
系統(tǒng)結構如圖3 所示。
圖3 系統(tǒng)結構圖Fig.3 System structure diagram
LogManager是整個日志系統(tǒng)結構的用戶使用接口,程序員可以通過該接口記錄日志。為了實現對日志進行分類,系統(tǒng)設計允許存在多個LogManager對象,每一個LogManager 負責一類日志的記錄,如程序名稱、程序模塊、等級名稱、自定義類型等屬性。LogManager類同時實現了對其對象本身的管理,在客戶端創(chuàng)建和發(fā)送日志時,這些屬性會被使用到。LogManager對象在接收到客戶端創(chuàng)建和發(fā)送的日志消息時,同時將該日志消息包裝成日志系統(tǒng)內部所使用的日志對象LogItem,Debug級的日志對象除了發(fā)送端所發(fā)送的消息以外,還會包裝諸如發(fā)送端類名、發(fā)送事件、發(fā)送方法名、發(fā)送行號等。這些額外的消息對于系統(tǒng)的跟蹤和調試都非常有價值。包裝好的LogItem最終被發(fā)送給日志輸出器(Appender),由這些日志輸出器負責將日志信息寫入最終媒介,輸出器的類型和個數均不固定,所有的輸出器通過日志輸出器管理對象進行管理,通常通過配置文件即可方便擴展出多個輸出器。
本方案具有以下優(yōu)點:
(1)避免軟件自測跟蹤、調試的日志被打印到了正式上線的軟件日志中。
(2)通過日志記錄格式,規(guī)范日志打印格式,提高問題查找和分析的速度。
以下為日志打印記錄
42 25.07.2020.10.22.020 [初始化]開始加載設備狀態(tài)配置文件
46 25.07.2020.10.22.030 [檢查]配置文件
47 25.07.2020.10.22.100 [成功]結束加載設備狀態(tài)配置文件
49 25.07.2020.10.23.000 [失敗]網絡連接[IP]191.128..50.101
本文通過調整日志模塊的結構,將日志模塊按等級和用途分類,重新定義日志記錄的描述方式,規(guī)范日志記錄,提高日志記錄的信息有效性。不但提高了軟件的開發(fā)質量,而且提高了問題分析和查找的效率,使得通過日志查找、定位、分析、解決問題的能力不再受制于開發(fā)人員。軟件維護人員,甚至到運營維護人員也可以通過規(guī)范、清晰易懂的語言描述,快速查找定位問題。