datastage（IBM InfoSphere Information Server ）日志的获取和分析

在使用 IBM InfoSphere Information Server 的过程中我们经常会遇到一些问题，但如何来查找和诊断问题，对于一个刚刚使用 IBM InfoSphere Information Server 的用户来说这或许是一个很棘手的事情。但是不必担心，因为 IBM InfoSphere Information Server 产品从安装、运行到卸载都为我们提供了大量的多种形式的日志信息。通过本文我们可以了解如何获得 IBM InfoSphere Information Server 提供的日志信息，如何通过分析相应的日志来确定和解决我们遇到的问题。

IBM InfoSphere Information Server 日志的获取和分析

IBM InfoSphere Information Server 是一种数据集成软件平台，能够帮助企业从散布在各个系统中的复杂异构信息获得更多价值。InfoSphere Information Server 提供了一个统一的平台，使公司能够了解、清理、变换和交付值得信赖且上下文丰富的信息。我们在使用 IBM InfoSphere Information Server 的过程中可能会遇到一些问题，我们应当如何来查找和诊断问题，对于一个刚刚使用 IBM InfoSphere Information Server 的用户来说这也许是一个很棘手的事情。但是我们不必担心，因为 IBM InfoSphere Information Server 产品从安装、运行到卸载都为我们提供了大量的日志信息。通过本文我们可以了解如何获得 IBM InfoSphere Information Server 提供的日志信息，如何通过分析相应的日志来确定和解决遇到的问题。

回页首

IBM InfoSphere Information Server 产品的层介绍

IBM InfoSphere Information Server 产品模块以逻辑层的形式被安装。层由被安装的组件的逻辑组及安装这些组件的计算机组成。IBM InfoSphere Information Server 由四个层组成，即 Client、Engine、Services 和 Metadata repository，如图 1 所示。

Client 层由客户端程序，用户的开发和管理控制台及安装这些组件的计算机组成。Client 层计算机必须运行在 windows 系统上，其他层计算机能够运行在任何操作系统上；Engine 层由 Engine 组件的逻辑组及安装这些组件的计算机组成；Services 层由应用服务器、组件的公共服务、特定产品模块的服务及安装这些组件的计算机组成；Metadata repository 层由元数据存储数据库、信息分析数据库和安装这些数据库的计算机组成。这四层有机组合起来，构成完整的 Information Server 体系架构，提供信息分析、SOA 服务创建发布、作业执行、元数据和其他数据的存储、管理。

图⒈ 各层关系图

下面我们以 IBM InfoSphere Information Server8.5 版本为基础介绍 IBM InfoSphere Information Server 的日志获取和分析。

回页首

IBM InfoSphere Information Server 的安装和卸载日志

IBM InfoSphere Information Server 各层安装 / 卸载成功后会产生一个安装 / 卸载日志，这个文件的命名格式为 ISInstall-date-timestamp.log，保存在 <Information Server 安装目录 >/logs 路径下。如果安装 / 卸载过程失败，会在 < 临时目录 >/ibm_is_logs 下产生命名格式为 ISInstall-date-timestamp.log 的日志，临时目录下的日志将会记录错误发生的位置及原因，以帮助我们定位和解决问题。例如 Engine 层的安装日志就如图 2 所示。

图⒉ Engine 层的安装日志实例

回页首

IBM InfoSphere Information Server 强大的日志系统

IBM InfoSphere Information Server 自身提供了强大的日志系统。如果我们在运行 Information Server 相关产品的过程中遇到问题，我们可以使用各个组件的日志，去分析定位问题。例如，使用 Information Server 的 Web Console 查看所有 components 的日志，使用 DataStage and QualityStage Director 查看 job 运行日志。

通过 web 控制台查看所有 components 日志

通过 Web Console，我们可以在网络中任意一台装有浏览器的机器上去查看日志，非常方便。登录 http://Services_IP:9080/ibm/iis/console，输入用户名和密码后，进入 IBM InfoSphere Information Server 的 WEB 管理控制台（Services_IP 表示服务层的 IP 地址）。点击 Administration->Log Management->Logging Components，在这个页面我们可以对各个 component 的日志行为进行配置，如图 3 所示。选择一个 component 名称后点击 Manage Configuration，进入该 component 的管理配置页面，如图 4 所示。

图⒊ Logging Components 页面

图⒋ Component 的管理配置页面

