郑爽上过的真人秀:使用ITCAM for WAS 对Websphere 进行监控管理和问题诊断

来源:百度文库 编辑:九乡新闻网 时间:2024/10/06 06:03:48

ITCAM forWebSphere® 是 IBM® 提供的针对 WebSphere 的一种全面的性能和可用性解决方案,可为企业WebSphere应用程序提供有效的应用管理,同时 ITCAM for WebSphere 是一个集成的应用诊断工具,它包括对 WebSphere 应用服务器的堆分析和内存泄漏的检测,帮助管理员在生产系统中解决那些在测试过程中难以重现的问题。

一、引言
当前,基于 J2EE(Java®2 Enterprise Edition)平台开发的应用越来越多,网上银行、电子商务等等已经成为了不可或缺的业务形式,而随着 J2EE 成为应用开发的主流,支撑它的关键技术部件——中间件也越来越丰富和复杂,这给中间件和应用的管理提出了更高的要求和难度。如何管理好这些中间件以及在这基础上搭建的复合应用(CompositeApplicationManagement)是一个复杂且又非常重要的事情。
ITCAM(IBM Tivoli Composite Application Management)® 是对复合应用的管理,即管理在复杂、异构环境中运行的复合应用,这些应用是复合性的,也就是说它们是作为分区业务逻辑和数据进行部署,跨越 Web 服务器、J2EE 应用服务器、集成中间件以及大型机系统,其中包括 CICS® 和 IMS。用于监控单个资源的传统工具和方法一般不能解决复合应用的性能与可用性问题。因此,系统管理员和开发人员要花费大量时间识别、隔离和解决这些问题。本文就以 Websphere 的管理为例,阐述如何使用 IBM Tivoli® 的复合应用管理软件ITCAM for WebSphere(IBM Tivoli Composite Application Manager for WebSphere)对 WebSphere 进行管理、维护以及应用问题的分析、诊断。

图 1.1 典型的复合应用的技术架构

一般来讲,对于 WebSphere 的管理分为三个层面:
1、对 Websphere 的资源和可用性进行管理
在这个层面,管理员需要对 WebSphere 的资源信息,例如 WebSphere 中 JVM 的 CPU、内存、jdbc 连接池、线程池、EJB 调用情况、GC 的情况、Session 的连接情况等做实时的信息监控,并且将这些数据收集起来,作为长期的性能趋势或者容量分析使用。

2、对 WebSphere 用户请求信息的监控
对于用户的请求信息,如 Request 需要进行实时的监控,对于关键的请求信息以及那些持续占用系统资源比较高的请求要进行告警处理。例如在一个网银系统中,详单信息的查询是非常重要的,可以设置对查询请求的 Request 进行监控来实时检查这项关键请求是否运作良好。另外,通过历史信息的收集和分析,可以分析出哪些请求在哪些时间段是频繁的,哪些业务是用户最多关心和访问的,以帮助优化业务过程,提高服务质量。

3、对应用问题的深度诊断和分析
在实际的应用开发中,由于对 J2EE 组件使用不当,或者是代码编写的不规范,开发出来的应用可能会出现一些很难发现且难以解决的问题,比如线程死锁、内存泄漏、内存溢出等。这些问题几乎让每位 WebSphere 管理员头疼,多数情况下这种问题难于在测试中发现,也很难诊断,通常的做法都是在 WebSphere 宕机后做 Heapdump,然后分析 dump 出来的数据,过程复杂、繁琐,而且需要比较深的 J2EE 的知识和耐心。
ITCAM for WebSphere 能够帮助 WebSphere 的管理员解决上述三个层面上的管理问题,不仅能够做日常的运维管理,而且能对内存泄漏进行分析、诊断,发现造成内存泄漏的 java 的类和方法。

二、ITCAM for WebSphere 的技术架构和介绍
ITCAM for WebSphere 是一种全面的性能和可用性解决方案,提供应用服务器和 J2EE 应用的多方面的监控,可为企业 J2EE应用程序提供有效的应用管理,同时 ITCAM for WebSphere 是一个集成的 J2EE 应用诊断工具,使用 ITCAM for WebSphere 可以替代一大堆零散的 J2EE 开发诊断工具,它包括对 J2EE 应用服务器的堆分析和内存泄漏的检测,帮助管理员在生产系统中解决那些在测试过程中难以重现的问题。

