用IBM Tivoli Monitoring 监视Q 复制

最新推荐文章于 2020-06-24 00:52:22 发布

ciwuli2087

最新推荐文章于 2020-06-24 00:52:22 发布

阅读量311

点赞数

文章标签：数据库运维 java

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 以及显示来自 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 配置示例

要进一步了解 Q Replication 和 SQL 复制，请参阅 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 数据流

需要的软件

本文描述如何针对 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 状态表

因为每个 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）数据提供者收集监视信息。

打开Manage Tivoli Enterprise Monitoring Services。
右击Universal Agent with Task/Subsystem Primary并选择create instance...。
在打开的屏幕上，输入新 Universal Agent 实例的名称，例如 “Q_REPL_AGENT”。
右击刚才创建的新 Universal Agent 实例并选择configure using defaults。
当问您是否要 “update the file KUMENV_Q_REPL_AGENT prior to configuration of the universal agent” 时，单击Yes。

在打开的文本编辑器中，将

*-----------------------------------------------------------------*
* 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

关闭文本编辑器之后，询问您是否希望现在就配置代理。单击Yes。
为了检查配置是否成功，查看新代理名左边的红色惊叹号是否变成了绿色的圆。

接下来，为 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 输出示例

编辑元文件

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 元文件，使用键属性一般是好做法，因为它可以防止在执行 SQLselect语句时多次添加同样的数据行，而且大多数 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


	关于下载方法的信息

参考资料

学习

您可以参阅本文在 developerWorks 全球站点上的英文原文。
“WebSphere Information Integrator —— Q 复制” （developerWorks，2005 年 4 月）：介绍 Q Replication 及其架构。
“Q Replication Live Monitor” （developerWorks，2005 年 9 月）：介绍 Q 复制的实时监视工具。
针对 Q Replication 的developerWorks 信息管理路线图
Tivoli Enterprise Portal User Guide：关于状态定义和 Enterprise Portal。
在DB2 UDB, DB2 Connect and DB2 Information Integrator Version 8 product manuals页面上可以找到
“Introduction to Replication and Event Publishing” （GC18-7567-00）和
“Replication and Event Publishing Guide and Reference” （SC18-7568-00）。
DB2 Information Center：DB2 信息中心。
Tivoli Information Center：所有 Tivoli 相关信息的好来源。
Tivoli Software Information Center：下载所有 Tivoli 相关产品文档。
Tivoli Universal Agent：可以找到关于 Tivoli Universal Agent 的信息。
developerWorks Information Management 专区：学习关于 DB2 的更多知识。在这里可以找到技术文档、how-to 文章、培训、下载、产品信息等等。
随时关注developerWorks 技术活动和 webcast。

获得产品和技术

下载WebSphere Information Integrator V8.2的试用版本。
下载Tivoli Monitoring Express V6.1的试用版本。
Q Replication Tools：概述了可以帮助 WebSphere Information Integrator 复制和事件发布客户进行配置、监视和问题诊断的免费软件工具。
使用IBM 试用软件构建您的下一个开发项目，这些软件可以从 developerWorks 直接下载。

讨论

参与developerWorks blogs并加入 developerWorks 社区。

关于作者


		Daniel Martin 是 University of Stuttgart 的副研究员。他是 Triple Space Communication（Tripcom，www.tripcom.org）项目的成员，他在那里的研究重点是消息传递、triple space 架构和 Web 服务。在回大学工作之前，他曾在 IBM Boeblingen Lab 的 DB2 Performance Expert Team 中工作。