Tivoli Application Manager for Transactions 實現可用性和響應時間管理：案例研究

轉自http://www.ibm.com/developerworks/cn/webservices/ws-itcamtransaction/

案例介紹

一個股票交易公司為終端使用者提供了股票交易服務。終端使用者通過 Web 瀏覽器訪問股票交易服務，比如 Internet Explorer 和 Firefox，然後執行以下操作：登入/登出系統、檢視最新的股票報價、在股票帳戶和他們的銀行帳戶之間轉帳，買進/售出股票並查詢交易歷史。

圖 1 展示了交易系統的架構。股票交易服務依賴於圖 1 所示的三個服務 —— 客戶資訊管理服務、股票報價/買入/賣出服務，以及轉帳服務。後兩種服務由外部提供商提供，因此，不受該股票交易公司的 IT 部門的管理。

圖 1. 交易系統架構

股票交易公司要想減少使用者投訴並保持使用者忠實度，服務的可用性和股票交易系統的響應時間是至關重要的。具體來講，存在下面幾個需求：

1. 應當對實際使用者所體驗的可用性和響應時間進行監視。無論任何時候，只要服務質量降低到預定義的閾值，都應當及時將問題報告給 IT 部門。
2. IT 部門可以主動監視系統可用性和響應時間，並在使用者報告之前發現問題。
3. 當察覺到上面提到的問題時，應當可以很輕鬆地將問題與特定的元件或互動隔離。

回頁首

使用 ITCAM 提供事務解決方案

基本上，有兩種不同的方法可以監視應用程式的可用性和響應時間，第一種方法是對真實的終端使用者的事務進行監視，另一種是主動監視。真實的終端使用者事務監視將監視由終端使用者觸發的事務；而主動監視將通過記錄並回放事務來模擬真實的終端使用者的體驗（如果他們在當時執行了一個事務的話），從而對事務進行監視。

ITCAM for Transactions 7.1 提供了一個全面的解決方案來滿足 SOA 環境中對服務可用性和響應時間管理的需求，並且同時支援真實的終端使用者事務監視和主動監視。ITCAM for Transactions 是一個構建在 IBM Tivoli Monitoring 框架之上的代理集合，具體包括：

• Web Response Time (WRT) 代理實時監視真實的終端使用者可用性和響應時間體驗。
• Robotic Response Time (RRT) 代理使用記錄的回放指令碼主動監視服務可用性和響應時間。
• 當出現與可用性和響應時間有關的問題時，Transaction Collector (TC) 代理和 Transaction Reporter (TR) 代理將隔離問題並使用事務拓撲圖進行診斷。

服務可用性和響應時間是從事務的角度進行監視的。在本文的場景中，典型的事務例子包括股票買進、股票報價、轉帳，等等。下面的圖 2 展示瞭解決方案架構。

圖 2. ITCAM for Transactions 架構

要執行本文的步驟來演示如何構建這個完整的解決方案，至少需要使用 6 臺機器（機器 M1 到 M6）。

您需要按照以下方式配置基礎環境：

• 在機器 M1 上安裝 Tomcat 5.5，然後將 StockCenterProject.war 部署到這個 Tomcat。
• 在機器 M2 上安裝 Tomcat 5.5，並將 BankFundService.war 部署到這個 Tomcat。
• 在機器 M3 上安裝 WebSphere Application Server 6.1，並將 TradeSystem.war 部署到這個 WebSphere Application Server。
• 在機器 M4 上安裝 DB2 8.5 或更高版本，並建立客戶資訊資料庫。

我們在此使用 Tomcat 而不是使用 WebSphere 託管 Stock Exchange Center 和 Bank 應用程式的原因是它們都是外部服務，應用伺服器的型別並不重要。

ITCAM 解決方案產品應當按照以下方法進行安裝和配置：

• 安裝 ITM 6.2, ITCAM for Transactions – 在機器 M5 上安裝 AMC 代理和 TR 代理。
• 安裝 ITCAM for Transactions – 在機器 M3 上安裝 WRT 代理和 TC 代理。
• 安裝 ITCAM for Transactions – 在 M6 上安裝 RRT 代理。

假設您具有基本的 ITM 知識。如果對它們不熟悉的話，請參考 “術語” 部分，並參考 ITM 資訊中心瞭解詳細內容。

回頁首

監視真實的終端使用者事務

WRT 代理通過觀察來自網路卡的 HTTP 請求/響應來監視真實的終端使用者的事務可用性和響應時間。您首先需要將 HTTP URL 對映到有意義的業務事務，然後建立 ITM Situations 來定義閾值。要完成這些任務，需要執行以下步驟：

建立事務定義

通過單擊工具欄上的 Application Management Configuration 圖示，開啟 Application Management Configuration Editor (AMCE)。

1. 定義 Stock Trade 事務以捕捉 HTTP 請求/響應，URL 類似 *TradeSystem*，如圖 3 和圖 4 所示：
   
   圖 3. 定義 Stock Trade 事務的過濾器
   
   
   
   
   圖 4. 定義 Stock Trade 事務的 Reporting 模式
   
   
   
2. 建立一個 Profile 來包含剛剛定義的事務，然後將 Minimum Response Time 設定為 2 秒，如圖 5 所示，然後將 profile 釋出給 WRT 代理。
   
   圖 5. 建立 profile
   
   
   
3. 單擊 OK 以確認修改並關閉 AMCE 視窗。

建立解決方案

1. 通過單擊工具欄上的 Situation Editor 圖示開啟 Situation 視窗。
2. 建立如圖 6 所示的場景。當應用程式中超過 10% 的事務變慢（長於 2 秒），那麼這個場景就會被觸發。
   
   圖 6. 建立場景
   
   
   