图 2.1 ITCAM for WebSphere 的技术架构

ITCAM for WebSphere 主要包含以下组件:

1、管理服务器——ITCAM for WebSphere ManagingServer(以下简称 MS)
MS 其实本身是一种在 IBM WebSphere Application Server 中运行的 J2EE 应用程序。MS 是控制管理的中心,它收集、处理来自各个数据收集器(DC)的数据,进行数据的分析、关联,并通过这个管理中心向各个 DC 发送管理指令,对被管 WebSphere 进行控制,例如撤销请求、调整线程的优先级等。

图 2.2 一个 MS 管理多个 DC

MS 由一个 WebSphere Server、一个 J2EE 应用和一个关系数据库组成。

2、数据收集器——Data collector(以下简称 DC)
DC 在每个受管理的 WebSphere Application Server 上安装、配置、运行,并与 ITCAM for WebSphere 管理服务器进行数据通信,将收集到的数据传送到 MS。 DC 在配置过程中需要针对每个 WebSphere 的实例进行配置,DC 修改了这个 WebSphere 实例的 JVM 启动参数,并且增加了一些 WebSphere 的环境变量。

3、TEMA——Tivoli Enterprise Monitoring Agent
TEMA 是 IBM Tivoli Monitoring 6 产品中的一个组件,TEMA 一方面收集 WebSphere Application Server 的某些配置和日志数据,另一方面 TEMA 作为数据转换接口,它接收来自 DC 收集到的数据并进行相应的转换处理,然后将数据传送给 TEMS。

4、TEMS——Tivoli Enterprise Monitoring Server
TEMS 是 IBM Tivoli Monitoring 6 产品中的核心组件,TEMS 为 Tivoli 企业服务器和各种代理程序提供了框架和数据库操作。代理程序将数据传递给 TEMS,然后通过 TEPS 服务器请求该数据。

5、TEP——Tivoli EnterprisePortal
TEP 是 IBM Tivoli Monitoring 6 产品中的数据管理和显示组件,是一个统一的用户界面。它提供了显示和处理各种 TEMA 所收集的数据的视图。在 TEP 中,可以定义“执行操作”控制被管理的服务器或者设置情境和阀值等进行报警处理。

TEP 有两种形式:客户机和浏览器。

图 2.3 通过 TEP 进行 WebSphere 管理的界面


前面提到对于 WebSphere 管理的三个层面:1、对 WebSphere 的资源和可用性进行管理,2、对 WebSphere 用户请求信息的监控,3、对应用问题的深度诊断和分析。在这里我们使用 DC 通过 TEMA 向 TEMS 传送数据并通过 TEP 进行管理的方式来对 WebSphere 进行第 1、2 层面上的管理;而对第 3 层面的管理我们使用 ITCAM for WebSphere 独有的管理平台 MS 进行问题的分析和诊断。

图 2.4 对 WebSphere 进行第 1、2 层面的管理架构


图 2.5 对 WebSphere 进行第 3 层面的管理架构

三、 ITCAM for WebSphere 的安装和配置
在安装 ITCAM for WebSphere 之前要安装以下组件:

  • 安装 DB2 用来存储数据
  • 安装 WebSphere Server 作为发布 ITCAM for WebSphere MS 管理应用的中间件
  • 安装 IBM Tivoli Monitoring 6 的 Server 来管理 ITCAM for WebSphere 的 TEMA
  • 如果在 Windows 平台安装 ITCAM for WebSphere,还需要在此 Windows 上安装 SFU(Services for UNIX)作为模拟 Unix 命令的环境


因为这里重点介绍的是 ITCAM for WebSphere,所以上述这些软件的安装过程就不再描述,读者可以通过 Redbook 来查看详细的安装步骤。

下面开始安装 ITCAM for WebSphere

