用IBM Tivoli Monitoring 監視Q 複製

CloudSpace發表於2009-01-12
IBM
IBM® Tivoli® Monitoring 是為監視企業應用程式的狀態和效能而設計的一個產品家族。本文將講解如何訪問 Q Replication 監視資訊、如何將這些資料傳入 Tivoli 平臺中，以及如何使用 Tivoli 警報和狀態讓 Q 複製在發生嚴重的事件時收到通知。

簡介

在以非常低的延遲複製大量資料方面，IBM WebSphere® Information Integrator Q Replication 是第一選擇。在進行復制的任務關鍵型環境中，希望能夠輕鬆地看到總體的系統狀態，並在某些東西發生錯誤時立即得到通知。這正是 IBM Tivoli Monitoring 的用武之地。它為所有業務相關應用程式提供了一個報告其當前狀態的中心位置，使管理員能夠看到這些系統的總體狀態。

因為沒有專門用於 Tivoli Monitoring 的 Q Replication 代理，所以本文將講解如何訪問 Q Replication 監視資訊、如何將這些資料傳入 Tivoli 平臺中，以及如何使用警報和狀態在發生嚴重的事件時收到通知。


圖 1. Tivoli Enterprise Portal Client 中的 Apply_Monitor 屬性組
圖 1. Tivoli Enterprise Portal Client 中的 Apply_Monitor 屬性組

圖 1 顯示了 Tivoli Enterprise Portal Client 以及顯示來自 Q Replication 的動態資料的圖形。這些圖形會自動更新，所以總是反映最新的資訊。您還可以使用 Tivoli Monitoring 的 “Historical Data Collection” 特性顯示以前任何時間點的資料。

IBM Websphere Information Integration Q Replication

Q Replication 主要由兩個程式組成：

  • Q Capture
  • Q Apply

Capture 程式監視源表上的修改並將提交的事務資料轉換為訊息。這些訊息通過 WebSphere MQ 訊息佇列傳送到目標位置。在目標位置，Apply 程式從佇列中讀取訊息，並將訊息轉換回事務資料。然後用一個高度並行的方法將事務應用到目標表，從而維持資料的完整性。圖 2 顯示一個 Q Replication 配置示例。


圖 2. Q Replication 配置示例
圖 2. Q Replication 配置示例

要進一步瞭解 Q Replication 和 SQL 複製，請參閱 DB2 UDB, DB2 Connect and DB2 Information Integrator Version 8 product manuals 頁面上的 “Introduction to Replication and Event Publishing” （GC18-7567-00）。

IBM Tivoli Monitoring

IBM Tivoli Monitoring 平臺這套產品能夠監視和管理各種平臺上的系統和網路應用程式。這些產品監視一個或多個專用工作站上企業系統的所有部分的可用性和效能，可以使用它提供的報告跟蹤趨勢和排除故障。

Monitoring 平臺由以下產品組成：

  • Tivoli Enterprise Portal Client (1)：一個用來檢視和監視企業系統的基於 Java 的使用者介面。
  • Tivoli Enterprise Portal Server (2)：客戶機使用這些軟體元件獲取、操縱和分析來自監視企業應用程式的代理程式的資料。
  • Tivoli Enterprise Monitoring Server (3)：作為一個收集和控制點，可用它來收集和控制來自代理的警報。它還從代理收集效能和可用性資料並將資料傳遞給門戶伺服器。
  • Tivoli Enterprise Monitoring Agents (4)：這些元件安裝在要監視的系統或子系統上。這些代理收集資料並將資料傳送到進行監視的伺服器。例如，Tivoli Monitoring for Databases 包含用於資料庫產品的代理。


圖 3. IBM Tivoli Monitoring 資料流
圖 3. IBM Tivoli Monitoring 資料流

需要的軟體

本文描述如何針對 Q Replication 設定 Tivoli Universal Agent。本文假設已經安裝了 Websphere II 和 Tivoli Monitoring。關於設定這些產品的資訊，請參閱下面 “相關參考資料” 一節中的文件。

  • IBM Tivoli Monitoring Version 6.1.0
  • IBM Tivoli Universal Agent Version 6.1.1
  • IBM WebSphere Information Integrator Version 8.2

相關參考資料

關於規劃、配置和管理 Q Replication 環境的更多細節，請參閱 DB2 Information Center 和 DB2 UDB, DB2 Connect and DB2 Information Integrator Version 8 product manuals 頁面上的 “Replication and Event Publishing Guide and Reference”（SC18-7568-00）。

