基于Open Lab的電信計費數據采集系統開發

黃 淼，徐向藝，馬 麗

（平頂山學院 軟件學院，河南 平頂山 467000）

目前很多電信公司都提供了Open Lab出租業務，由于大型服務器購買昂貴，許多中小型公司都采用租用服務的方式經營。電信公司提供一項叫做Unix服務器的出租業務，需要使用Unix實驗室出租業務的客戶，通過電信公司提供的賬號和密碼遠程登錄指定的Unix機器，并使用Unix服務。電信運營商根據用戶的使用時長進行收費。由于Unix服務器上記錄的用戶登錄日志信息中的數據都是流水賬數據，而且用戶數量較多，使得數據信息量十分龐大。為了得到有序排列的用戶信息數據，為日后計費提供可靠的數據支持，所以非常有必要開發一個數據采集系統，用于采集從Unix服務器上記錄的用戶登錄日志信息中提取與用戶計費相關的信息，以便后期將這些數據轉移到數據庫中存儲為計費做準備[1]。

1 數據采集系統需求分析

1.1 業務需求分析

電信公司通過數據采集系統需要最終得到的關鍵信息是各個用戶的在線時長，然后用來作為電信的收費依據。能夠提供該信息的是Unix服務器自帶的用戶信息記錄日志文件wtmpx。該文件記錄了每次用戶登錄的OS賬號、進程ID、登入時刻、登出時刻和登錄終端機器IP。

數據采集系統客戶端需要對這些采集到的用戶信息成批進行讀取，讀取一批數據后對采集到的成對登錄登出數據進行匹配，然后將匹配成功的數據信息發送給數據采集服務器。匹配不成功的單條記錄進一步同下一批日志數據一起進行下一次匹配發送處理。數據采集服務器接受客戶端發送過來的成對數據并提供數據的接收監控顯示功能，并將成對數據存入相應的數據庫保存，為收費提供數據管理和支持。

1.2 數據描述

日志文件wtmpx是實時動態增長的，每372字節的數據代表一條登入/登出記錄。因此，數據采集端程序從日志文件中讀取數據時，只需要讀取從上次讀取到本次讀取之間所產生的最新的日志數據。即，采集端程序需要從上次讀取的末尾位置開始讀取，以每372字節的數據為單位進行讀取，直到接近文件末尾。正因為日志文件是實時動態增長的，如果讀至文件末尾，數據并非372字節的倍數，則表示一條登錄數據尚未完全形成，因此，只需要讀至上一個372字節的數據即可。數據采集端程序讀取日志文件的過程如圖1所示。

圖1 日志文件讀取過程Fig.1 Log file reading process

圖1中突出顯示字體1000部分表示上次讀取的末尾位置，則本次讀取從此開始。因為日志文件的動態增長，以至于本次讀取時，最后一條數據尚不是完整記錄，因此，只讀取到上一條登入/登出記錄即可。采集端程序從日志文件wtmpx中得到數據后，將數據存為臨時日志文件temp.log，然后進行數據解析。該文件中包含多條登入/登出記錄，每條記錄（每372字節）中需要采集的信息有：登錄的OS賬號、登錄的進程 ID、登錄/登出的時間、登錄期間的在線時間、終端IP。這些需要采集的數據信息在每372長度的字節中的位置如表1所示。

表1 采集的數據位置信息表Tab.1 Data collected by position information table

Unix服務器自帶的文件中包含的用戶信息是數據采集系統將要讀取的關鍵數據，對該文件的解析是系統設計的前提。該文件是一個二進制文件，從表1中可以看出，系統需要采集的5個數據項在文件中的一條登錄登出記錄項的地址是不連續的，在設計系統時，必須針對這幾個數據項的地址和各自的大小進行讀取[2-3]。

2 數據采集系統設計

根據系統的需求分析得出，該數據采集系統是一個基于“客戶端-服務器”架構的數據挖掘系統，由數據采集客戶端和數據采集服務器端兩部分組成。

數據采集客戶端的主要功能為：

1）定期讀取日志文件，得到最新的日志數據（從上一次讀取后的位置開始讀取）；

2）提取并解析日志文件中的數據；

3）如果有未匹配的日志文件，則將解析后的登錄日志數據和未匹配的日志文件數據合并；