1、安装 ITCAM for WebSphere 的 MS
在安装文件目录运行 setup_MS.exe 进入安装界面,连续点击“下一步”,选择安装路径,接着在“数据库选项”选择“现有 DB2”,并输入“数据库实例用户”和“数据库模式用户”的用户名及密码

图 3.1 安装 ITCAM for WebSphere 的 MS


继续“下一步”,选择要部署 ITCAM for WebSphere 管理应用程序的 WebSphere Server,即 ITCAM for WebSphere 的管理应用程序会部署在这个 WebSphere Server 上,接着输入这个 WebSphere 实例的 Soap 连接信息

图 3.2 安装 ITCAM for WebSphere 的 MS


接着选择要部署的 WebSphere 实例,然后连续点击“下一步”,完成安装。
ITCAM for WebSphere 的 MS 安装完毕后在 MS 管理控制台输入用户名和密码登陆管理界面进行安装确认。

图 3.3 安装 ITCAM for WebSphere 的 MS


在系统菜单启动“am-start.sh”,这个 shell 作为后台接口服务运行,它是连接 DC 和 MS 之间的作为数据通信的接口。

图 3.4 安装 ITCAM for WebSphere 的 MS


2、安装 ITCAM for WebSphere 的 TEMA
在安装目录运行 setup.exe,然后选中所有的“复选框”,因为 TEMS、TEPS、TEP 都在本机,所以这里我们将安装所有对的 ITCAM for WebSphere TEMA 的 support,当然还有 ITCAM for WebSphere TEMA

图 3.5 安装 ITCAM for WebSphere 的 TEMA


继续“下一步”,选择默认配置,接下来配置 TEMA 与 TEMS 的连接,这里默认选项不做修改

图 3.6 安装 ITCAM for WebSphere 的 TEMA


然后配置 ITCAM for WebSphere TEMA 的参数,可以配置“请求数据监控的级别”、“数据收集间隔”等,同时可以调整数据采样率(注意:采样率越高对 WebSphere 的资源消耗就越多)

图 3.7 安装 ITCAM for WebSphere 的 TEMA
 

图 3.8 安装 ITCAM for WebSphere 的 TEMA


3、安装 ITCAM for WebSphere 的 DC
在安装目录运行 setup_DC_w32.exe,选择“下一步”,输入安装路径,选择“在此计算机上安装数据收集器”,点击“下一步”

图 3.9 安装 ITCAM for WebSphere 的 DC


选择“将配置延迟到以后”,稍后我们再进行 DC 的“配置”

图 3.10 安装 ITCAM for WebSphere 的 DC


4、配置 ITCAM for WebSphere 的 DC 与 MS 和 TEMA 连接
在进行 DC 的配置之前,新建一个 WebSphere 的实例,并且部署 WebSphere 的样例程序,接下来 DC 的配置就针对这个新建实例以及监控这个实例上的 WebSphere 样例应用。新建 WebSphere 实例的过程请参考 WebSphere 的 redbook,这里不再描述,但是务必记住在新建实例过程中的 soap 端口号。

图 3.11 新建 WebSphere 实例的 soap 端口号


下面开始进行 DC 的配置,将 DC 连接到 MS 和 TEMA
在“开始”菜单选择“DC Configuration”

图 3.12 配置 ITCAM for WebSphere 的 DC 与 MS 和 TEMA 连接


选择“配置用于数据收集的服务器”,然后将 2 个复选框都选中,因为这里 DC 既要和 TEMA 连接,又要和 ITCAM 的 MS 连接

图 3.13 配置 ITCAM for WebSphere 的 DC 与 MS 和 TEMA 连接


输入“管理服务器标准主机名”,端口保持为“9122”

图 3.14 配置 ITCAM for WebSphere 的 DC 与 MS 和 TEMA 连接


点击“下一步”,输入和“TEMA”连接的信息:主机名和端口(端口就是之前建立的 63335 侦听端口)

图 3.15 配置 ITCAM for WebSphere 的 DC 与 MS 和 TEMA 连接


选择要监控的服务器类型——WebSphere Application Server,这里 ITCAM for WebSphere 可以监控以下 WebSphere 服务器类型:
  • WebSphere Application Server
  • WebSphere Process Server
  • WebSphere ESB Server
  • WebSphere Portal Server
  • Workplace Server