可以在 Tivoli Software Information Center 下載所有 Tivoli 相關產品。另外，如果需要其他資訊，請訪問 Tivoli Universal Agent 的產品 Web 站點。



訪問 Q Replication 狀態資訊

每個 Capture 和 Apply 程式都有一組對應的控制表。這些表儲存在與 Q Apply 和 Q Capture 程式相同的位置，其中包含配置值和要訪問的狀態資訊。可以在複製設定期間定義的 Capture 和 Apply 模式中找到這些表。
圖 4 顯示一個來自 Q Apply 程式的監視控制表示例。


圖 4. Q Apply 狀態表
圖 4. Q Apply 狀態表

因為每個 Q Apply 和 Q Capture 程式都可能在不同的系統上執行，而控制表是程式本地的，Tivoli Monitoring 需要單獨連線每個系統。下一節將提供詳細步驟。

如果希望獲得所有 Q Replication 控制表的完整列表並瞭解它們包含的內容，那麼請參閱 Replication and Event Publishing Guide and Reference 中的對應章節。



設定 Tivoli Universal Agent

關於如何安裝 Universal Agent 的詳細說明，請參閱 Installing monitoring agents 和產品 CD-ROM 中的文件。有關的更多資訊，請參閱 Tivoli Universal Agent User's Guide。

在成功地安裝 Universal Agent 之後，按照以下步驟進行設定並配置一個新的代理例項，這個代理例項使用 Open Database Connectivity（ODBC）資料提供者收集監視資訊。

  1. 開啟 Manage Tivoli Enterprise Monitoring Services。
  2. 右擊 Universal Agent with Task/Subsystem Primary 並選擇 create instance...。
  3. 在開啟的螢幕上，輸入新 Universal Agent 例項的名稱，例如 “Q_REPL_AGENT”。
  4. 右擊剛才建立的新 Universal Agent 例項並選擇 configure using defaults。
  5. 當問您是否要 “update the file KUMENV_Q_REPL_AGENT prior to configuration of the universal agent” 時，單擊 Yes。
  6. 在開啟的文字編輯器中，將 

    *-----------------------------------------------------------------*
* UA Startup automatic start DP options                           * 
* (ASFS,APIS,FILE,SOCK,HTTP,SNMP,POST,WBEM,ODBC)                  *
*-----------------------------------------------------------------*
KUMA_STARTUP_DP=ASFS

    改為 

    *-----------------------------------------------------------------*
* UA Startup automatic start DP options                           * 
* (ASFS,APIS,FILE,SOCK,HTTP,SNMP,POST,WBEM,ODBC)                  *
*-----------------------------------------------------------------*
KUMA_STARTUP_DP=ODBC

  7. 關閉文字編輯器之後，詢問您是否希望現在就配置代理。單擊 Yes。
  8. 為了檢查配置是否成功，檢視新代理名左邊的紅色驚歎號是否變成了綠色的圓。

接下來，為 Universal Agent 建立一個元檔案。這個檔案描述了您想讓 Tivoli 平臺監視的資料，該檔案還包含配置資訊，比如資料來源名稱和 Universal Agent 的位置。

如果想省事兒，可以從 下載 一節中下載元檔案示例，然後跳到下面的 編輯元檔案 一節繼續閱讀。將下載的元檔案示例儲存在 IBM\ITM\TMAITM6\metafiles\ 下面。

生成元檔案

Universal Agent 附帶一個命令列工具，可以從現有的 ODBC 資料來源生成有效的元檔案。但是，需要對生成的檔案做進一步處理，使它符合自己的環境。

在使用 Universal Agent 工具生成元檔案之前，需要為儲存 Q Replication 控制表的資料庫設定 ODBC 資料來源名稱（DSN）。在 Windows 系統上建立 DSN 的步驟如下：進入 Administrative Tools, Data Sources (ODBC)，建立一個使用 DB2 ODBC 驅動程式的系統 DSN，選擇要監視的複製程式的 Q Replication 控制表所在的資料庫。

建立 DSN 之後，使用 IBM\ITM\TMAITM6 下面的 KUMPCON 工具。用 KUMPCON GENERATE YourDataSourceName user=YourUserID pswd=YourPassword 命令在一個控制檯視窗中啟動它，然後按照螢幕上的說明進行操作。