出現問題後……

當出現與響應時間有關的問題後，您首先會收到事件通知，這是由您定義的場景觸發的，如圖 7 所示。

圖 7. 場景被觸發後將彈出事件

在 Transactions 工作空間中，我們可以看到具體的變慢的事務。顯然，從下面的圖 8 中，您會看到出現問題的事務是 /TradeSystem/TradeSysCall

圖 8. WRT Workspace 顯示事務資訊

在 AMC 工作空間中，可以看到企業環境中的所有應用程式的完整狀態。可以從圖 9 中看到，最慢的事務 /TradeSystem/TradeSysCall 被 Web Response Time 代理和 Transaction Reporter 代理同時捕獲。在後面的小節中，您將看到如何將問題與 Transaction Reporter 代理隔離。

圖 9. AMCE 工作空間顯示事務的完整狀態

回頁首

主動監視服務可用性和響應時間

我們可以使用 Rational Performance Tester (RPT) 來記錄事務並使用 RRT 代理來回放這些事務，從而執行主動監視。當為我們回放的事務定義好閾值後，我們就可以在出現效能問題時收到警告事件，並在問題影響到真實的終端使用者之前採取修復措施。

1. 使用 RPT 記錄指令碼，將指令碼上傳到 AMC

RPT 是一個效能測試工具，用於識別是否存在系統效能瓶頸以及引起瓶頸的原因，您可以使用它的記錄功能來記錄希望進行監視的事務。在安裝 RPT 後，您就可以開始記錄事務並將指令碼上傳到 AMC 了。這些指令碼應當根據真實的終端使用者的使用情況進行記錄。

在本文中，我們將記錄一個名為 BuyStock 的 RPT 指令碼，從而模擬一個真實的終端使用者在我們的股票交易系統中執行一些主要操作的情景，比如登入、檢視股票價格、將資金從銀行轉到股票帳戶，以及購買股票。這個指令碼類似圖 10 所示：

圖 10. RPT 指令碼視窗

2. 為 RRT 定義 profile 以回放指令碼

在記錄好 RPT 指令碼後，您可以將它們上傳到 AMC 並定義一個 profile 來回放它們。如圖 11 所示，您可以定義一個名為 StockApp 的 profile，每 15 分鐘回放一次指令碼 BuyStock，然後為其定義一個效能閾值。該閾值應當根據平均體驗值或服務水平協議定義。Min Response Time Threshold 屬性用於定義該閾值，在這裡我們將事務閾值設定為 10.0 秒。

圖 11. 用於 RPT 指令碼回滾的 Profile 定義

3. 識別最慢的事務

當您在 RRT 代理上回滾了 RPT 指令碼後，就可以從 AMC 代理工作空間中檢視事務響應時間資料。該工作空間列出了在我們的整個環境中進行監視的所有應用程式。當應用程式的響應時間慢於 Min Response Time Threshold，它的 Overall Status 將被修改為 Warning 或 Critical，如圖 12 所示：

圖 12. AMCE 工作空間中的應用程式狀態

當我們注意到 BuyStock 應用程式的 Overall Status 變為 critical 時，我們可以連線到相應的 RRT 代理來檢視此應用程式的詳細資訊，例如，我們可以向下鑽取此應用程式的事務和子事務，以找出最慢的事務和子事務。

可以從圖 13 中看到，指令碼 BuyStock 的響應時間被分解為包含在該指令碼中的每個子事務的響應時間。您可以看到 TradeResult 是最慢的事務。在我們的股票交易系統中，TradeResult 的任務就是將交易請求提交到後端系統並將交易結果反應給終端使用者。要找出引起事務響應時間變慢的因素，我們可以使用 Transaction Tracking 代理來幫助我們分離問題。

圖 13. RRT 工作空間中的子事務資訊

回頁首

分離效能下降問題

當我們找到響應時間最慢的事務後，可以使用 TC 代理和 TR 代理來向下鑽取該事務並分離可能引起效能下降問題的元件，比如 web 應用伺服器、資料庫或後端 web 服務。

1. 在上下文中從 AMC 工作空間啟動到 Transaction Reporter 工作空間

轉到 AMC 工作空間並展開 Applications 節點，找到 BuyStock 項，單擊它，隨後我們可以看到在 Transactions 表中有兩個項，一個用於 RRT 代理，另一個用於 TR 代理。右鍵單擊 Transaction Reporter 代理項的連結錨點；當彈出一個選單後，選擇 Transaction Topology 選項，如圖 14 所示，它將連結到 Transaction Reporter Agent 的 Transaction Topology 工作空間。

圖 14. 在上下文選單中啟動

2. 在 Transaction Reporter 工作空間中分離問題

在此工作空間中，我們看到了 Buy Stock 事務的完整拓撲。從圖 15 的拓撲中可以看到，fundCall 節點上有一個紅色箭頭，它表示正是該節點使 Buy Stock 事務變慢。通過進行分析，fundCall 的響應時間就是用於呼叫 Bank 服務的響應時間。因此，造成效能下降的根本原因是因為 Bank 服務的響應時間較慢，這屬於外部服務問題。隨後我們可以要求 Bank 服務的提供商處理它。

圖 15. TR 工作空間中的事務拓撲檢視

回頁首

結束語

本文描述了在 SOA 環境中用於解決典型響應時間變慢問題的基於 ITCAM for Transactions 的解決方案，並展示瞭如何部署和配置它。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-665650/，如需轉載，請註明出處，否則將追究法律責任。