程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> Eclipse Test and Performance Tools Platform，第2部分: 監視應用程序

Eclipse Test and Performance Tools Platform，第2部分: 監視應用程序

編輯：關於JAVA

開始之前

關於本系列

為應用程序編寫代碼只是交付健壯的產品質量的程序所需的漫長過程的第一階段。必須對代碼進行測試，以檢驗它的操作和准確性。往往還必須對代碼進行分析，以便消除性能瓶頸和資源浪費（尤其是內存）。還必須對代碼進行監視，以便對故障進行定位、識別使用模式、尋找進一步增強和優化的機會以及探測入侵嘗試和實際的入侵。

Eclipse Test and Performance Tools Platform（TPTP）是一種軟件體系結構以及幾個擴展了 Eclipse 平台的組件（到目前為止），包括測試、性能和監視工具。這個 “Eclipse Test and Performance Tools Platform” 系列講解 TPTP 的功能。第 1 部分演示了如何分析 Java™ 應用程序。第 2 部分演示如何捕獲任意的日志文件，並將它們轉換為得到廣泛支持的 Common Base Events（CBE）格式。第 3 部分將解釋如何管理應用程序測試。

關於本教程

本教程講解如何使用 Eclipse TPTP 的功能將典型的應用程序日志文件轉換為 CBE 格式。利用少量規范，再進行一些編碼工作來創建一系列規則，就可以將任何日志文件轉換為一種統一的結構化的格式。然後，就可以使用 Eclipse TPTP 和其他專用工具，快速地組合、處理和分析使用模式、性能和錯誤。

目標

在本教程中，要學習如何編寫一個適配器（adapter），將典型的 Linux® 軟件服務日志文件轉換為 CBE 數據。將使用 Eclipse TPTP Adapter Configuration Editor 逐漸創建轉換並進行調試，然後用 Generic Log Adapter（GLA）對數據進行輸入、轉換和輸出。

前提條件

您應該具備軟件開發經驗並了解整個軟件開發生命周期，包括測試和分析。還應該熟悉從命令行安裝軟件，以及設置和管理 shell 和系統環境變量，比如 shell 的 PATH 和 Java CLASSPATH。另外，具備閱讀和編寫正則表達式的經驗也很重要。了解 Eclipse 和 Eclipse 用戶界面（UI）范型也是有幫助的。

系統需求

可以在具有 JVM 的任何系統上運行 Eclipse，比如 Solaris、Linux、Mac OS X 或 Windows。如果系統上沒有安裝 JVM 和 Eclipse，那麼所有軟件至少需要 300 MB 的空閒磁盤空間。還需要有足夠的空閒物理內存來運行 JVM。一般來說，建議使用 64 MB 或更多的空閒物理內存。

必須在 UNIX®、Linux®、Mac OS X 或 Microsoft® Windows® 系統上安裝幾個軟件包。需要一個 Java 虛擬機（Java Virtual Machine，JVM）、Eclipse SDK 的一個副本、Eclipse TPTP 運行時的一個副本以及 Eclipse TPTP 所依賴的幾個軟件。還需要 Eclipse TPTP GLA，用於對獨立應用程序或您自己的應用程序中的日志文件進行轉換。下面是所需的所有軟件：

從 Sun Microsystems 或 IBM 下載 Java 技術

Eclipse V3.1 Software Development Kit（SDK）

Eclipse Modeling Framework（EMF） SDK V2.1

XML Schema Infoset Model（XSD） SDK V2.1

Version 1.1.1 of Eclipse Unified Modeling Language（UML） 2

Eclipse TPTP 運行時

GLA 運行時

對日志文件進行轉換和分析

為了支持以後的監視過程，復雜的應用程序（尤其是需要連續運行的應用程序）在開發期間通常會設計輸出日志文件的功能，日志文件是對應用程序活動的記錄。一些活動是詳細的內部診斷信息，這些信息對於隔離 bug 或者分析與其他系統和軟件組件的交互是很重要的。日志中記錄的一些活動可能是由應用程序本身發起的 —— 比如，讀取配置文件或打開要監聽的端口。其他活動可能是由對服務的請求生成的。

問題：對遺留應用程序的監視

根據應用程序的用途，系統管理員可能會不定期地查看程序的日志文件 —— 當發生錯誤時，甚至是在處理緊急事件時。另外，日志常常能夠提供大量有價值的歷史信息。例如，在 Apache HTTP Server 日志中可以找到通信流量和使用模式信息。

如果所有日志文件都至少捕獲了最基本的信息，那麼是很理想的。如果所有日志文件的格式都是一致的，那就更好了，尤其是從系統管理員的角度來看。一致性會使讀取日志容易得多，有助於開發自動化工具（而且會大大減少開發成本），從而能夠自動地從大量信息中篩選出重要的事件。

但是這種一致性是不現實的。應用程序是各種各樣的，底層的操作系統設施和編程語言庫也是不一樣的。一些應用程序（“遺留的應用程序”）是 “頑固不化” 的，無法對它們進行調整，從而取得一致性。另外，昂貴而又稀缺的開發人員資源往往都用在新特性上了，沒有時間去對原有特性進行翻新。

解決方案：對日志文件數據進行轉換

既然理想情況是不現實的，而且認識到一個解決方案無法滿足所有需求，那麼更可行的辦法就是對日志文件數據進行轉換，從而滿足某一事實標准並應用現代的分析工具。例如，在為記錄、跟蹤和分析事件（事件是指在計算系統中發生的情況）定義通用標准的研究工作中產生了 CBE 格式。CBE 數據是基於 XML 的，現在有許多工具能夠處理和分析 CBE 數據。

然而，盡管從任意日志文件轉換到 CBE 可能是可行的，但是這一過程可能不容易，也不便宜。考慮到應用程序的種類繁多，日志文件格式的數量也非常多，編寫這麼多轉換本身就是一項繁重的任務。