當詢問是否對特定的表名進行模式匹配時，回答 yes 並使用 “IBMQREP” 作為要匹配的模式。這樣的話，KUMPCON 工具只為以 IBMQREP 開頭的表生成後設資料（所有 Q Replication 控制表都以 IBMQREP 開頭）。

圖 5 顯示來自 KUMPCON 工具的輸出示例。


圖 5. KUMPCON 輸出示例
圖 5. KUMPCON 輸出示例

編輯元檔案

Tivoli Agent 元檔案是純文字檔案，可以用任何編輯器來編輯。在執行 KUMPCON GENERATE 之後，可以在資料夾 IBM\ITM\TMAITM6\metafiles 中找到生成的檔案。因為它是自動生成的，所以它的形式非常原始，需要進一步調整。下面列出可能需要修改的專案：

  • 資料型別：Tivoli Monitoring 使用自己的型別系統，所以來自外部的任何資料都必須使用一種 Tivoli 型別進行描述。元檔案中屬性定義的（簡化）語法如下： 

    attribute-name attribute-type maximum-size [KEY] [ATOMIC] [@help text]

    表 1 中列出了 Tivoli 的屬性型別。

    需要修改生成的元檔案的原因是 KUMPCON GENERATE 傾向於使用限制性非常大的型別，而且生成的 D（DisplayString）和 N（DisplayNumeric）型別的屬性比需要的多。這些屬性不能用於 Tivoli Enterprise Portal Client 中的條形圖、餅圖和計量圖。這些圖型別只接受純數值屬性（比如型別 G、C、A 或 #）。字元和日期屬性只能在表中顯示。另外，純數值型別在狀態定義中要靈活得多，比如在屬性 x 為字元（display*）型別時，if x > 10 這樣的規則是不可能的。

    一般規則是，對於只包含數值的屬性，應該總是使用數值型別。在這種情況下，如果屬性值來自 DB2，那麼可以在表定義中檢查列型別。



    表 1. Tivoli 資料型別
    型別 說明
    S 開關。布林值 0 或 1。
    G 計量。正的或負的整數。
    C 計數器。正的整數。
    A 平均值。收集的所有資料的平均值。
    D DisplayString。字串。
    N DisplayNumeric。數字字串。
    T 時間。格式是 CYYMMDDHHMMSSmmm（其中 C=1 表示 21 世紀）。
    # 差值。將屬性值表示為取樣之間的差。例如，如果取樣 1 的值是 100，取樣 2 的值是 120，那麼差值就是 20。
    % 變化的百分數。將屬性值表示為取樣之間的差的百分數形式。例如，如果 ReceiveCount 定義為 % 資料型別，取樣 1 的值是 100，取樣 2 的值是 120，那麼變化的百分數就是 20。
    ? 變化的速率。將屬性值表示為取樣之間每秒的變化。例如，如果 ReceiveCount 定義為 ? 資料型別，取樣 1 的值是 100，取樣 2 的值是 120，取樣 1 和 2 之間的時間是 5 秒，那麼變化的速率是每秒 4。


  • 屬性性質：屬性可以具有下面兩個性質之一，或者同時具有這兩個性質，或者都沒有：

    • Key：表示這個屬性是鍵屬性。Tivoli Monitoring 使用鍵屬性判斷多個事件是否有同樣的原因。鍵屬性幫助將具有同樣鍵屬性值的資料行關聯起來。當 Universal Agent 收到具有鍵屬性資料的資料行時，它檢查是否已經有鍵屬性值匹配的資料行。如果有的話，新的資料行就替換現有的資料行。 注意：每個屬性組最多允許有 5 個鍵屬性。

    • Atomic 表示這個屬性是原子性的。原子性的屬性意味著，如果此屬性上的一個狀態為真，那麼生成單獨的事件。例如，如果狀態定義是 IF mem_usage > 100。原子性的屬性 mem_usage 會為每個分配的記憶體大於 100MB 的程式生成一個事件。如果多個程式滿足這個條件，那麼每個程式產生單獨的事件。非原子性的 mem_usage 屬性的表現不一樣。即使有多個程式同時滿足條件，也只產生一個事件。

    對於 ODBC 元檔案，使用鍵屬性一般是好做法，因為它可以防止在執行 SQL select 語句時多次新增同樣的資料行，而且大多數 ODBC 表有一個或多個索引列在邏輯上與元檔案中的鍵屬性對應。

    注意：為了更靈活地在 Tivoli Enterprise Portal Client 中顯示資料，在屬性組定義中使用 SQL 子句只選擇最新的資料。但是，在 Portal Client 上的圖定義中過濾要顯示的屬性。另外，在 Portal Client 中建立圖形之前，一定要理解控制表的結構和資料。例如，IBMQREP_APPLYMON 表（和來自 元檔案示例 的 Apply_Monitor 屬性組）包含 Apply 程式的每個佇列瀏覽執行緒（對於 Apply 程式監聽的每個佇列有一個執行緒）的資料。應該使用 Enterprise Portals 對特性進行過濾和分組，從而為每個接收佇列建立單獨的圖形。

    要想了解如何在 Tivoli Enterprise Portal Client 中建立圖表，請參閱 Tivoli Enterprise Portal User Guide。關於 Q Replication 控制表的詳細資訊，請參閱 Replication and Event Publishing Guide and Reference。

  • 資料取樣方法：在 //NAME 語句中定義資料取樣方法和其他屬性組性質。下面是完整的語法： 

    //NAME attribute-group-name sample-method [time-to-live] [AddSourceName]
