KirsT 最初的版本是根據Kirtore量身定製的log收集程式，其log內容結構符合Kirtore系統行為規範1.07v標準，
基本介紹
- 中文名：KirsT
- 性質：log收集程式
- 根據：Kirtore
- 系統行為規範：1.07v標準
KirsT定義,KirsT格式,log type,Log time,產生Log的模組名,意義,
KirsT定義
下圖為一個log信息的範例
e,01/07/2005 03:51:24,KirinReplication,Get Partition node configuration from Coordinator,SrcFile="kirscooandhandler.cpp" SrcFunc="KirsReplicitionNodeViewRequest::OnSentMessageComplete" SrcLine="455" Pid="1288" Tid="1152"
KirsT格式
log type
其內容為一個位元組，表示log的類型信息，根據log信息的種類和級別不同，產生不同類型的log type信息。常見的log type主要包含以下幾種
Log type | Log type informations |
e | err log which is always launch by core dump, The most horrible log of the MSRA |
w | Warning log ,which is should be detected by the dev team , the log should not happened |
i | Information log which show the information of the software running ,from the information, the user could know the progress of the software |
p | Pack log ,which is show by the pack transformation |
z | Zero log , when the software quit with successful a zero log launch |
t | time log ,when the DFS do the time allot process ,it will show |
c | Customer log , which is defined by the customers |
b | Binary program launch it |
d | Debug log ,the dev do UTing, should not leave it alone |
s | System log |
針對kisT的需求來說，主要針對的是error log 和warning log的收集。
Log time
Log time主要記錄為這一條log的發生時間，其格式為 MM/DD/YYYY HH:MM:SS, 作為krirn分散式系統的一個特點為：krirn 分散式系統的所有節點可能分布在與隸屬於不同時區的機房中，每一台節點的時間均為當地時間，這就給krirnAT 造成了一個很大的麻煩即，如果需要將屬於不同時區的節點的log信息進行匯總的話，同一時間產生的Log 可能會被分開處理和收集，最終會導致一個生成一個錯誤的結果，給進行分析造成不必要的麻煩。
產生Log的模組名
KirsT，由一台Master (DM)、數台Shadow Master(可選)和多台數據節點機(chunk server)以及運行於應用程式處的DFS客戶端庫(dfsapi)、DPF Agent以及DFS實用工具子系統(如DFS監控子系統、DFS目錄樹瀏覽子系統、檔案目錄複製子系統、數據導入等)等組成。DM及Shadow DM用來保存整個DFS的元數據(metadata)，chunk server用來保存檔案內容，dfsapi lib提供DFS到應用程式的接口。每個檔案被分成固定大小的塊(即chunk)，每個chunk被複製後保存在多台chunk server上（預設為3台）。通過DFS的客戶端庫(dfsapi)，應用程式的多個客戶端可以並發地讀寫檔案內容其完成的主要功能是：
檔案/目錄的創建、刪除、移動、改名
檔案的打開、關閉、讀出、追加、寫入(overwrite)
檔案屬性設定和修改(內容拷貝數，用戶許可權，壓縮方法，stream or structure content…)
多個客戶端並發讀同一個檔案
多個客戶端並發追加同一個檔案(無額外鎖機制)
同一檔案的讀出和追加可同時進行
客戶端的每個單一操作都是原子操作
只要DM及Shadow DM中超過半數線上，則系統可用
單一DM宕機重啟後系統可正常工作
少於chunk拷貝數的任意台chunk server下線時該檔案仍然可用
單一機架/房間所有chunk server下線時系統仍然可用(假設系統包含至少兩個機架/房間且機架/房間的機器容量網路配置大致相當)
經過配置的新chunk server機器自動加入系統
不論增加還是減少chunk server，系統都能在一段時間後達到所有chunk server的負載平衡
檔案和目錄的快照(snapshot)功能
DM和Shadow DM的線上checkpoint功能
Chunk server對其上的chunk數據進行校驗
檔案的chunk拷貝數可增加或減少
未及時更新的chunk拷貝(因chunk server離線等)能被發現並剔除
每個chunk server同時是一個客戶端。
針對不同的需求，存在著不同的模組，kirin-AT所收集的log 也主要有這些模組產生
4 log body
主要指的是krirn的log內容，符合微軟KirinStore系統行為規範1.07v標準，大小不超過2048位元組，其內容主要包括
1）編譯二進制信息，由dev設計並輸入代碼中
2）SrcFile：二進制檔案源檔案名稱
3）SrcFunc:所調用函式名和類名
4）SrcLine：log所在行號
5）Pid：進程名
6）Tid：執行緒名
在krirnAT的設計中，為了金大程度上增加其的兼容性，和可配置型，本工具需要對不同格式的Log兼容，例如，在前文中提到的KirinStore系統行為規範1.07v標準的格式順序為：Log type ,Log time,Log info,和log body四部分組成。但是在MSTD的log格式標準為：log type, log info 和 log decryptions 三部分組成.所以,在kirinAT中，需要設計一種算法，來自動的匹配不同種類的log格式。
kirinAT中處理此任務的模組是LogReader,,其完成的功能是，從上游模組Seeker中取得log檔案，讀取log檔案，對log檔案內容進行類型識別和匹配，導出符合標準kirinAT標準的log格式，將結果傳遞給下一個模組 Parser
實現方法
設計一個類LogForKirin
主要包含以下成員變數：
char logType//Log type
char logTime[40] //Log time
char logInfo[2048] // Log info
char logBody[2048] //log body
主要包含以下方法
private setValue(char * ,char *,char *,char *) 給LogForKirin變數賦值
public putIntoLogForKirin（Log *） 外部調用
private moduleSeek() 識別為符合kirinAT要求的格式
public outputValue()輸出
實現邏輯如下
1 首先讀取配置檔案reader.config，其檔案的格式如下
divide symbol ,
Log type 1
Log time 2
Log info 3
log body 5
divide symbol所對應的字元為該log檔案的分隔設定，log檔案的每一行按照分隔設定來劃分成n份，其中，log type 為第一份（即第一個逗號以前的檔案內容），log time為第二份，log info為第三份，log body為第五份，以此類推。
2將配置項讀取後，開始讀取log檔案，調用putIntoLogForKirin方法，將所有log檔案的log信息導入到類LogForKirin中，該方法會根據配置檔案，查找輸入的log信息的分隔設定，將其進行統計，利用所羅門倒排算法，將所需要的log信息過濾出來，調用setValue方法輸入到類的實例中，一條log輸入完成後繼續輸入其餘的log信息，最終得出一個LogForKirin實例的數組。將結果輸出到Parser模組中。