在 Manage Configuration 页面中，我们可以新建该组件的其他日志配置文件，也可以对已有配置文件进行打开、复制、将配置文件设置为活动的、将日志配置文件设置为默认的或删除等操作。选中配置文件名称后点击 open 后，进入配置文件页面，如图 5 所示。在配置页面中我们可以对各事件分别设置日志记录的等级。

图⒌ Component 的 Manage Configuration 页面

点击 Administration->Log Management->Logging Views，在这个页面我们可以对所有 component 的项目日志进行打开、查看、删除和清洗等操作，如图 6 所示。选择一个项目名称后点击 View log，进入该项目的日志页面，如图 7 所示。我们可以对日志进行过滤、导出和清洗等操作。选中某条日志后，页面底部显示该条日志的完整内容。

图⒍ Components 的 Manage Configuration 页面

图⒎ 使用 WEB 控制台查看 compoent 的项目日志

通过 Director 查看 job 的运行日志

通过 DataStage and QualityStage Director 可以查看 DataStage and QualityStage Designer 中 job 的运行日志。在 Director 页面选中一个 job 名称，然后选择 view 菜单下的 Log 选项便可以查看 job 的运行日志，如图 8 所示。job 的运行日志如图 9 所示。

图⒏ 使用 DataStage and QualityStage Director 查看 Job 日志

图⒐ Job 运行日志

Job 运行日志包含 Occurred、On date、Type 和 Event 四个方面的信息。Occurred 表示事件发生的时间，时间左侧的图标是事件类型的图形化表示，绿色代表信息，黄色代表警告，红色代表致命错误。On date 表示 job 运行的日期。Type 表示事件的类型，分为：Info、Warning、Fatal、Control、Reject、 Reset。其中，Info 显示阶段的开始和结束时间。Warning 表示一个错误出现了，你可能需要调查警告原因，因为 job 有可能终止。Fatal 表示一个严重的错误，你需要调查错误原因。Event 使用一个消息来描述事件。Control 显示 job 开始和完成的时间。Reject 表示被丢弃的行的输出时间。Reset 表示 job 已经被重新设置了。双击某条消息后弹出详细事件窗口来显示完整消息，如图 10 所示。

图⒑ 完整的事件信息

回页首

IBM InfoSphere Information Server 各层的日志分析

除了查看 IBM InfoSphere Information Server 日志系统中的日志外，我们还可以通过对各层日志的分析，进一步定位解决问题。例如 service 层的应用服务器日志，元数据层的数据库日志等。

Client 层日志

在 Client 层可以产生多种日志，本文中我们主要介绍如何查看 DataStage and QualityStage Designer 日志及错误日志。

DataStage and QualityStage Designer 的日志

DataStage and QualityStage Designer 的各种操作都被记录到 C:\Document and Settings\username\ds_logs/dstage_wrapper_trace_<n>.log 文件中。主要包括登录、退出、job 的打开、保存、编译、导入和导出等操作。

dstage_wrapper_trace 日志实例：

 2010-09-19 10:53:20,046 INFO com.ibm.datastage.Auditor.log(Auditor.java:101) - [AUDIT BEGIN] Open job: name=DW00DN_SalesOrganization_15 2010-09-19 10:53:24,578 INFO com.ibm.datastage.Auditor.log(Auditor.java:101) - [AUDIT 00:04] OK

DataStage and QualityStage Designer 在运行过程中如果出现问题会产生一个 ds_errorreport_<data_time>.zip 形式的错误报告，错误报告的名称可以通过错误窗口获得，如图 11 所示。错误报告保存在 C:\Documents and Settings\USER\Application Data\IBM\InformationServer\DataStage Client\client tagID\ ErrorReports\<clientTagID> 路径下。clientTagID 可以从 <Information Server 安装目录 >\Version.xml 中获得。zip 文件由 Details.txt、DStage_wrapper_trace_<n>.log 和 Version.xml 三个文件组成。其中，Details.txt 记录了错误消息，异常类型、异常源和异常堆栈信息及加载的模块信息。DStage_wrapper_trace_<n>.log 是用户的日志信息。Version.xml 记录了版本及组件的详细信息。

图⒒ DataStage and QualityStage 的错误窗口

Services 层日志

在 Service 层我们主要介绍应用服务器日志和 Information Server 相关组件，例如 Information Analyzer，Business Glossary，Metadata Workbench 等在后台的日志。

Services 层的应用服务器可以使用 WebSphere Application Server、Weblogic 等。下面我们以 WebSphere Application Server 为例来分析应用服务器的日志。WebSphere Application Server 日志不但可以用来监视 WebSphere Application Server 的启动而且可以用来诊断 InfoSphere Information Server 产生的问题。一般在应用程序存在问题时，我们需要查看和分析 SystemOut.log、SystemErr.log、activity.log、Native_stderr.log 和 FFDC 事故记录等。