4）將這些記錄匹配為完整的登錄會話記錄（一次登錄會話包含一次登入記錄和一次登出記錄）；

5）提交匹配后的日志數據到服務器。

數據采集客戶端的系統功能如圖2所示。

圖2 數據采集客戶端系統功能流程圖Fig.2 The flow chart of data collection client system function

數據采集服務器端的主要功能為：

1）持續接收數據采集客戶端發來的登錄數據，并記載登錄數據；

2）顯示數據接收以及操作的結果，以實現數據監控；

3）定期檢查所記載的登錄數據，并將數據保存到歸檔日志文件logrecfile.txt中。

數據采集服務器端的系統功能如圖3所示。

圖3 數據采集服務器端功能Fig.3 The flow chart of data collection server system function

由以上分析得出，可以把系統設計分成以下幾個模塊：讀取日志模塊，匹配日志模塊，發送日志模塊，日志瀏覽監控模塊、日志接收模塊，以及日志存儲模塊。

3 數據采集系統核心功能設計與實現

3.1 類的設計及功能描述

整個數據采集系統設計了7個類。分別是：

1）Log類：日志數據業務類，代表從日志中解析出來的日志記錄，每個日志記錄解析為一個Log對象。

2）LogPair類："日志記錄對"業務對象，包含兩個登錄日志對，還包括登錄主機的IP地址。日志對中一個是登錄記錄，一個是登出記錄。

3）DMSClient類：采集客戶端核心業務程序，主要用于獲取日志數據、解析日志數據、匹配日志數據、以及向采集服務器發送日志數據。

4）DMSClientFrame類：采集客戶端界面，顯示采集數據以及發送數據的狀態信息。

5）DMSServer類：采集服務器接收程序，接收采集端發來的數據，接收到數據以后寫入到文件中。

6）DMSServerFrame類：采集服務器界面，能夠顯示采集過程中的數據信息。

7）NetService類：設計網絡協議，提供數據發送和接受的格式[4]。

3.2 日志讀取模塊

日志讀取模塊每次讀取原始文件的一部分。采用增量讀取，每一次讀取一批。讀取日志核心算法步驟描述如下：

1）檢查輸入數據文件是否存在。

2）檢查上次讀取結果log.txt是否存在，如果存在就說明上次的結果沒有處理完成，這次就不再讀取。

3）讀取上次的讀取位置（沒有的從開始位置讀取）。

4）根據上次的讀取位置和文件長度判斷是否有新記錄產生。如果沒有新數據產生，就不讀取。

5）從上次讀取位置開始批量讀取日志到臨時文件，如果讀取到文件末尾就不讀取。

6）保存本次讀取的位置。7）改名臨時文件到log.txt。8）如果有異常一定不產生文件log.txt。

3.3 日志匹配模塊

日志匹配模塊每次從日志讀取模塊產生的結果log.txt中讀取登錄登出數據中成對的數據，最終產生匹配成功的成對數據文件matched.txt。其核心算法步驟描述如下：

1）檢查是否有輸入數據文件log.txt，如果沒有就返回。

2）檢查是否有輸出數據文件matched.txt，如果有返回。

3）如果有單條登錄記錄login.txt存在，讀取 login.txt到集合 logins， logouts。

4）讀取 log.txt到集合 logins， logouts。

5）迭代 logouts的key查找logins。如果找到，就是登錄對 matchedList＜logPair＞。找到從logins集合中刪除登錄記錄。

6）保存 matched集合到matched.txt。

7）保存 logins集合到login.txt

8）刪除 log.txt。

3.4 日志發送模塊

發送日志要用到網絡，網絡協議的設計就是一項非常重要的工作。為了便于數據的封裝和擴展。網絡協議設計采用XML[5]作為協議數據封裝。設計了負責XML數據的發送和接收的NetService類。XML報文設計包含類型type、長度length和值value三項內容。數據結構設計如下：先發送類型type，設計每次發送10個Byte，再發送長度length為4個Byte的int類型數據，最后發送value，節數量與length一致。發送數據方法 sendDocument（Document doc，Socket socket）將 xml doc通過socket的out流發送出去。其設計如下：

1）先發送定長的type數據 "XML"到流中。

2）將xml doc寫入到內存的緩沖區中，得到全部的Bytes數據，同時得到數據的長度。