选择刚才新建的 WebSphere Server,对此 Server 进行监控,选择“下一步”确认并修改 WebSphere 的配置项,这里保持默认值图 3.16 配置 ITCAM for WebSphere 的 DC 与 MS 和 TEMA 连接


配置与 WebSphere 的 Soap 连接

图 3.17 配置 ITCAM for WebSphere 的 DC 与 MS 和 TEMA 连接


接着选择要配置的 WebSphere 实例,最后点击“完成”,DC 配置结束,然后重启 WebSphere
配置完成后,打开 TEP 查看,我们看到已经有 WebSphere 的监控信息显示

图 3.18 配置 ITCAM for WebSphere 的 DC 与 MS 和 TEMA 连接


接着在 MS 上将刚才配置的 DC 纳入 MS 的管理区域。打开 MS 管理控制台,选择菜单“管理”——“Server Management”——“Data Collector Configuration”,在“Unconfiguration Data Collectiors”选中刚才配置的 DC,点击“Apply”

图 3.19 配置 ITCAM for WebSphere 的 DC 与 MS 和 TEMA 连接


我们发现在“Configuration Data Collectors”中已经将此 DC 纳入到 MS 的管理区域

图 3.20 配置 ITCAM for WebSphere 的 DC 与 MS 和 TEMA 连接


选择“可用性”——“Systems Overviews”——“Server”,可以看到从 DC 收集到的数据已经可以显示了

图 3.21 配置 ITCAM for WebSphere 的 DC 与 MS 和 TEMA 连接


四、 用 ITCAM for WebSphere 的 TEMA 和 TEP 对 WebSphere 进行监控管理
前面说过 WebShpere 管理的三个层面,这里我们用 ITCAM for WebSphere 的 TEMA 和 TEP 的方式来对 WebSphere 进行资源、可用性的管理和用户请求信息的管理维护。
登陆 TEP 管理控制台,可以看到在安装了 ITCAM for WebSphere 的 TEMA 后,已经自动生成了大量的“属性组”,每个属性组由多个“工作空间”组成,而每个工作空间就如下图所示表达各种监控信息和数据,例如从下图中可以查看此 WebShpere 的“总体响应时间”、“总体请求频率”、“CPU 使用率”以及 WebSphere Server 当前的信息。

图 4.1 用 ITCAM for WebSphere 的 TEMA 和 TEP 对 WebSphere 进行监控管理


我们可以用此管理控制台做很多管理操作,这里仅用下面的例子来说明管理员如何通过 TEP 对 WebSphere 进行维护管理:
  • 监控活动的应用(Application)
  • GC(garbage collection)监控
  • 用户 Request 监控
1、监控活动的应用(Application)
在平常的运维管理中,WebSphere 的管理员要维护大量的 App 应用,有时 App 应用会因为异常错误或者人为原因而 down 掉,这时候如果能对应用进行监控,那么对管理员将非常方便。
ITCAM for WebSphere 的 TEMA 内置了对应用的监控,可以通过属性组“Application Health”来对 WebSphere 上的全部应用进行管理、监控。

图 4.2 监控活动的应用


这里我们手工从 WebSphere 管理控制台停掉某个应用,如“PlantsByWebSphere”,可以立刻在 TEP 看到此应用显示红色状态,告知此应用的状态为“Stopped”图 4.3 监控活动的应用——在 WebSphere 控制台停止应用



图 4.4 监控活动的应用


而且,在 TEP 我们还可以通过定义情境(Situation)设置阀值进行告警,告警可以通过短信、邮件方式告诉管理员。
如下图,鼠标右键点击“Application Health”,然后选择“Properties”

图 4.5 监控活动的应用


新建一个 Situation,并给这个情景起名“Application_stop”

图 4.6 监控活动的应用


选择“OK”,后在弹出的对话框中选择需要进行设定的“属性组”和“属性项”

图 4.7 监控活动的应用


选择“ok”,然后设置上面两个属性组的条件表达式,这里选择“Scan for string within a string”,意思是检查这个字段是否包含指定的字符串。

图 4.8 监控活动的应用