SytemOut.log 和 SystemErr.log 属于 JVM 日志。通常，SystemOut.log 日志用于监控应用程序服务器的运行是否正常，SystemErr.log 日志包含异常堆栈跟踪信息。默认情况下，这两个文件保存在 <WAS 安装目录 >/AppServer/profiles/InfoSphere/logs/server1 路径下。有两种方法可用于查看应用程序服务器的 JVM 日志。使用管理控制台，它支持从远程机器查看 JVM 日志；使用存储日志的机器上的文本编辑器，即使用文本编辑器打开指定路径下的 SystemOut.log 和 SystemErr.log 即可。下面详细介绍使用管理控制台设置和查看日志的步骤。

使用管理控制台查看 JVM日志

登录 http://Services_IP:9060/ibm/console 输入用户名和密码后，进入 WebSphere 管理控制台页面。点击故障诊断下的日志和跟踪选项后，点击右侧的服务器名称，然后选择 JVM 日志选项。JVM 日志的配置页面可以对日志文件进行各种设置，如图 12 所示。JVM 日志的运行时页面如图 13 所示。可以点击运行时页面的查看按钮来查看日志，如图 14 所示。

图⒓ JVM 日志的配置页面

图⒔ JVM 日志的运行时页面

图⒕ 管理控制台上的 JVM 日志文件

JVM 日志格式分析

掌握日志常用格式，可以帮助我们更好的查看日志。

SystemOut.log 实例分析：

 [11/1/10 19:09:22:875 GMT-05:00] 0000000a SASRas A JSAS0002I: Authentication
protocol: CSIV2/IBM

[11/1/10 19:09:22:875 GMT-05:00]：时间戳记。
0000000a：线程 ID, 从发出消息的线程的散列代码生成的 8 个字符的十六进制值。
SASRas：组件名称，发出消息或跟踪事件的记录组件的缩写名称。
JSAS0002I：消息 ID。
A：消息类型，消息类型是大写的。可能值包括：F：致命消息；E：错误消息；W：警告消息；I：参考消息；A：审计消息；C：配置消息；D：详细信息消息；O：通过用户应用程序或内部组件直接写入 SystemOut.log 的消息；R：通过用户应用程序或内部组件直接写入 SystemErr.log 的消息；Z：表明不可识别的类型的占位符。
Authentication protocol: CSIV2/IBM：消息内容。

IBM 服务日志

Activity.log 为 IBM 日志，应用程序服务器从各种 WebSphere Application Server 组件的活动创建服务或活动日志文件。Activity.log 是二进制文件，它位于 <WAS 安装目录 >/AppServer/profiles/InfoSphere/logs 路径下。在管理控制台下，点击故障诊断下的日志和跟踪选项后，点击右侧的服务器名称，选择 IBM 服务日志选项后进入配置页面，如图 15 所示。

图 ⒖ IBM 服务日志的配置页面

我们可以使用 showlog 命令将二进制日志输出到标准输出或文件。执行 <WAS 安装目录 >/bin/showlog activity.log 将日志输出到标准输出。

Activity.log 输出到标准输出后的实例：

 ComponentId: Application Server ProcessId: 2632 ThreadId: 00000017 ThreadName: server.startup : 5 SourceId: com.ibm.ws.webcontainer.webapp.WebGroup ClassName: MethodName: Manufacturer: IBM Product: WebSphere Version: Platform 6.0 [BASE 6.0.2.27 cf270815.03] ServerName: ips32Node01Cell\ips32Node01\server1 TimeStamp: 2010-11-01 19:10:07.719000000 UnitOfWork: Severity: 3 Category: AUDIT PrimaryMessage: SRVE0169I: Loading Web Module: ProductAppSOAPBinding_HTTPRouter. ExtendedMessage:

通过上面实例的第一列名称我们可以清楚的了解每项的含义，在此不再赘述。

Native_stderr 日志

Native_stderr.log 保存在 <WAS 安装目录 >/AppServer/profiles/InfoSphere/logs/server_name 路径下。这个日志主要记录当前应用服务器的 JVM 的 GC 状况。利用相关的 JVM 分析工具，如：GCMV (Garbage Collection and Memory Visualizer)，可以很轻松的确定当前 GC 的状况及 JVM 的内存有没有问题。

FFDC 事故记录