Eclipse TPTP GLA 和 Adapter Configuration Editor 簡化了轉換的創建過程，由此簡化了遷移到 CBE 的過程。GLA 在日志文件上應用由 Adapter Configuration Editor 創建的適配器並產生 CBE 數據。Adapter Configuration Editor 可以運行手工建立的 Java 類（靜態適配器（static adapter）），也可以運行一系列規則將日志文件分割成記錄、字段和值，並將它們組合成 CBE 數據。後一種形式的適配器稱為基於規則的適配器（rules-based adapter），它們不需要編寫代碼。而且，更好的是，Adapter Configuration Editor 在 Eclipse 中運行，提供了一個強大的適配器開發環境，在這個環境中可以逐漸地定義和測試自己的適配器。最後，還可以選擇將 GLA 與自己的代碼集成起來或者使用第三方工具，比如 IBM Log and Trace Analyzer，從而探測和研究產生的 CBE 事件文件。

本教程講解如何使用 Eclipse TPTP GLA 和 Adapter Configuration Editor 的功能將典型的 Linux 應用程序日志文件轉換為 CBE 事件。只要有日志文件在手並具備一點兒正則表達式知識，就能夠將日志轉換為統一的結構化的 CBE 格式。

安裝所需的軟件和組件

在開始之前，必須安裝和設置所需的軟件和組件（見 “前提條件”）。

安裝 J2RE V1.4

下載並安裝 Version 1.4 或 1.5（也稱為 Version 5.0）。（如果您的系統已經安裝了 J2RE V1.4 或更高版本，那麼可以跳過這一步。）

通常，JRE 作為自解壓的二進制代碼發布。如果將 J2RE 包下載到自己的主目錄，安裝（在 Linux 上）通常很容易，見清單 1。

清單 1. J2RE V1.4 安裝

%　cd　~ %　mkdir　~/java %　cd　~/java %　mv　~/jre-1_5_0_06-linux-i586.bin　. %　chmod　+x　jre-1_5_0_06-linux-i586.bin %　./jre-1_5_0_06-linux-i586.bin 　... %　rm　./jre-1_5_0_06-linux-i586.bin %　ls　-F　 jre1.5.0_06/　

清單 1 中的命令安裝 J2RE V1.5，但是安裝 J2RE V1.4 的步驟是一樣的（只是文件名不同）。

安裝 Eclipse V3.1 SDK

下載適合自己平台的 Eclipse V3.1 SDK。可以在 Eclipse Downloads 找到這個 SDK。通常，安裝時只需將 Eclipse tar 文件（.tar.gz）解壓到您選擇的目錄中。

例如，如果使用 Linux，那麼下載 Eclipse V3.1 SDK tar 文件並使用清單 2 中的命令將它解壓到一個目錄（比如 ~/java/）。

清單 2. 安裝 Eclipse V3.1 SDK

%　cd　~/java %　mv　~/eclipse-SDK-3.1.1-linux-gtk.tar.gz　. %　tar　zxvf　eclipse-SDK-3.1.1-linux-gtk.tar.gz 　... %　rm　eclipse-SDK-3.1.1-linux-gtk.tar.gz　

為了確認已經成功地安裝了 Eclipse，留在解壓 Eclipse 的目錄中，確保 java 可執行文件在 PATH 中並運行 java -jar eclipse/startup.jar。例如：

清單 3. 檢驗安裝

%　export　JAVA_DIR=$HOME/java %　export　JAVA_HOME=$JAVA_DIR/jre1.5.0_06　 %　export　PATH=$JAVA_HOME/bin %　export　CLASSPATH=$JAVA_HOME　 %　cd　$JAVA_DIR %　java　-jar　eclipse/startup.jar

如果 Eclipse 提示您為自己的工作空間選擇一個目錄，那麼使用 $HOME/java/workspace。這個目錄將容納您在 Eclipse 中創建的所有項目。（當然，如果有許多項目，以後可以選擇其他目錄，讓每個工作空間只包含一個項目。）現在退出 Eclipse 以便安裝 Eclipse TPTP、它需要的軟件和 GLA。

安裝 TPTP 和 GLA 運行時

Eclipse TPTP 運行時包含創建、調試和運行適配器所需的軟件。為了安裝 Eclipse TPTP 軟件，需要下載 Eclipse TPTP 和 GLA 運行時。它們通常以 zip 格式發布。將這兩個文件轉移到包含 J2RE 和 Eclipse 的目錄並進行解壓（見清單 4）。如果提示覆蓋任何文件，那麼只需選擇 All。

清單 4. 安裝 Eclipse TPTP 和 GLA

%　cd　~/java %　mv　~/tptp.runtime-TPTP-4.1.0.zip　. %　mv　~/tptp.gla.runtime-TPTP-4.1.0.1.zip　. %　unzip　tptp.runtime-TPTP-4.1.0.zip 　... %　unzip　tptp.gla.runtime-TPTP-4.1.0.1.zip 　... %　rm　tptp.runtime-TPTP-4.1.0.zip %　rm　tptp.gla.runtime-TPTP-4.1.0.1.zip %　ls　-F　 GenericLogAdapter/　eclipse/　jre1.5.0_06/

安裝 EMF SDK V2.1

為了讓 TPTP 正常工作，必須安裝 EMF SDK V2.1。

如果 Eclipse 正在運行，就退出它並下載 EMF SDK V2.1。然後進入包含 Eclipse 文件夾的目錄並運行 unzip emf-sdo-SDK-2.1.0.zip（見清單 5）。

清單 5. 安裝 EMF SDK V2.1

%　cd　$JAVA_DIR %　ls eclipse　jre1.5.0_06　 %　mv　~/emf-sdo-SDK-2.1.0.zip　. %　unzip　emf-sdo-SDK-2.1.0.zip creating:　eclipse/features/　 creating:　eclipse/features/org.eclipse.emf.ecore.sdo_2.1.0/　 creating:　eclipse/features/org.eclipse.emf_2.1.0/　 inflating:　... 　... %　rm　emf-sdo-SDK-2.1.0.zip