输入要监控的特定应用名称如“PlantsByWebSphere”,另一字段选择应用状态为“Stopped”,然后选择“OK”

图 4.9 监控活动的应用


刷新 TEP 当前视图,可以看到一个报警产生了,这就是刚才通过阀值定义的报警。

图 4.10 监控活动的应用


2、GC(garbage collection)监控
GC 是 JVM 的关键过程,GC 的一些信息直接反映了 WebSphere 的运转是否正常,例如 GC 后使用的堆大小,还有多少堆能用等等,下面来看看对 GC 的监控。
在 TEP 开始监控 GC 前,需要先对历史数据的收集进行调整。点击下面的图标“历史信息配置”

图 4.11 GC 监控


配置和 GC 相关的历史数据的收集:选中需要收集的项,然后选择“Configure Groups”,接着选择“Start Collection”。

图 4.12 GC 监控


等待几分钟后,GC 的数据开始被收集。GC 的监控如下图所示

图 4.13 GC 监控


接着可以对 GC 设置监控阀值,按照上一节过程在“工作空间”最下方鼠标右键选择“属性”,打开阀值设定界面,设定“Kbytes Used”大于 1000000K 并且小于 256000K 时报 Critical 的错误。注意字段横向表示与(and)的关系,纵向表示或(or)的关系。

图 4.14 GC 监控


通过上面的设置,当 GC 后使用的内存超过大约 1G,并且 free 的内存只有 256M 左右时,系统就进行报警。
3、用户 Request 监控
对用户请求的监控不仅可以分析最近一段时间内响应速度来体现服务水平,另一方面可以监视我们非常关注的关键请求的响应速度,并且能发现响应时间非常慢的请求,然后对此请求进行优化和调整。图 4.15 用户 Request 监控


这里我们对用户请求的“平均响应时间”作监控,创建一个新的 situation,选择属性组“Request Analysis”,选择属性“Avarage Response”

图 4.16 用户 Request 监控


设定响应时间超过 1 秒就报警(这里因为是做测试,所以时间调低能快速看到效果)

图 4.17 用户 Request 监控


由于上面设置的时间比较短,可以看到这个 situation 已满足条件,产生了报警

图 4.18 用户 Request 监控


用同样的方法可以设定某个关键请求的阀值进行监控,例如“登陆请求”

图 4.19 用户 Request 监控


以上我们通过一些实例演示了 ITCAM for WebShpere 通过 TEP 对 WebShpere 进行运维管理的过程,其实还有非常多的功能可以使用,这里就不再描述,读者可以自己进行更深入、更多地探索。

五、用 ITCAM for WebShpere 的 MS 对 WebSphere 进行应用问题的深度分析和诊断
在 WebSphere 的管理和维护中会遇到一些比较棘手的问题,而内存泄漏或者内存溢出则是这些问题中比较多见且很难处理的问题之一。ITCAM for WebSphere MS 的管理平台提供了一套方法和工具来对这类问题进行分析和诊断,这些内容包括方法论都被内置到 ITCAM for WebSphere MS 的管理菜单中,使用起来非常方便。
在用 ITCAM for WebShpere 对 WebSphere 进行内存泄漏分析前,先要调整 DC 上的一些参数和配置文件,将监控级别调整到 Level 3,这些调整是为了提高对 WebSphere 的监控深度,可以深入看到 java 的代码,将内存泄漏问题定位到某些类甚至某些方法。

在安装部署 DC 所在的 WebSphere 服务器上,找到 toolkit_custom.properties 文件(一般在 **\DC\runtime\**Node**.server**\custom 目录下),修改文件,将“#”号去掉,修改成下图所示,然后重启 DC。

图 5.1 内存泄漏分析


打开 ITCAM for WebShpere MS 的管理控制台,将要进行内存泄漏分析的 DC 调整监控级别到 L3。打开菜单“管理”——“Monitoring On Demand”,选择监控级别为“(L3)Tracing Mode”,然后选择“OK”确认。

图 5.2 内存泄漏分析


接下来,我们看看如何使用 ITCAM for WebShpere 进行应用内存泄漏的分析。