[AddTimeStamp] [Interval=] [SkipNonNumeric=Y/N] [@help text]

    取樣方法可以是下面 4 種方法之一：

    • P：定期輪詢資料，只有最新的資料集可以用於狀態監視和報告。
    • S：取樣資料的工作方式與輪詢資料相同，但是有多個資料集可供使用。
    • K：鍵資料的工作方式與取樣資料相同，但是允許將事件關聯起來。在每個組中，最多有 5 個屬性可以指定為鍵屬性。
    • E：事件資料不定期出現，出現時就被報告。

    對於 ODBC 資料，K（鍵取樣）是最合適的取樣方法，因為幾乎每個表都有至少一個鍵列，而且 DBMS 會確保它的語義。

    注意：應該將元檔案中的每個屬性組上的 Interval= 性質設定為與對應的 Q Apply 和 Q Capture 程式的 monitor_interval 引數相同的值。在命令列視窗中發出 asnqccmd capture_server=YourDB2Alias capture_schema=YourApplySchema qryparms 和 asnqacmd apply_server=YourDB2Alias apply_schema=YourApplySchema qryparms 可以獲得這個值。

還可能希望修改應用程式和屬性組名稱。另外，刪除不需要的所有屬性組和屬性。這會節省網路流量並提高 Tivoli Enterprise Portal Client 的響應速度。


清單 1. Apply_Monitor 屬性組
//NAME Apply_Monitor K 300 Interval=20
//SOURCE ODBC DB2_TARGET user=***** pswd=*****
//SQL SELECT * FROM APPLY221222.IBMQREP_APPLYMON
order by monitor_time DESC fetch first 100 rows only
//ATTRIBUTES
MONITOR_TIME        D  28 KEY ATOMIC
RECVQ               D  48
QSTART_TIME         D  28
CURRENT_MEMORY      C  999999
QDEPTH              C  999999
END2END_LATENCY     C  999999
QLATENCY            C  999999
APPLY_LATENCY       C  999999
TRANS_APPLIED       C  999999
ROWS_APPLIED        C  999999
TRANS_SERIALIZED    C  999999
             ...

在使用來自本文的 下載 一節的元檔案示例時，一定要修改它，以便匹配自己的系統 ODBC DSN、控制表模式、應用程式和屬性組名稱。還應該檢查是否需要修改元檔案 //SQL 定義中的 SQL 語句。另外，按照上面的說明，確保將每個屬性組的 Interval= 語句設定為正確的值。

在編輯元檔案時，一定要在命令列視窗中用 KUMPCON VALIDATE metafile-name 檢驗它的語法。

啟動 Universal Agent 例項

在啟動 Universal Agent 例項之前，需要告訴它在哪裡尋找應該使用的元檔案。這要使用在前面步驟中為 Universal Agent 例項建立的配置檔案。在預設安裝中，可以在 IBM\ITM\TMAITM6\work\KUMPCNFG_[$YOUR_AGENTS_INSTANCE_NAME] （例如，IBM\ITM\TMAITM6\work\KUMPCNFG_Q_REPL_AGENT）中找到這個檔案，其中的 [$YOUR_AGENT_INSTANCE_NAME] 代表在 設定 Tivoli Universal Agent 中給新的代理例項起的名稱。如果這個檔案不存在，那麼只需建立具有這個名稱的空文字檔案，在文字編輯器中開啟它並新增一行，輸入想讓代理在啟動時裝載的每個元檔案的名稱。另外，確保將 KUM_WORK_PATH 和 KUMP_INIT_CONFIG_PATH 環境變數設定為正確的值。