FFDC（第一次失败数据捕获）是一个内置在 WebSphere Application Server 运行时中的工具，该工具试图在发生可能的非正常情况时，自动捕获并保存关键信息。因为 WebSphere Application Server 遇到的许多问题都与某种 Jave 异常有关，所以 FFDC 将监视服务器操作过程中引发的所有异常。一旦引发一个异常，将对其进行实时检查，以确定它是否属于非预期的异常，或是否属于某个可能正在发生的问题的一部分。如果是，FFDC 将向文件中写入一条记录（FFDC 事故记录），其中包含堆栈跟踪、异常发生时的环境，以及对生成这一异常的服务器的组件状态所做的一个短转储（可选）。FFDC 事故记录保存在 <WAS 安装目录 >/AppServer/profiles/InfoSphere/logs/ffdc 路径下。我们可以对这些 FFDC 事故记录进行事后检查，以深入了解发生的情况。

Information Server 组件的后台日志

Information Analyzer 组件的日志保存在 <WAS 安装目录 >/AppServer/profiles/InfoSphere 路径下，包括 iasServer-servername.log 和 iasHandler-servername.log，iasServer 日志用来记录 Information Analyzer 的启动信息，iasHandler 日志用来记录 Information Analyzer 的运行信息。 Business Glossary 组件的日志包括 glossary-api-servername.log、 glossary-servername.log、 glossary-web-servername.log；Metadata Workbench 组件的日志包括 workbench.log、workben-aspect.log、workbench-web-activity.log；系统审计日志为 ISauditLog-x.log。它们都保存在 <WAS 安装目录 >/AppServer/profiles/InfoSphere/logs 路径下。

Metadata repository 层日志

Metadata repository 层的数据库系统可以使用 DB2、Oracle 和 SQL server，下面我们以 DB2 为例来介绍数据库系统的日志分析。DB2 日志可以用来诊断数据库产生的问题，默认情况下 DB2 日志被保存在 Linux 系统的 /home/<DBUser>/sqllib/db2dump/db2diag.log 中。对于 Windows 系统则需要手动设置日志路径，命令如下：

db2 update dbm cfg using DIAGPATH <path_name>；db2stop force；db2start。

db2diag.log 日志实例分析：

（1）2010-07-19-10.48.46.057331+330 E6831A910 （2） LEVEL: Error (OS)
（3）PID : 303804 （4）TID : 258 （5）PROC : db2sysc 0
（6）INSTANCE: db2inst1 （7）NODE : 000
（8）EDUID : 258 （9）EDUNAME: db2sysc 0
（10）FUNCTION: DB2 UDB, oper system services, sqloLoadModule, probe:140 CALLED : OS, -, dlopen OSERR : ENOEXEC (8) "Exec format error"MESSAGE : Attempt to load specified library augmented with object name failed.
（11）DATA #1 : Library name or path, 50 bytes /home/db2inst1/sqllib/lib64/libdb2iocp.a(shr_64.o) DATA #2 : String, 0 bytes Object not dumped: Address: 0x0683F0B0 Size: 0 Reason: Zero-length data DATA #3 : String, 5 bytes
………

（1）表示时间和时区；
（2）表示错误等级，分为 info、event、warning、error、severe；
（3）表示进程号；
（4）表示线程号；
（5）表示进程名称；
（6）表示实例名称；
（7）表示分区号，000 代表单分区；
（8）引擎可调度单元号；
（9）引擎可调度单元的名称；
（10）产品名称：DB2；组件名：oper System services；sqloLoadModule：写入消息的函数名；probe：函数内的探测点；
（11）被调用函数返回的信息，可能返回多个数据字段。

db2diag.log 是 DB2 中非常重要的诊断日志，一般出现问题后，首先就要查看 db2diag.log 文件。如果日志的数据量很大时，直接查看 db2diag.log 效率会非常低而且容易遗漏。从 DB2 版本 8.2 开始，DB2 提供了 db2diag 工具可以用来过滤查找特定的日志，下面简要介绍 db2diag -g 选项的基本使用方法。

-g: 搜索符合一系列列标志 = 列值条件的日志记录，多个条件用逗号分开，区分大小写。
-gi: 功能与 -g 相同，不区分大小写。实例： db2diag – gi NODE=001，LEVEL=SEVERE
-gv: 搜索不符合一系列列标志 = 列值条件的日志记录，多个条件用逗号分开，区分大小写。
-gvi: 功能等同于 -gv, 不区分大小写。实例： db2diag – gvi LEVEL=ERROR

Engine 层日志