安裝 XSD SDK V2.1

與前一個文件一樣，進入包含 Eclipse 目錄的目錄並運行 unzip xsd-SDK-2.1.0.zip（見清單 6）。

清單 6. 安裝 XSD SDK V2.1

%　cd　$JAVA_DIR %　mv　~/xsd-SDK-2.1.0.zip　. %　unzip　xsd-SDK-2.1.0.zip %　rm　xsd-SDK-2.1.0.zip

如果提示您確認覆蓋任何文件，那麼只需按 y（小寫）對每個問題回答 “Yes”。

安裝 UML V2.0 Metamodel Implementation

要使用 Eclipse TPTP 的 UML 特性，就必須安裝 UML V2.0 Metamodel Implementation。如果正在使用 Eclipse V3.1.1，那麼下載 V1.1.1 of UML 2，然後在包含 Eclipse 的目錄中解壓它的存檔文件（見清單 7）。

清單 7. 安裝 UML V2.0 Metamodel Implementation

%　cd　$JAVA_DIR %　mv　~/uml2-1.1.1.zip　. %　unzip　uml2-1.1.1.zip 　... %　rm　uml2-1.1.1.zip

安裝 Agent Controller

Agent Controller 是 Eclipse TPTP 的一個重要組件，它使 Eclipse 能夠啟動應用程序並與這些應用程序進行交互，從而提取分析數據。下載適合自己操作系統的 Agent Controller 運行時。接下來，在包含 Eclipse 的目錄中創建一個稱為 tptpd 的目錄，並將 Agent Controller 存檔文件解壓到這個目錄中（見清單 8）。

清單 8. 安裝 Agent Controller

%　mkdir　$JAVA_DIR/tptpd %　cd　$JAVA_DIR/tptpd %　mv　~/tptpdc.linux_ia32-TPTP-4.1.0.zip　. %　unzip　tptpdc.linux_ia32-TPTP-4.1.0.zip

如果看到兩個下面這樣的錯誤：

清單 9. 安裝 Agent Controller

linking:　lib/libxerces-c.so　　　　 warning:　symbolic　link　(lib/libxerces-c.so)　failed 　 linking:　lib/libxerces-c.so.24 warning:　symbolic　link　(lib/libxerces-c.so.24)　failed　

那麼通過輸入以下命令來手工地重新創建這兩個鏈接：

清單 10. 安裝 Agent Controller

%　cd　$JAVA_DIR/tptpd/lib　 %　rm　libxerces-c.so　libxerces-c.so.24 %　ln　-s　libxerces-c.so.24.0　libxerces-c.so　 %　ln　-s　libxerces-c.so.24.0　libxerces-c.so.24

添加 Agent Controller 目錄

要使用 Agent Controller，必須將它的 lib 目錄添加到 LD_LIBRARY_PATH 中。例如，如果正在運行 Linux 並采用以上步驟中給出的目錄結構，那麼用以下命令添加 $JAVA_DIR/tptpd/lib：

%　export　LD_LIBRARY_PATH=$JAVA_DIR/tptpd/lib:$LD_LIBRARY_PATH

還必須確保 Controller 的 lib 和 bin 目錄的內容是可執行的。為此，運行：