如果 Universal Agent 已經在執行了，希望匯入新的元檔案而不停止代理，那麼可以使用 KUMPCON IMPORT metafile-name 啟用新的元檔案。另外，如果希望更新現有的活躍元檔案而不中斷服務，那麼可以使用 KUMPCON REFRESH metafile-name。

現在可以啟動新的 Universal Agent 例項，操作方法是右擊 Manage Tivoli Enterprise Monitoring Services，然後在上下文選單中選擇 Start。在開啟 Portal Client 時，應該會看到一個由 universal data provider 監視的新應用程式，而且對於元檔案中的每個屬性組，這個應用程式下面有一個單獨的工作空間。圖 1 顯示來自 元檔案示例 的 Apply_Monitor 屬性組，它使用不同的圖形呈現複製的當前狀態。

要想進一步瞭解 KUMPCON、元檔案和 Universal Agent 配置，請參閱 Universal Agent User Guide。

故障排除

如果有什麼錯誤，首先要檢視的地方是 IBM\ITM\TMAITM6\logs 中的 Universal Agent 日誌目錄。如果 Universal Agent 正在執行，但是表現不符合期望，那麼應該啟動 Tivoli Enterprise Portal Client 並檢視出問題的 Universal Agent 例項的 Data Provider Log（DPLOG）工作空間。DPLOG 工作空間與系統控制檯日誌相似。它提供來自資料提供者的詳細審計資料。

如果代理例項啟動了，但是沒有出現在 Portal Client 中，那麼還應該檢查 Universal Agent 配置中是否有主監視伺服器的正確 IP 地址或主機名。

可以在 Manage Tivoli Enterprise Monitoring Services 下面設定這個值，操作方法是右擊 Universal Agent 例項，然後單擊 Advanced，單擊 Configure advanced...，然後單擊 OK。開啟的視窗中包含主監視伺服器的代理連線設定。

用於 Q 複製的狀態和警報

狀態是一個邏輯表示式，涉及元檔案中定義的一個屬性組中的一個或多個屬性。狀態用來監視網路中系統的條件和健康狀態。它們可以在造成它們的系統上觸發可執行程式的執行，也可以通知管理員發生了某一事件。可以使用 Situation Editor 管理來自 Portal Client 的狀態。

每個專用的代理都附帶一組預定義的狀態。可以按原樣啟用它們，也可以修改它們來建立自己的狀態。我們用來監視 Q Replication 的 Universal Agent 沒有附帶預定義的狀態，因為它是通用的。因此，需要根據自己的情況為 Q Replication 提供一組狀態定義。另外，可以參考下表中的 “公式” 列，以便更好地瞭解 Portal Client 中表檢視的 “Threshold” 特性。

表 2. Q 複製狀態示例
名稱 說明 屬性組 公式
APPLY_E2E_LATENCY_LIMIT 如果來自被監視的 Apply 程式的任何佇列的端到端複製延遲達到某個值（這裡是大於 10 秒），那麼希望得到通知或者執行某個命令。 Apply_Monitor ( END2END LATENCY > 10000 )
APPLY_DETECT_SPILLING 如果 Apply 程式需要將一行 spill 到 Websphere MQ 中的 spill 佇列中，那麼希望得到通知或者執行某個命令。 Apply_Spilled_Rows ( SPILLQ != XXX )
APPLY_QDEPTH_LIMIT 如果在來自被監視的 Apply 程式的任何佇列中有太多的訊息等待處理，那麼希望得到通知或者執行某個命令。 Apply_Monitor ( QDEPTH > 50000 )
APPLY_DETECT_MONSTER_TX 如果在任何 Apply 佇列中有一個或多個事務超過了 Apply 程式的記憶體限制，那麼希望得到通知或者執行某個命令。 Apply_Monitor ( MONSTER TRANS != 0 )
APPLY_DETECT_MEM_FULL 如果由於代理正在使用所有可用記憶體，Apply 程式無法處理來自任何接收佇列的事務，那麼希望得到通知或者執行某個命令。 Apply_Monitor ( MEM FULL TIME != 0 )
APPLY_WARNING 如果 Apply 程式報告了一個警報訊息，那麼希望得到通知或者執行某個命令。 Apply_Trace_Log ( SCAN(OPERATION) == WARNING )
APPLY_ERROR 如果 Apply 程式報告了一個錯誤訊息，那麼希望得到通知或者執行某個命令。 Apply_Trace_Log ( SCAN(OPERATION) == ERROR )
CAPTURE_TX_SPILLED 如果 Capture 程式使事務溢位到磁碟或虛擬 I/O，那麼希望得到通知或者執行某個命令。 Capture_Monitor ( TRANS SPILLED != 0 )
CAPTURE_WARNING 如果 Capture 程式報告了一個警報訊息，那麼希望得到通知或者執行某個命令。 Capture_Trace_Log ( SCAN(OPERATION) == WARNING )
CAPTURE_ERROR 如果 Capture 程式報告了一個錯誤訊息，那麼希望得到通知或者執行某個命令。 Capture_Trace_Log ( SCAN(OPERATION) == ERROR )
QREP_HOTLIST_OFFLINE 如果 Q Replication 程式之一不再執行了，那麼希望得到通知或者執行某個命令。 NT Process ( MISSING (ProcessName) == ('asnqcap.exe','asnqapp.exe') )