Engine 层的日志文件 DSAuditTrace.log，它用来记录项目的详细信息，存放在 <Information Server 安装目录 >/Server/DSEngine 路径下。DSAuditTrace.log 文件首次被创建时会产生一个文件头，文件头后面记录项目的新建或删除信息，格式如下：

 LOG CREATED: 14:29:52 11 AUG 2010, user=mkops, from=C:\IBM\InformationServer\Server\DSEngine, version=8.5, platform=WINNT 2010-10-23 00:49:16(,0): Project creation started on server: name=dstageY,
path=C:\IBM\InformationServer\Server\Projects\dstageY Adding project to xmeta repository: name=dstageY, host=MK-LENG, locale=ENU 2010-10-23 01:07:03(,0):Project creation finished OK:name=dstageY, host=MK-LENG Project deletion from server started : name=dstageX Project deletion from server finished: name=dstageX,

Engine 层中还有一些日志可供我们参考，它们是位于 Linux 系统 <Information Server 安装目录 >/ASBNode/bin 下的 logging-agent-x.err、logging-agent-x.out、LoggingAgent.out 和 Agent.out 等；或位于 Windows 系统 <Information Server 安装目录 >\ASBNode 下的 Logging-agent.out、Logging-agent.err、Asbagent_startup.out 和 Asbagent_startup.err 等。

Logging-agen.out 和 Logging-agent.err 用来记录 Logging agent 的启动信息及启动时出错信息。Asbagent_startup.out 和 Asbagent_startup.err 用来记录 ASB agent 的启动过程及启动时出错信息。

Logging-agent.out日志实例如下 :

 2010-11-01 19:13:04,828 Info [ISF-LOGGING-AGENT] [0026] Logging agent log level set to "Info". 2010-11-01 19:13:04,843 Info [ISF-LOGGING-AGENT] [0034] Log helper log level set to "Off". 2010-11-01 19:13:04,843 Info [ISF-LOGGING-AGENT] [0027] Batch events set to "true". 2010-11-01 19:13:04,843 Info [ISF-LOGGING-AGENT] [0036] Number of events to batch set to "100". 2010-11-01 19:13:04,843 Info [ISF-LOGGING-AGENT] [0028] Length of time to wait before flushing batched events set to "1000". 2010-11-01 19:13:04,843 Info [ISF-LOGGING-AGENT] [0030] Cache configuration set to "true". 2010-11-01 19:13:04,843 Info [ISF-LOGGING-AGENT] [0031] Length of time to wait before refreshing cache set to "60000". 2010-11-01 19:13:04,843 Info [ISF-LOGGING-AGENT] [0029] Buffer events if LoggingService cannot be reached set to "true". 2010-11-01 19:13:04,843 Info [ISF-LOGGING-AGENT] [0037] Number of events to buffer set to "1000". 2010-11-01 19:13:04,843 Info [ISF-LOGGING-AGENT] [0038] Length of time to wait before trying to reconnect with the LoggingService set to "5000". 2010-11-01 19:13:04,843 Info [ISF-LOGGING-AGENT] [0035] The maximum number of events to queue set to "10000". 2010-11-01 19:13:04,875 Info [ISF-LOGGING-AGENT] [0025] LoggingAgent bound successfully "31533". 2010-11-01 19:13:07,812 Info [ISF-LOGGING-AGENT] [0020] Authenticated.

Asbagent_startup.out日志实例如下 :

 2010-11-01 19:13:14,484 Info [ISF-AGENT-APP] [0038] Initialization started. 2010-11-01 19:13:16,234 Info [ISF-AGENT-APP] [0037] Authenticated. 2010-11-01 19:14:33,281 Info [ISF-AGENT-APP] [0039] Initialization Complete. Listening for requests on port 31531. 2010-11-01 19:14:33,281 Info [ISF-AGENT-APP] [0040] Switching to the Logging Agent.

回页首

结束语

综上所述，除了使用 IBM InfoSphere Information Server 日志系统进行问题诊断分析外，也可以尝试从各层应用系统的自身日志中获取所需信息。无论是 IBM InfoSphere Information Server 的日志系统，还是各层应用系统的日志，都可以设置相关的参数定制输出日志的详细程度。虽然越详细的日志里包含的信息越丰富，但海量的日志也会提高分析的难度。所以，针对不同的问题，我们需要查看不同的日志，并且定制合适的日志输出级别，这样才能快速的定位、解决问题。

摘自：http://www.ibm.com/developerworks/cn/data/library/techarticle/dm-1102lengc/index.html