先简单介绍一下用 ITCAM for WebShpere 进行内存泄漏分析的过程和原理,一共有三个步骤:
  • 首先分析应用是否有内存泄漏的可能性(可以在监控级别 Level 1 下):一般情况下,当用户 session 或者用户请求数在一定时期内保持不变或者减少,而 GC 后 JVM 的 Heapsize 的使用却越来越多,那么,这时候就要怀疑应用是否存在内存泄漏,可以经过几天的观察,从收集的历史信息分析,如果 HeapSize 的使用不管是业务繁忙还是空闲一直是呈上升趋势,那么就可以初步断定有内存泄漏。
  • 建立 2 个以上的 Heap 快照(监控级别设定为 Level 3):可以在业务压力有代表性的时间段收集 Heap 快照,比如在业务繁忙时段建立几个(一般是早上 9 点到 12 点,或者下午 2 点到 6 点),在业务空闲时段建立几个(中午 12 点到 2 点,或者晚上或者凌晨——建立 Heap 快照的收集是自动的)。
  • 分析上面建立的 Heap 快照,找到造成内存泄漏的可疑 java 对象(Level 3 下):通过 Heap 对象的对比,发现哪些对象增长的速度非常快,哪些对象使用的内存很多,哪些对象在 GC 后数量不仅没有明显减少,反而不断地增长。通过这些分析就可以基本确定内存泄漏的对象,根据这些对象就可以看到对应的 java 类和方法。

下面开始进行内存分析

1、分析应用是否有内存泄漏的可能性:
在菜单选择“问题确定”——“Memory Diagnosis”——“Memory Leak”

图 5.3 内存泄漏分析


分析一段时间的“请求数”和“GC 后平均 Heap Size”,发现在用户“请求数”降低的情况下,“GC 后 Heap Size”却在不断地增长,说明 GC 后一些 Java 对象没有释放,继续持有 Heap 的资源,通过上述分析得出应用可能存在内存泄漏。

图 5.4 内存泄漏分析


2、建立 2 个以上的 Heap 快照
继续深入分析 Java 对象,建立几个 Heap 快照进行分析对比。

图 5.5 内存泄漏分析


3、分析上面建立的 Heap 快照,找到造成内存泄漏的可疑 java 对象
分析对比这些 Heap 对象,发现开源组件 hibernate 的实例数很多,增长的速度非常快,其中“org/hibernate/hql/***”生成的对象尤其多,所以怀疑可能是 Hibernate 使用不当。

图 5.6 内存泄漏分析


另一组 Heap 对比发现 Hibernate 总的 Size 也很大

图 5.7 内存泄漏分析


根据上述分析,询问了应用开发人员,确定在应用中大量使用了 Hibernate 作为 ORM 映射,这是 Hibernate 的开发机制,它将表转换成 java 对象以方便 java 开发人员用 java 的方式来操纵表,但在实际的使用中,如果用法不当会造成应用潜在的异常,例如一个查询后返回值如果是一个非常大的数据结果集,那么这个结果集进行 java 对象转换后肯定会占用大量 java 的内存资源,如果没有及时释放并且更多这样的 java 对象产生,很可能会造成内存泄漏发生。
按照上述过程,我们完成了对 java 内存泄漏的分析,这是在 WebSphere 没有宕机的情况下完成的。实际环境下,如果因为应用内存泄漏或者内存溢出使得 WebSphere 宕掉,也可以结合使用 ITCAM for WebShpere 内置的 MDD4J(Memory Dump Diagnostic for Java)这个工具分析 dump 出来的数据,详细的用法读者可以查阅相关资料,这里不再描述。

六、 总结

本文通过一些实例说明如何用 ITCAM for WebShpere 对 WebSphere 的三个管理层面做监控管理和分析,其中列举了 WebSphere 管理员最关心的性能问题的监控和对内存泄漏问题的诊断。ITCAM for WebShpere 是一个非常强大的 WebSphere 管理工具,它的另一组件——ITCAM for J2EE 能够对 Weblogic、JBoss、Oracle App Server、Tomcat 等其它中间件进行深入的监控分析,形成对中间件和复合应用的完整监控。