在編輯狀態時，一定要在 Condition 選項卡下為狀態選擇適當的取樣間隔。還應該調整狀態定義的 Action 選項卡下的設定。尤其是需要將 “If the condition is true for more than one monitored item.” 或 “If the condition stays true over multiple intervals.” 等引數設定為正確的值。

在建立由來自不同代理的不同屬性組觸發的狀態時，Tivoli Monitoring 系統的真正實力才會顯現出來。這對於 Q Replication 非常有用，因為這個產品使用其他軟體執行它的部分工作。Q Replication 在作業系統上執行，使用 Websphere MQ 傳輸訊息，使用 DB2 捕捉和應用事務。顯然，Q Replication 是否能夠正常工作在很大程度上依賴於底層系統是否健康。

Tivoli Monitoring 產品系列已經為 Websphere MQ、DB2 和所有主流作業系統提供了專用的代理。應該安裝這些代理，並建立跨越 Q Replication 使用的所有軟體的狀態或工作流定義。例如，進行簡單的原因分析：如果 Q Replication 顯示錯誤而且 Websphere MQ Agent 向 Tivoli Monitoring 報告 Admin Queue 關閉了，那麼產生一個訊息，指出複製由於 WebSphere MQ 問題而停止了。

注意：只能建立使用同一屬性組中的屬性的狀態。如果希望在狀態中使用不同組中的屬性，那麼必須建立另一個狀態並將它嵌入第一個狀態中。也可以建立新的屬性組，其中包含要在狀態中使用的所有屬性。還可以使用 Workflow Editor 組裝出狀態。

關於狀態和 Portal Client 的更多資訊，請參閱 Tivoli Enterprise Portal User Guide。






用來監視 Q Replication 的其他工具

在談到 Q Replication 時，還應該提到其他一些工具。首先是 Q Replication 產品附帶的 Replication Alert Monitor，這個工具也可以從 Replication Control Center 獲得。

還有 “Q Replication Live Monitor”（developerWorks，2005 年 9 月），這個小型的輕量工具以圖形方式顯示實時延遲和吞吐量資訊，可以從 developerworks 獲得它。

第三個工具 Q Replication Dashboard 與 Live Monitor 非常相似，但是功能更多，可以從 Q Replication Tools 頁面獲得它。





結束語

本文講解如何用 IBM Tivoli Monitoring 監視 Q 複製。可以通過 Q Apply 和 Q Capture 程式所在的每個系統上的控制表獲得 Q 複製狀態資訊。通過為 Universal Agents ODBC 資料提供者建立元檔案來連線這些控制表。元檔案把要讀取的資料分組到屬性組中，並用 Tivoli 專用的資料型別描述每個屬性。配置並執行 Universal Agent 之後，可以使用 Tivoli Enterprise Portal Client 建立併發布狀態定義，從而在發生嚴重事件時得到通知（甚至執行定製的命令）。








下載

描述 名字 大小 下載方法
Sample metafile sample.mdl.zip 2KB HTTP
關於下載方法的資訊


參考資料

學習

獲得產品和技術

討論


關於作者

Daniel Martin 是 University of Stuttgart 的副研究員。他是 Triple Space Communication（Tripcom，www.tripcom.org）專案的成員，他在那裡的研究重點是訊息傳遞、triple space 架構和 Web 服務。在回大學工作之前，他曾在 IBM Boeblingen Lab 的 DB2 Performance Expert Team 中工作。

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

相關文章