3）將int分成4個Byte發送到流中。

4）將XML的全部的Byte數據發送到流中。

1）先接收定長 type類型。如果type不是 "XML"就拋出異常。

2）接收4個Byte，合并為一個int，是長度信息length。

3）從流中接收length個Byte到數組緩沖區。

4）將數組緩沖區中的數據，解析為XML doc。

需要將一個List全部的日志數據封裝起來發送到服務器。發送XML數據格式設計如下：

封裝服務器回送消息的接收XML數據格式設計如下:

日志發送模塊的核心算法描述如下：

1）檢查是否有被發送的數據文件matched.txt。如果沒有這個輸入數據文件，就不發送。如果有數據，就讀取數據到集合中。

2）連接到服務器。

3）向服務器發送集合數據并等待響應結果。如果響應結果中包含消息OK則說明發送成功，刪除matched.txt。如果返回ERROR表示發送失敗，就不能刪除matched.txt。如果異常也不能刪除matched.txt。

3.5 數據采集服務器端設計

數據采集服務端主要用來接受客戶端發送過來的日志數據，由于數據要通過網絡傳輸，服務器端采用讀取配置文件的方式讀取相關的初始化配置參數。設計一個loadConfig（）方法負責讀取并且初始化服務器參數。服務端主要任務流程如下：首先讀取配置文件信息，然后開始監聽服務器網絡端口號，創建緩沖隊列和線程池。需要設計保存文件線程和客戶服務線程并將線程啟動。保存文件線程會檢查緩沖隊列，如果有數據就追加寫入到logFile。 如果有客戶端連接進來，就創建客戶端服務線程并提交到線程池執行。客戶服務線程在執行的時候，不斷接收用戶提交的數據并保存到緩沖隊列[6－7]。

3.6 系統界面描述

數據采集系統客戶端在讀取、解析、匹配和發送數據后，還需要將數據操作的結果顯示在界面上以實現數據監控，每次操作后，均在頁面上顯示本次操作的結果。其界面效果如圖4所示。

圖4 數據采集系統客戶端界面Fig.4 Data collection system is the client interface

數據采集系統服務器端程序實時獲取采集端發來的數據。在得到采集端發來的數據后，保存數據，并將采集端服務器的信息顯示在界面上以實現數據監控。其界面效果如圖5所示。

圖5 數據采集系統服務器端界面Fig.5 Data collection system is the server interface

4 結束語

本文闡述了基于C/S模式的電信數據采集系統的開發過程。該系統在Windows操作系統下通過Java語言開發完成。實驗結果表明，該數據采集系統能夠從大量雜亂的日志數據中提取所需要的關鍵信息并對這些信息進行按規律整合，最后以GUI圖形界面的方式提供數據的瀏覽監控顯示功能。極大地方便了后期的數據維護和計費管理。該系統還可以推廣到除電信業務以外的其它需要處理大數據的場合。比如倉庫的物流管理、企業的業績分析、學校的學生信息管理等。

[1]路鵬飛，李進.在線計費系統中余額分配算法的優化[J].計算機工程，2011，37（7）:282－284.LU Peng-fei，LI Jin.Online billing system balance allocation algorithm in the optimization[J].Computer Engineering，2011，37（7）:282－284.

[2]周如培，馮同鑫.基于CORBA的電信計費系統的研究與開發[J].計算機應用研究，2002（8）:130-131.ZHOU Ru-pei，FENG Tong-xin.The research and development of the telecommunication billing system based on CORBA[J].Computer Application Research，2002（8）:130-131.

[3]張友生，李雄.軟件開發模型研究綜述[J].計算機工程與應用，2006，42（3）:17－19.ZHANG You-sheng，LI Xiong.Software development model studies reviewed[J].Computer Engineering and Application，2006，42（3）:17－19.

[4]孫衛琴.Java面向對象編程[M].電子工業出版社，2006.

[5]耿祥義.XML基礎教程[M].清華大學出版社，2006.

[6]CHEN Zhi-rui，TAN Hong-zhou.Logic structure of programmable instructions for Java[J].Journal of Electronics（China），2009，26（5）:44－46.

[7]Little G，Miller R C.Keyword programming in Java[J].Automated Software Engineering，2009（3）:32－35.