%　chmod　+x　$JAVA_DIR/tptpd/{bin,lib}/*　

現在將配置、啟動和停止 Agent Controller 的腳本添加到 PATH：

%　export　PATH=$JAVA_DIR/tptpd/bin:$PATH

針對環境配置 Agent Controller

最後，要配置 Agent Controller 以便匹配環境。進入 Agent Controller 的 bin 目錄，然後運行 SetConfig.sh。

%　cd　$JAVA_DIR/tptpd/bin %　./SetConfig.sh　

當配置腳本提示您進行選擇時，接受默認設置。運行配置腳本會在 Agent Controller 的文件層次結構中創建文件 config/serviceconfig.xml。

測試 Agent Controller

為了測試 Agent Controller，運行 RAStart.sh。為了停止 Agent Controller，運行 RAStop.sh：

清單 11. 測試 Agent Controller

db%　RAStart.sh Starting　Agent　Controller RAServer　started　successfully %　RAStop.sh RAServer　stopped,　pid　=　5891 RAServer　stopped,　pid　=　5892 RAServer　stopped,　pid　=　5893 RAServer　stopped,　pid　=　5894 RAServer　stopped,　pid　=　5895　 RAServer　stopped,　pid　=　5896　 RAServer　stopped,　pid　=　5897 RAServer　stopped,　pid　=　5898　 RAServer　stopped,　pid　=　5899　 RAServer　stopped,　pid　=　5900 RAServer　stopped,　pid　=　5901 RAServer　stopped,　pid　=　5902 RAServer　stopped,　pid　=　5904 RAServer　stopped,　pid　=　5905　 RAServer　stopped,　pid　=　5906　

現在完成了！重新啟動 Eclipse，在 Eclipse 工具欄上應該會看到一個新按鈕，如圖 1 所示。這是 TPTP Profile 按鈕，表示 TPTP 已經成功地安裝了。就可以繼續學習本教程了。

圖 1. TPTP Profile 按鈕

創建適配器

GLA 使用一個 XML 配置文件來控制如何分析和轉換日志文件，以及如何輸出數據。一個配置文件包含一個或多個上下文，在每個上下文中定義如何轉換一種日志文件。在某些情況下，一個配置文件中的多個上下文可以同時運行。

適配器配置文件

首先，創建一個適配器配置文件來處理名為 daemon.log 的 Linux 日志文件。在運行 Debian Linux 的測試系統上，daemon.log 捕獲來自 POP3（電子郵件）、THTTPD（“簡化的” HTTP 服務器 —— 一種只處理靜態文件的小型快速 Web 服務器）和 MyDNS（一種小型的容易配置的 Domain Name System（DNS）服務器）守護進程的消息。在 MySQL 守護進程啟動和停止時，daemon.log 也進行記錄。

清單 12 給出 POP3 和 THTTPD 服務器產生的一部分日志項。

清單 12. Linux daemon.log 文件的片段

Mar　2　07:24:54　db　popa3d[8861]:　Session　from　66.27.187.89　 Mar　2　07:24:55　db　popa3d[8861]:　Authentication　passed　for　joan Mar　2　07:24:55　db　popa3d[8861]:　1422　messages　(11773432　bytes)　loaded Mar　2　07:24:57　db　popa3d[8861]:　0　(0)　deleted,　1422　(11773432)　left Mar　2　07:26:28　db　thttpd[7784]:　up　3600　seconds,　stats　for　3600　seconds:　 Mar　2　07:26:28　db　thttpd[7784]:　　thttpd　-　0　connections　(0/sec),　0　max　simultaneous Mar　2　07:26:28　db　thttpd[7784]:　　map　cache　-　0　allocated,　0　active　(0　bytes)... Mar　2　07:26:28　db　thttpd[7784]:　　fdwatch　-　1589　selects　(0.441389/sec)　 Mar　2　07:26:28　db　thttpd[7784]:　　timers　-　3　allocated,　3　active,　0　free　 Mar　2　07:27:35　db　popa3d[8911]:　Session　from　71.65.224.25　 Mar　2　07:27:35　db　popa3d[8911]:　Authentication　passed　for　martin Mar　2　07:27:35　db　popa3d[8911]:　1350　messages　(10880072　bytes)　loaded Mar　2　07:27:36　db　popa3d[8911]:　4　(11356)　deleted,　1346　(10868716)　left Mar　2　07:29:54　db　popa3d[8963]:　Session　from　66.27.187.89

適配器配置文件中的每個上下文定義 6 個組件：上下文實例（context instance）、檢測器（sensor）、提取器（extractor）、解析器（parser）、格式化器（formatter）和輸出器（outputter）。上下文實例為轉換的一般操作設置參數，包括日志是否連續地追加以及修改日志的頻繁程度。從概念上講，其他 5 個組件依次發揮作用，它們都讀取輸入、執行各自的任務並傳遞結果供進一步處理（某些格式化器例外，它們僅僅是將結果寫到文件或控制台）：

檢測器分段讀取日志文件，直到它遇到文件的末尾並暫停。然後，當檢測器發現日志文件已經增長時，它就讀取新增的數據。檢測器將它的數據傳遞給下一階段 —— 提取器。

提取器讀取數據並將它分割為單獨的記錄。一個正則表達式定義了記錄的開頭是什麼樣的，另一個正則表達式定義記錄的末尾。識別出單獨的記錄之後，這些記錄傳遞給解析器進行進一步處理。

解析器每次從提取器讀取一個記錄，將每個記錄分解為字段和值。另外，解析器能夠根據記錄的內容做出決策，應用一組或多組規則來產生字段和值。例如，如果一個日志文件記錄了一個事件的開頭、中間過程和結束，那麼解析器能夠將每個記錄分解為此事件特有的一組字段和值。總之，解析器的目標是將每個日志文件項中的字段和值映射到 CBE XML 記錄中的適當元素、屬性和值。格式化器讀取解析器的輸出。

格式化器的工作很簡單：它讀取解析器創建的元素、屬性和值，創建一個適合上下文中的下一階段（輸出器）使用的對象。

輸出器使用來自格式化器的對象並輸出這個對象。輸出器將 XML 輸出到文件或控制台。它們也能夠創建新的日志文件或者將數據傳遞給某個守護進程。

下面 5 節描述如何定義上下文的 6 個組件。

創建適配器配置文件

首先，創建一個簡單的 Eclipse 項目來包含適配器配置文件：

點擊 File > New 並展開 Simple。選擇 Project 並點擊 Next。

將項目命名為 My Adapter 並點擊 Finish。

點擊 File > New > Other 並展開 Generic Log Adapter。選擇 Generic Log Adapter File 並點擊 Next。

選擇 My Adapter 並將適配器文件命名為 my.adapter。點擊 Next。

為希望用這個適配器處理的日志文件選擇一個模板（見圖 2）。

可以使用希望處理的日志文件的片段，或者日志文件的精確表示 —— 比如來自詳細的規范。點擊 Browse，在文件系統中找到並打開這個模板。在做出選擇之後，點擊 Finish。當提示您切換透視圖時，點擊 Yes。

圖 2. 選擇一個表示要轉換的日志文件的模板

圖 3 顯示 Generic Log Adapter 透視圖。可以看到，這個用戶界面顯示一個上下文實例，在其中檢測器的屬性指向剛才選擇的模板日志文件。這個上下文實例還包含提取器、解析器、格式化器和輸出器，這些必須進一步進行定義。

圖 3. Generic Log Adapter 透視圖

配置上下文

每個上下文實例描述如何處理一個日志文件。可以在上下文實例中設置幾個選項。要看到這些選項，點擊 Configuration 下面的 Context Instance。應該會看到與圖 4 相似的面板。

圖 4. 上下文實例選項

可以編輯 Description 來描述這個上下文的用途。另外：

如果日志文件會不斷更新（daemon.log 就是這種情況），那麼選中 Continuous operation 復選框。

Maximum idle time 是上下文應該等待日志文件更新的毫秒數，如果在這段時間內日志文件沒有更新，那麼上下文實例就關閉。

Pause interval 控制在到達日志文件末尾之後，上下文應該等待多長時間。

因為日志文件不一定是 ASCII 文本，所以可以設置 ISO language code（使用兩個小寫字母）、ISO country code（使用兩個大寫字母）和文件的 Encoding（使用來自 Internet Assigned Numbers Authority（IANA）字符集注冊庫的值）。在默認情況下，這些參數設置為 en、US 和 JVM 的默認編碼。

最後，因為一些日志文件沒有指出時區、年、月和日，而 CBE 要求有這 4 個值，可以在 Timezone GMT offset 和 Log file creation date 字段中提供替代值。

因為 daemon.log 會不斷增長，所以選中 Continuous operation 復選框。因為郵件通常經常被查看，所以將 Maximum idle time 和 Pause interval 設置為 120。測試計算機位於科羅拉多，所以 GMT 是 -7。daemon.log 沒有指定年，所以提供默認值 2006 作為替代值。在做這些修改之後，保存文件。

指定檢測器

檢測器讀取日志文件並將收集的數據轉發給提取器。下一步是指定檢測器應該如何工作。

指定檢測器如何工作

點擊檢測器。它的屬性見圖 5，這裡也顯示了為 daemon.log 檢測器設置的值。

圖 5. 設置 daemon.log 的檢測器

因為 daemon.log 是單個文件，所以不需要改變 Sensor type 選項。Description 字段描述檢測器的用途。Maximum blocking 定義在將輸入傳遞給提取器之前要讀取多少行。因為 daemon.log 中的項往往跨許多行，所以 10 是合理的設置。Confidence buffer size 的值表示包含日志文件最後 n 個字節的緩沖區的大小。如果日志改變了 —— 即，最後 n 個字節不同於可靠緩沖區中的內容，那麼檢測器就讀取更多的輸入。默認值是 1,024 字節，這對於這個示例是足夠的。

有些日志在日志文件的末尾附加一個結束標志（在每次寫新數據時）。通常，最好忽略這一數據，所以為了跳過結束標志，在 File footer size 中指定要跳過的字節數。daemon.log 沒有結束標志，所以把這個值設置為 0。

如果展開 Sensor type（點擊箭頭），會看到另外兩個屬性：directory 和 fileName。這些屬性最初設置為模板日志文件的位置和名稱，但是以後可以改變它們來處理真實數據。

在設置檢測器屬性之後，不要忘了保存配置文件。另外，總的來說，在嘗試運行適配器之前應該總是保存配置文件。

編輯提取器

檢測器的作用是收集輸入。提取器的作用是將輸入流分割為單獨的記錄。（下一個組件 —— 解析器 —— 將每個記錄分割為字段。）

配置提取器屬性

為了編輯提取器，點擊 Extractor。它的屬性見圖 6。提取器的屬性指定每個記錄的分界符，並控制這些分界符是否應該包含在傳遞給解析器的記錄中。

圖 6. 提取器屬性
　　在示例日志文件（daemon.log）中，日志的每一行是一個單獨的事件。這使得提取器很容易配置。（圖 6 是適合 daemon.log 的配置。）

取消選中 Contains line breaks 復選框，因為 daemon.log 中的每一行是一個記錄。但是，如果一個日志項跨許多行（MySQL 或 IBM DB2® 數據庫日志就是這種情況），則要選中這個復選框。

在這個示例中，也取消選中 Replace line breaks 復選框。但是，如果日志文件包含換行符，則可以選中這個復選框，從而刪除每個換行符或者將它們替換為特殊標志，這有利於進行分析。要刪除換行符，只需選中這個復選框；要將每個換行符替換為一個符號，需要選中這個復選框並在 Line break symbol 字段中提供一個分界符。最好選擇不會出現在這個日志文件中的符號。

Start pattern 和 End pattern 都是正則表達式，分別描述每個記錄的開頭和結尾。在這個示例中，每一行是一個記錄，所以行首（^，脫字符）表示記錄的開頭，行末（$，美元符號）表示記錄的末尾。因為 ^ 和 $ 不表示任何內容，所以不需要包含在記錄本身中。

保存配置。

MySQL 示例

為了進行對比，為 MySQL 的慢查詢日志創建另一個提取器示例，這是一個特殊的日志，用來捕獲不夠優化的查詢。慢查詢日志中的每一項至少跨三行（見清單 13）。

清單 13. MySQL 慢查詢日志的片段

#　Time:　030207　15:03:33 #　Query_time:　13　Lock_time:　0　Rows_sent:　0　Rows_examined:　0 SELECT　l　FROM　un　WHERE　ip='209.xx.xxx.xx'; #　Time:　030207　15:03:42 #　Query_time:　17　Lock_time:　1　Rows_sent:　0　Rows_examined:　0 SELECT　l　FROM　un　WHERE　ip='214.xx.xxx.xx'; #　Time:　030207　15:03:43 #　Query_time:　57　Lock_time:　0　Rows_sent:　2117　Rows_examined:　4234 SELECT　c,cn,ct　FROM　cr,l,un　WHERE　ci=lt　AND　lf='MP'　AND　ui=cu;

針對慢查詢日志的提取器可能像圖 7 這樣。

圖 7. MySQL 慢查詢日志的提取器示例

圖 8 顯示三個記錄中的第二個，這說明提取器成功地處理了每個記錄。

圖 8. 從慢查詢日志提取的記錄

對到目前為止做的工作進行測試

回到 daemon.log 適配器，現在可以對檢測器和提取器組件進行測試，從而確認可以獲得數據並將數據分割為記錄。

重新運行適配器

看一下 Generic Log Adapter 透視圖底部的兩個面板。應該會看到與圖 9 相似的內容。左邊是 Extractor Result 面板；右邊是重疊的 Formatter Result 面板、Sensor Result 面板和 Problems 面板。Extractor Result 面板中有一系列控制適配器的按鈕。圖 10 顯示這些按鈕的標簽（把鼠標放在每個按鈕上也可以看到工具提示。）

圖 9. 上下文組件顯示面板

圖 10. 適配器控制按鈕

點擊 Rerun adapter 從日志文件模板的開頭重新開始處理。然後點擊 Next event 處理第一個事件。

Sensor Result 面板應該顯示日志文件的前 10-20 行。

Extractor Result 面板應該顯示日志文件的第一行，Mar 2 06:27:35 db popa3d[7964]: Session from 71.65.224.25。

Problems 面板應該是空的。但是，在運行適配器時要注意這個面板。如果忽略了必需的 CBE 屬性、指定了無效的正則表達式或者使用了不支持的值，那麼這個面板應該會指出這些問題。

Formatter Result 面板現在的意義不大，因為還必須定義解析器。但是，它展示了當前記錄最初的 XML CBE：

清單 14. 當前記錄最初的 XML CBE

<CommonBaseEvent 　　creationTime="replace　with　our　message　text" 　　globalInstanceId="A1DAABE6C7876D20E8E9E8C475042F1B" 　　version="1.0.1"> </CommonBaseEvent>

以後您會看到，在定義了解析器之後，在這個 XML 中會自動地添加其他元素和屬性。

要讓提取器產生下一個記錄，再次點擊 Next event。要想一直處理到最後一個記錄（在檢測器目前已經收集的輸入中），點擊 Show last event。

建立解析器

檢測器讀取數據。提取器將數據分割為記錄。解析器的作用是從每個記錄中提取出特定的字段，並使用這些值構造出一個完整的 CBE XML 記錄。

解析器的作用

解析器可以從日志文件中直接提取出某些字段，比如時間戳、主機名稱、守護進程名稱和文本消息。解析器也可以從記錄中間接地獲得數據。例如，解析器可能發現一個記錄來自某個軟件服務，並將 CBE componentIdType 屬性設置為 ServiceName。在某些情況下，解析器甚至可能在記錄中添加數據。尤其是，如果日志項沒有記錄事件的日、月、年和時區，那麼解析器必須添加這些數據，才能創建有效的 CBE。

為了理解 daemon.log 示例的解析器，清單 15 給出了日志項 Mar 2 06:27:35 db popa3d[7964]: Session from 71.65.224.25 的有效 CBE XML 記錄。顯然，一些屬性來自原來的日志項；其他屬性是從隱含數據構造出來的。（許多屬性值來自 Common Base Events Specification。在創建自己的解析器時參考這個文檔是有幫助的。）

清單 15. daemon.log 中第一個記錄的等效 CBE 記錄

另外，要記住每個 CBE（至少）必須定義 creationTime 屬性、msg 屬性和 sourceComponentId 元素（這個元素必須具有清單 15 所示的 6 個屬性）。situation 元素（和其他元素）是可選的，它對事件進行詳細說明。

解析器是如何工作的

點擊 Generic Log Adapter 透視圖中的 Parser，開始定義解析器。圖 11 顯示完成的解析器。對於清單 15 所示的 CBE 中的每個屬性和元素，都有一個解析器任務。

圖 11. 完成的 daemon.log 解析器

解析器的工作過程分兩個階段。首先，它將輸入的記錄（來自提取器）分割為位置（position），也就是編號的部分，每個部分之間由分隔符（separator token）。如果沒有指定分隔符，那麼跳過這一步。然後，解析器將記錄分隔為指示（designation），也就是 (名稱，值) 對，每個 (名稱，值) 對是兩個字符串，由指示符（designation token）聯結在一起。如果沒有指定指示符，那麼跳過後一步。

考慮這個例子：如果分隔符是正則表達式 [ ]+，指示符是 =（等號），而解析器處理以下記錄：

03/05/06　12:51:06EST　Mail　name=joe　action=login　authentication=password　

解析器會定義 6 個位置和 3 個指示，見表 1。

表 1. 解析器定義的位置和指示
位置/指示值 1 03/05/06 2 12:51:06EST 3 Mail 4 name=joe 5 action=login 6 authentication=password h{'name'} joe h{'action'} login h{'authentication'} password

注：如果輸入的記錄以分隔符開頭，那麼創建的第一個位置是空的。

可以使用定義的所有位置和指示來簡化每個解析器任務。例如，要創建 creationTime 屬性，只需分析第二個位置。當然，完整的原始記錄總是可用的。但是，位置和指示使解析任務更快而且更容易管理，因為源字符串更小。在許多情況下，可以將一個位置或指示直接用作 CBE 值。

解析示例日志項

再次點擊 Parser。為了方便，使用分隔符 :[ ]+（一個冒號，後面是一個或多個空格）將每個 daemon.log 項分割為兩個位置。daemon.log 日志項沒有 (名稱，值) 對，所以忽略指示符。這些設置見圖 12。現在，保存設置。

圖 12. 將記錄分割為位置

設置 creationTime

設置 CBE 中的第一個必要字段：creationTime。目標是將 daemon.log 記錄提供的時間戳轉換為與 XML 模式 dateTime 數據類型兼容的時間格式。為了方便，適配器可以自動地將 java.text.SimpleDateFormat 類理解的時間格式轉換為 XML 模式數據類型。

為了設置 creationTime 字段，執行以下步驟：

展開解析器並選擇 creationTime。這是一個 CBE 必要字段，所以選中 Required by parent 復選框。

點擊與 creationTime 相關聯的替換規則。

對於 Positions，輸入 1，因為第一個位置包含要提取的時間戳。

對於 Match，提供正則表達式 ^(\w{3})\s+(\d{1,2})\s+([\d:]+)\s+.*$。這個正則表達式捕獲月份名稱（$1）、月中日（$2）和日中的時間（$3）。

對於 Substitute，輸入 $1 $2 @YEAR $3 @TIMEZONE。
在這個解析任務的其余部分中，將使用這個替換表示而不是完整的輸入記錄。$1、$2 和 $3 來自前一步。但是，因為時間戳不包含年或時區，所以要使用與當前上下文實例相關聯的年和時區（分別用 @YEAR 和 @TIMEZONE 表示）。因此，對於第一個 daemon.log 記錄，Substitute 中的設置產生字符串 Mar 02 2006 06:27:35 -0700。

忽略 Substitute extension class 字段，這個字段允許提供一個 Java 類來進行進一步的替換，將替換的結果轉換為正確的類型。可以使用 java.text.SimpleDateFormat 格式字符串完成這一任務。將 Time format 設置為 MMM dd yyyy hh:mm:ss Z，這表示 3 個字母的月份名、2 位的天數、4 位的年份以及由冒號分隔的小時、分鐘和秒，還有一個 RFC 822 時區。

圖 13 顯示 creationTime 的最終設置。如果保存配置文件並重新運行適配器，那麼 Formatter Result 面板應該會顯示一個具有 creationTime="2006-03-02T13:27:35.000Z" 屬性的新 XML 記錄。

圖 13. 將輸入的時間戳解析為 creationTime 屬性

獲得消息

msg 屬性是另一個 CBE 必要屬性。按照以下步驟添加這個屬性，並創建解析器任務來提取合適的值：

右擊 CommonBaseEvent，然後點擊 Add > msg。

點擊 msg，然後選中 Required by parent 復選框。

展開 msg，然後點擊 Substitution Rule。

在 Positions 字段中指定 2，因為日志項的消息部分位於第二個位置。（它是分隔符後的所有內容。）

對於 Match，指定一個選擇整個字符串的正則表達式。正則表達式 ^(.*)$ 捕獲所有內容並表示為 $1。

對於 Substitute，指定 $1。

圖 14 顯示最終的設置。

圖 14. 提取消息的設置

保存配置文件並點擊 Extractor Result 面板中的 Rerun adapter。點擊 Next event 並切換到 Formatter Result 面板。應該會看到新的 msg 屬性，msg="Session from 71.65.224.25"。

尋找源

CBE 記錄的最後一個必要部分是 sourceComponentId，它用來記錄事件所影響的組件（服務、系統等等）。在 daemon.log 這個示例中，影響的組件是在特定主機上運行的軟件服務。解析器的任務是捕獲並記錄特定的組件。

再次右擊 CommonBaseEvent，然後點擊 Add > sourceComponentId。（圖 15 顯示可以添加到 CBE 中的所有屬性。）為了明確，表 2 給出了 sourceComponentId 所需的所有設置。一個新設置是 Default value。如果分析規則發現匹配，但是沒有提供替換值，那麼使用 Default value。

圖 15. 可以添加到 CBE 記錄中的元素和屬性列表

表 2. sourceComponentId 的設置
Item Default value Required by parent Positions Match Substitute 說明 component 　 Yes 1 ^.* db (\w+)\[.*$ $1 捕獲軟件服務的名稱，比如 pop3ad 或 mysqld。 componentIdType ServiceName Yes 　 ^(.*) 　表示組件記錄服務的名稱；根據 CBE 規范，ServiceName 是這個屬性的規定值之一。 componentType daemon Yes 　 ^(.*) 　描述組件的類。 location db.linux-mag.com Yes 　 ^(.*) 　指定與組件位置對應的物理地址。location 值的格式由 locationType 屬性指定。對於這個屬性，建議使用完全限定的主機名。在這裡，因為日志項不包含主機名，所以通過默認值添加主機名。在其他情況下，可以從日志中直接解析出主機名。 locationType Hostname Yes 1 ^(.*) 　指定 location 屬性中的值的格式和含義。可以使用許多關鍵字，在這裡使用 Hostname 關鍵字。 subComponent 　 Yes 　 ^.*\[(\d+)\].* $1 表示事件影響的特定守護進程。

如果完成了表 2 中列出的所有修改，然後保存並重新運行適配器，那麼應該會產生與清單 15 相似的 CBE 事件記錄。作為另一個練習，將 situation 添加到 CBE 中。situation 描述造成事件的情況類型。例如，可以創建一個解析器以便在最初聯系守護進程時創建一個 StartSituation，或者創建另一個解析器以便在進行請求時創建一個 RequestSituation。

situation 不是必需的（因此，可以禁用 Required by parent），但是它們有助於增加 CBE 記錄的針對性。如果創建一個 situation 並添加一系列 situation 解析器，那麼可以選擇 Child choice 復選框，從而決定在產生匹配之後是否可以停止處理。

對於調試自己的解析器，有一個有幫助的技巧：如果需要一個屬性，但是在（從提取器傳遞給解析器的）輸入記錄中沒有找到，那麼 Formatter Result 面板對於這個記錄是空的。換句話說，必要屬性的表現就像是邏輯 AND：如果出現不匹配，那麼對這個記錄的處理就會停止。所以，在調試規則時取消選中 Required by parent 復選框常常是有幫助的。緩慢且漸進地構建規則，同時通過觀察 Problem 面板來尋找問題的線索。

格式化器和對輸出器進行組織

既然解析器已經產生了屬性和值，就必須將新數據組合成 CBE 實例。這就是格式化器的作用。

將 CBE XML 記錄輸出到文件

適配器格式化器不要求配置。它是一種內部操作，創建符合 CBE V1.0.1 規范的 CBE 對象。

在格式化器創建 CBE 對象之後，由輸出器將這些對象輸出到文件、標准輸出、另一個日志、日志記錄代理或日志分析程序。如果適配器配置定義了多個上下文，那麼可以使用一個特殊的格式化器，讓多個上下文向同一個文件中寫記錄。

為了簡化，將 CBE XML 記錄輸出到一個文件：

點擊 Generic Log Adapter 透視圖中的 Outputter，然後為 Outputter type 選擇 SingleFileOutputter。

右擊 Outputter，然後點擊 Add > property。

點擊新屬性，然後將 Property name 設置為 directory。將 Property value 設置為一個您能夠寫文件的目錄。忽略文件名。只指定目錄的路徑，不帶末尾的斜線。

再次右擊 Outputter 並點擊 Add > property。將新的 Property name 設置為 fileName，將 Property value 設置為文件名。將在 directory 指定的目錄中創建這個文件。

修改上下文實例

除了修改配置，還必須修改上下文實例以使用適當的輸出器類。為此，執行以下步驟：

展開 General Log Adapter 透視圖中的 Contexts 並展開 Context Basic Context Implementation。

點擊 Component Logging Agent Outputter。

將 Name 和 Description 改為 Single File Outputter。

將 Executable 類改為 org.eclipse.hyades.logging.adapter.outputters.CBEFileOutputter。

保存配置文件。

添加 SingleFileOutputterType

還有一個重要的步驟：由於某種原因，Adapter Configuration Editor 會忽略適配器配置文件的輸出器定義中的一個重要元素。（可以在 developerWorks 自主計算論壇的 No Output from Outputter 上找到相關內容。）但是，可以快速地將這個元素手工添加到文件中。

使用編輯器打開文件 my.adapter。滾動到文件底部，尋找以下文本。

清單 16. 適配器配置

<cc:Outputter 　description="Single　File　Outputter" 　uniqueID="N13725210AFF11DA8000AE8373D52828" 　type="SingleFileOutputter"> 　　<pu:Property　propertyName="directory" 　　　propertyValue="/home/mstreicher"/> 　　<pu:Property　propertyName="fileName" 　　　propertyValue="emitter.log"/> 　　<op:SingleFileOutputterType　directory="/home/mstreicher" 　　　fileName="emitter.log"/> </cc:Outputter>

如果缺少 <op:SingleFileOutputterType... /> 行，那麼添加它並修改 directory 和 fileName 屬性的值，以匹配另外兩個屬性的值。然後保存文件。

運行 GLA

基於規則的適配器現在完成了。利用 Extractor Result 面板中的控件分步處理模板日志文件並檢驗其操作。如果確認一切正常，就可以使用單獨的 GLA 來運行適配器。

使用 GLA 運行適配器

GLA 使用在適配器中創建的設置讀取日志文件並生成一個 CBE XML 文檔。清單 17 給出 my.adapter 文件的一小部分。

清單 17. my.adapater 文件的片段

<adapter:Adapter... 　<cc:ContextInstance　　　charset="" 　　continuousOperation="true" 　　description="A　context　for　daemon.log" 　　isoCountryCode=""　isoLanguageCode="" 　　maximumIdleTime="120" 　　pauseInterval="120" 　　timezone="-0700" 　　uniqueID="N05306B00AFF11DA8000AE8373D52828" 　　year="2006"> 　<cc:Sensor 　　description="Read　the　daemon.log" 　　uniqueID="N057E8B10AFF11DA8000AE8373D52828" 　　confidenceBufferSize="1024" 　　fileFooterSize="0" 　　maximumBlocking="10" 　　type="SingleFileSensor"> 　　　<pu:Property 　　　　propertyName="directory" 　　　　propertyValue="/home/mstreicher/java-tptp-gla" 　　　/> 　　　<pu:Property 　　　　propertyName="fileName" 　　　　propertyValue="daemon.log" 　　　/> 　　　<sensor:SingleFileSensor 　　　　directory="/home/mstreicher/java-tptp-gla" 　　　　fileName="daemon.log"'　　　　/> 　</cc:Sensor> 　<ex:Extractor 　　containsLineBreaks="false" 　　description="Divide　daemon.log　into　individual　records" 　　endPattern="$" 　　includeEndPattern="false" 　　includeStartPattern="false" 　　lineBreakSymbol="" 　　replaceLineBreaks="false" 　　startPattern="^" 　　uniqueID="N05AA7D00AFF11DA8000AE8373D52828" 　/> . </adapter:Adapter>

要運行 GLA，首先必須編輯它的腳本，指向安裝它的位置。使用編輯器打開 GenericLogAdapter/bin 中的 gla.sh 文件。（如果嚴格按照安裝說明進行安裝，那麼這個文件位於 ~/java/GenericLogAdapter/bin/gla.sh。）找到 GLA_HOME=/home/eclipse/GenericLogAdapter 行，將路徑改為指向包含 GLA 副本的目錄。如果嚴格按照說明進行安裝，那麼將這一行改為 GLA_HOME=~/java/GenericLogAdapter。保存文件。

接下來，在自己的 Eclipse 工作空間的 My Adapter 目錄下找到 my.adapter 文件。在測試系統上，my.adapter 在 ~/workspace/My Adapter/my.adapter 中。為了運行適配器，執行 gla.sh，提供適配器文件的路徑作為惟一的參數：

%　~/java/GenericLogAdapter/bin/gla.sh　~/workspace/My\　Adapter/my.adapter

過一會兒，emitter.log 文件應該會出現在您的主目錄中（或者在輸出器配置中指定的創建文件的目錄中）。

結束語

本教程演示了如何創建基於規則的適配器，從而將典型的 Linux 日志文件轉換為 CBE 日志文件。有了 CBE 日志，就可以使用 Autonomic Computing Toolkit 的 Log and Trace Analyzer 這樣的工具來進一步處理 CBE 數據。

另外，如果 Adapter Configuration Editor 提供的規則構造不適合您的日志文件，也可以集成自己的 Java 類來解析並輸出 CBE 格式。與基於規則的適配器不同，靜態適配器（之所以稱為靜態適配器是因為它使用 Java 類而不是規則）只需要檢測器和輸出器，它們由 Java 代碼提供。仍然采用最終的配置文件來運行 GLA，但是在 GLA CLASSPATH 中必須包含您的 Java 類。

無論是哪種情況，Adapter Configuration Editor 和 GLA 都提供了一個強大的環境，在這個環境中可以使用現代的自主計算工具來分析現有的（甚至遺留的）應用程序的行為。從任意數量的日志文件格式轉換到 CBE 只需要做很少的工作；利用規則或自己的代碼，就可以輕松地完成復雜的轉換。