IT运维管理解决方案V1.0(共40页)

1、系统运维管理整体解决方案系统运维管理整体解决方案目目 录录第一章第一章项目概述项目概述 .4第二章第二章监控技术方案监控技术方案 .51系统总体框架设计.51.1设计原则.51.1.1管理系统自动化.51.1.2管理系统化.51.1.3管理系统实时性.61.1.4管理系统简单直观性.61.1.5管理系统对资源的占用.61.1.6管理体系的开放性.61.1.7管理系统的安全性.61.1.8管理系统的扩展性.71.2方案概述.71.2.1总体结构.ITM 架构.TPC 架构.ITCAM 架构.Netcool 网络及事件管理平台 .

2、报表系统架构.111.2.2架构分析.122项目实施技术方案.122.1监控功能.122.1.1与事件管理平台整合.122.1.2用 ITM 实现对操作系统的监控 .磁盘监控：.文件监控：.网卡.NFS 统计.RPC 统计 .进程.CPU.系统属性.用户属性.162.1.3用 ITM 实现 Windows 平台的监控.162.1.4用 ITCAM For database 实现对 Oracle、SQL 等数据库监控.

3、ITCAM 实现 Oracle 数据库监控 .ITM 实现 SQL Server 数据库监控.212.1.5用 ITCAM 实现对 WebSphere、Tuxedo 的监控.222.1.6用 TPC 实现对存储的监控.242.1.7事件管理实施.252.1.8报表管理实施.报表展现.262.1.9数据采集频率.272.1.10报警处理.2报警分级.2报警方式.282.2分布式支持.282.3系统安全性.292.4扩展接口.292.4.1与 Tivoli 其他产品的接口.292.4.2二次开发的接口.292

4、.4.3通用代理（Universal Agent） .292.5性能分析.302.6方案总结.312.7本方案的优势.31第三章第三章IT 运维流程管理方案运维流程管理方案.324.1需求分析.324.2流程设计.334.3 Tivoli Service Request Manager的流程实现.334.3.1Tivoli Service Request Manager 支持的管理流程 .334.3.2 管理对象分类和管理条目定义 .334.3.3 服务申请 .344.3.4 突发事件管理 .354.3.5 问题管理 .364.3.6 变更管理 .374.3.7 配置管理 .384.3.8 服

5、务水平管理 .384.4 Tivoli Service Request Manager的技术实现.394.4.1 Tivoli Service Request Manager 体系架构 .39第一章第一章项目概述项目概述客户 IT 环境复杂,IT 资源类型众多,维护难度高,亟需建立一个集中的运维监控体系。以达到 IT 资源的集中管理、综合分析，提高工作效率和运维质量的目标。项目建设的整体目标为：项目建设的整体目标为：整体规划、分布实施、重点突破，务求实效，作为整个系统与网络监控平台建设的知道思想；采用成熟的技术，配置要平衡；具有良好的稳定性、高效性、安全性、灵活性；具有良好的开放性，有较好的兼

6、容能力；具有较强的扩充能力；需要能保护现有投资。总体需求分析总体需求分析包括：包括：监控：主机、存储、网络、应用（数据库、中间件），故障告警、性能分析、自动发现2.服务流程：服务台、事件管理、故障管理、变更管理、发布管理、配置管理、知识库3.多维度展现：4.报表：第二章第二章监控技术方案监控技术方案1 1系统总体框架设计系统总体框架设计1.11.1设计原则设计原则客户信息系统的管理必须采用有效的方法，在客户信息系统整个范围内实施管理策略和流程。客户信息系统的管理体系侧重在如何提供一个适合客户信息系统的低风险的 IT 管理模式，设计、建构、实施一个统一、集成并可扩展的管理结构，实现对复杂的计算机

7、系统有效的管理。客户信息系统面对的是复杂的管理对象和多种管理需求。如果没有一套统一、集成的管理系统，在网络、系统和服务发生变化时，或者管理任务发生变化时，将可能导致管理体系大的调整，管理员可能需要花费很长时间和精力重新学习新的管理技能，从而导致管理效率的下降。最终将导致管理工作实施的周期加长，管理错误增多。统一和集成的管理将帮助最好的利用管理员的技能和精力，对客户系统进行高效、准确的管理。根据客户信息系统平台建设需求和我们的经验，在设计信息监控平台时应满足以下原则：.1管理管理系统自动化系统自动化对于客户信息系统而言，建构在管理平台上的，统一、集成的管理模式可以降低管理系统维护

8、的费用和风险，主要体现在：能够识别出管理复杂系统存在的困难和长远发展的问题，从而得到避免，防止用户重复投资减少对将各种单点管理工具勉强组合在一起工作，以满足管理工作的需要避免重复的管理工作，减少管理功能上的重复管理平台可以实现各管理应用间的通信，以更好的解决问题自动化管理减少管理员维护工作量，可以在统一平台上完成自动管理和监控，从而提高管理效率。.2管理系统化管理系统化该平台要对客户信息系统进行综合管理。系统的构成层次从下至上为：物理网络层、系统层、数据库层及应用层，只有做到对所有资源的统一管理，才能全面的管理好系统资源。任何管理上的遗漏，都将成为系统故障出现的隐患。同时在单一

9、管理环境下，实现对所有 IT 资产的集中化管理,并且对所有的平台都有统一的操作界面及管理, 简化操作。全面的管理，提高客户信息系统的整体可用性。减少系统管理人员对问题的定位时间。.3管理系统实时性管理系统实时性IT 系统管理平台的监控对象是重要的 IT 资源，这些 IT 资源承载着多个关键的业务系统，对于监控系统来说，要在系统发生问题时实时的捕捉，确保信息的实时、完整。.4管理系统简单直观性管理系统简单直观性系统应采用直观监控界面，并采用直观、清晰的展现形式；同时系统还应具有操作简便、使用方便的功能。.5管理系统对资源的占用管理系统对资源的占用在

10、实现管理的同时，必然会占用一定的网络系统资源，如何尽量减少资源的占用，是实现有效的管理系统的重要因素。因此在 IT 系统平台的选择上，需要管理平台对资源的占用最少，尽量采用单一代理，轻客户端程序，以减少对系统资源的占用。同时管理平台需要具有分布式结构，以减少管理对网络资源的占用。.6管理体系的开放性管理体系的开放性管理系统的开放性，是设计客户监控系统的一个原则。管理系统需要符合业界标准，以实现对各种资源的统一管理和与其它管理软件的集成。同时管理系统需要开放开发接口，以方便客户扩展管理功能。该系统管理需要基于开放的管理平台，遵循业界标准，并提供管理接口：网络管理基于 SNMP 标

11、准网管协议系统管理平台基于面向对象标准：Object Management Group(OMG)：Object Request Broker ArchTECture (CORBA)支持第三方厂商的应用集成，为系统管理的选型提供更高的灵活性开放的 API 支持用户应用软件的集成，为系统管理的内容扩充提供发展余地.7管理系统的安全性管理系统的安全性管理系统自身的安全性是保证管理工作正常进行的关键因素，因此在设计监控系统时，充分考虑了管理系统的安全性，包括：提供管理工作的安全审计控制和日志记录提供方便维护的安全通信结构，如信息的加密提供完整的策略和框架，并能适应组织的变化，灵活地设定

12、管理人员的角色及权限客户系统监控需要管理平台具有优秀的体系安全管理，以保证管理的安全。.8管理系统的扩展性管理系统的扩展性该监控系统平台规模会随着网络、系统、应用的扩展而扩展，因此选择的信息运维平台的扩展性对保护投资有重要意义。扩展性主要体现在：管理功能的扩展管理范围的扩展客户监控系统平台体系建立在企业级管理平台基础之上，具有优秀的扩展性，用户可以在需要时增加管理模块，扩展管理节点，保护现有网络系统以及应用管理投资。1.21.2方案概述方案概述.1总体结构总体结构IBM Tivoli 管理总体架构如下：最底层为管理对象层，包括数据中心内部的各种被管理对象。中间为

13、采集层，负责管理数据的采集，一般采用专用的协议和技术。在上层为数据处理层，主要为集中的告警信息、集中的性能数据和集中的配置信息管理最上层为集中展现层，展现数据中心的实时和历史运行状况，通过个性化的界面提供给不同层面的管理人员。服务流程层则负责管理运行流程的建立、运行和落地实现。在数据采集层，分别采用不同的技术来管理不同的 IT 资源：管理对象采用技术IBM 产品服务器和操作系统CORBA 和运行日志文件Tivoli Monitoring存储SNIA 协议和 syslogTivoli Productivity Center数据库、中间件产品自身接口或者标准协议ITCAM 产品家族网络Syslog

14、、SNMPOmnibus下面就每个产品的具体实现进行说明：ITM 架构架构Tivoli Monitoring v6 基于 CORBA 版本 v2.5 实现。Tivoli Monitoring v6 主要逻辑部件：管理服务器 Tivoli Enterprise Monitoring Server 管理网关 Hub Tivoli Enterprise Monitoring Server管理代理 Tivoli Enterprise Monitoring Agent展示门户 Tivoli Enterprise Portal Server数据历史保存 Tivoli Data

15、Warehouse对于分布式环境，可以通过 Remote TEMS 来实现高度的扩展性ITM6.1 与其他各 tivoli 产品的关系图如下：由上图可以看出，ITCAM 产品可以作为一个 agent 直接和 TEMS 联系。TPC 架构架构TPC 为客户提供完整的存储基础架构-包括磁盘，数据和光纤网络-提供了一套管理，配置及分析工具。下图举例描述了一些可管理的组件。 通用代理程序为应用程序特定代理提供了一个平台。 根据子代理所使用的任务，通用代理将被选择安装至应用服务器，桌面 PC 机，或笔记本上。ITCAM 架构架构Tivoli Com

16、posit Application Manager 基于 Tivoli Monitoring 的底层实现技术，实现对数据库、J2EE服务器、应用服务器等的中间件和应用的监控。Netcool 网络及事件管理平台网络及事件管理平台 Netcool/OMNIbus 提供了业务最为强大的事件处理能力使 IT 管理人员更高效地进行原始数据的访问、处理和显示。通过增加智能化来提高事件分析功能，该功能具备先进的程序语言和数据触发器，从而允许进行批处理和更复杂的数据处理操作，这为先进的商业服务管理和服务质量管理提供了一个坚实的基础。Netcool/OMNIbus 应用软件包括一个成

17、品软件模块库，从安全、声音和 IP、DSL/宽带、无线、转换器和路由器、企业管理系统和应用软件等超过一千个环境中收集并整理错误信息。Netcool/OMNIbus 居于各类 Netcool 解决方案的核心，包括那些商业服务管理、服务质量管理、安全管理，以及先进的关联和诊断 Netcool 解决方案。Netcool/OMNIbus 还为 IT 管理团队提供有关其基础架构和业务的重要信息，以及 Netcool 套件中那些备受赞誉的功能，包括可扩展性、覆盖面、适应性，还有已成为实时错误管理解决方案的公认标准的快速部署能力。Micromuse 公司首席技术官 Craig Farrell 表示：“Net

18、cool/OMNIbus 产品以经被全球范围内超过一千八百家用户选中，作为其 Netcool 解决方案的一部分，为大型企业和服务提供商提供安全、可升级的管理骨干。Netcool/OMNIbus 增强了我们行业领先的可扩展性、高效率和性能，并针对多区域服务管理提供更多的功能性，内建更多操作智能标准，从而保持了我们的行业领先地位。这些提升能使 IBM 的客户实现更高的操作效率，并更为高效地访商业服务管理数据。 ”报表系统架构报表系统架构数据展示平台从各管理模块收集性能数据，其中，主机系统运行监控、中间件运行监控、数据库运行监控数据从 IBM Tivoli 系统数据库中获

19、取，并汇总到本系统的报表统计模块。报表统计模块包含实时报表、历史报表、运行月报、趋势报告、比较报告、主机健康报告子系统，可对监测数据实时统计和分析，并出具分析报告。并根据实际情况可以以曲线、饼图、柱图、表格等形式进行展示，并可以根据用户需求把巡检性能报告定时发送到管理员的邮箱中。该系统可以根据管理员的需求设定不同用户以及不同的访问权限。Report Web AdminEnd userWEB报表展示帐号权限管理应用管理XML数据文件AdminWEBWEBBIRT Server.2架构分析架构分析由于客户系统监控规划的监控对象估计在 100 台以上，考虑到 Tivoli 监控服务器

20、 HUB TEMS(Tivoli Enterprise Monitoring Server)负载会比较大，我们会采用 Remote TEMS 来分担负载。可以考虑按照机房来规划 remote tems。ITM OS agent、ITM for Message and Collaboration、ITM for Database agent、ITCAM For Web Resource agent 先连到 remote tems，然后由 remote tems 去和 hub tems 通信，再由 tivoli enterprise portal server 进行展现。这样的设计，一方面方便了各

21、机房系统管理员的维护工作；另一方面，HUB TEMS 的负载减小很多，故可以不用对 HUB TEMS 做 failover，减少了一台 PC 服务期的采购，为客户节省了成本。每个 Agent 配置 primary remote tems 和 secondly remote tems。正常情况下，agent 和 primary remote tems 通信，当 primary remote tems 出现问题的时候，agent 会自动连接到 secondly remote tems。这样的设计，可以保障 agent 和 hub tems 的通信，相当于是做了 remote tems 的 fail

22、over。由于历史数据可以存放在 agent 端，采集经常也是由 agent 自己驱动，所以当 TEMS 出现问题的时候，数据采集还是正常进行，不会出现历史数据丢失。2 2项目实施技术项目实施技术方案方案2.12.1监控功能监控功能.1与事件管理与事件管理平台整合平台整合对于应用系统来说，网络、设备、各种分布式的系统、数据库系统、中间件、各种应用程序都会产生各自的事件，在系统出现故障时，故障信息通过事件的方式显示在管理员的控制台上。对于大型网络系统，一个系统管理员往往要面对成百上千个不同的事件，负担很重，而且，由于事件量大，关系不清楚，管理员很难在众多事件中分出事件的重要程度，

23、难以把重点放在对关键事件上，同时，也难以对问题进行准确的分析。由于各种事件，如网络、系统、数据库、应用的事件之间有相关性，因此对事件进行统一处理可以大大提高管理效率，加快故障分析定位和故障处理，降低由于系统故障带来的损失。IBM Tivoli 软件提供专业的事件故障管理工具 IBM NetCool Omnibus 为管理员提供企业统一的事件管理控制台，对来自各种管理应用的事件和故障进行统一处理，并且提供全周期的自动化和事件控制。包括：事件集成-一个灵活且可扩展地从分布式环境中各个信息源收集和集成消息及事件的事件集成机制，专门收集网的 IT 环境产生的事件。使管理员只需要面对一个事件控制台，就可

24、以查看网络中发生的所有事件。同时，事件可以按照来源、类型进行分组，管理员可以方便的进行查看。事件处理-对于各种信息事件进行处理。包括对事件进行过滤，滤除某些不重要的设备的不重要的事件，避免事件风暴的产生，减轻管理员的工作量。同时 Omnibus 提供强大的事件相关处理机制(Event Correlation)，管理员可以定义事件处理的规则、流程，在收到事件后，会自动经过流程处理，将多个不同事件之间的相关性进行分析，将根源事件显示到控制台上。管理员可以通过定义不同的事件处理流程，完成故障的定位，相关事件的分析，大大提高事件处理的效率。事件响应-一个通过从中央服务器发送和控制分布式应答作为系统事件

25、应答的分布式自动响应引擎，负责根据对各种事件分析的结果实现对远程分布式系统进行控制。管理员可以定义在收到相应事件时的反应方式，如声电报警、执行预定义的程序、重新启动出现故障的程序等自动化处理方式，或者将本地无法处理的故障传送给上级管理中心需求帮助。事件的自动化处理可以减轻管理员的工作量，同时提高对故障的响应速度。利用 Omnibus 提供的大量的事件收集 Adapter 可以将第三方的告警信息方便地传送到 Omnibus 中，进行集中管理，充分发挥 Tivoli 对系统的管理能力，同时也使整个系统的管理更统一。事件存放在内存数据库中，通过 SQL 语句命令，可以查询并产生 ASCII、Bina

26、ry 等格式，供第三方工具分析。.2用用 ITM 实现对操作系统的监控实现对操作系统的监控实现的指标列举如下（不限于此）：磁盘监控：磁盘监控：监控系统上配置的物理磁盘的相关属性，主要监控内容包括 Inode、,Mount 点,以及磁盘空间使用率、数据传输率、平均等待时间及繁忙程度等：基本信息监控：包括磁盘名监控： 监控当前文件系统 Mount 的物理盘名称；系统名监控：监控当前系统的主机名等；Inode 监控：监控磁盘当前的 Inode 总数、正在使用的 Inode 的数量、剩余的 Inode 数量、某个文件系统上分配的 Inode 数量，以及 In

27、ode 使用率等内容，统计值包括平均、最大、最小及总计使用率等；Mount 点监控：监控当前文件系统 Mount 点的路径名等；.文件系统监控：包括文件系统尺寸监控，统计值包括平均、最大、最小及总计使用率等；空间监控：包括当前可用的磁盘空间、可用的磁盘空间百分比、磁盘空间使用率等，统计值包括平均、最大、最小及总计使用率等；磁盘性能监控：包括平均磁盘请求队列监控，平均磁盘访问等待时间监控，磁盘数据传输时间百分比，当物理磁盘使用时间百分率过高时，监控系统会产生“磁盘时间百分率很高”的报警事件；当磁盘每秒读取过多的数据时，监控系统会产生“每秒读取字节数很高”的报警事件。 这些报警事件会即时发送到故障

28、管理控制台与业务管理控制台。文件监控：文件监控：监控系统中文件和目录的相关属性，主要监控内容包括名称、尺寸、拥有者、访问权限以及链接等基本监控信息：包括被监控文件的名称、文件大小、文件的类型、文件所在的路径名、文件和目录的访问权限、链接名、拥有者、所属组信息，以及文件最近被访问时间，上次修改时间等。网卡网卡检测与在基于 Unix 的操作系统上安装的所有网络接口卡有特定关联的瓶颈，监测内容主要有：接收和发送帧统计、网络接口名、接口 IP 地址以及接口状态等。监控所有网络接口的帧平均冲突率、平均接收率、平均发送率，平均接收错误率、平均发送错误

29、率、采样周期包括 1 分钟、5 分钟、15 分钟、60 分钟等；网卡流量统计：包括在一个给定的采样周期内收到帧的数量、发送帧的数量、帧冲突、接收错误；监控所有网络接口的包接收率，包冲突率、接收错误率、发送率、发送错误率、采样周期包括 1 分钟、5 分钟、15 分钟、60 分钟等；最大传输单元监控（FMTU）：监控网卡上传输包的最大尺寸，统计值包括平均、最大、最小及总计使用率等。NFS 统计统计检测与 NFS 有特定关联的瓶颈，主要关注：连接及错误等。主要监控内容有： 监控一定时期内的 NFS 客户端的连接请求数量，以及被服务器拒绝的数量以及百分比等；通过分析各种 N

30、FS 服务器及客户端的各种调用类型如：System 统计 Calls、Get Attribute Calls、Link Calls 、 Make Directory Calls、Null Calls、 Read Calls 、Read Directory Calls、Read Link Calls Remove Directory Calls 、Remove File Calls、Rename File Calls、root Calls 、Set Attribute Calls 、Symbolic Link Calls、Write Cache Calls 等帮助管理员分析和判断 NFS 流量，

31、修正相关问题。RPC 统计统计检测与 RPC 有特定关联的瓶颈，主要关注：调用及错误信息等。主要监控内容有：监控一定时期内的 RPC 客户端的连接请求数量，转发、等待超时、以及被服务器拒绝的数量以及百分比等；监控 RPC 传输包状态如：在一个监控周期内的不正确的 RPC 包数量、如服务器包头信息不正确，服务器返回包太短等。进程进程检测与进程有特定关联的瓶颈，如：进程占用系统资源的情况监控，以及进程状态等，当某个进程占用 CPU 时间过高时，监控系统会产生“进程占用 CPU 时间过高”的报警事件，并即时发送给故障管理控制台与业务管理控制台。

32、进程监控参数包括：进程组 ID、用户 ID、父进程 ID、进程会话 ID、以及占用系统 CPU 时间、用户 CPU 时间、占用内存的百分比、占用的虚拟内存地址、进程开始时间、进程运行时长、启动该进程的命令行等；进程状态监控如：监控处于不存在、活动、正在运行、停止、睡眠、等待状态的进程等；监控启动该进程的终端名、用户名、Major Fault、Minor Fault、进程的优先级等；在处理其中当前运行的进程监控，处于运行队列中等待 CPU 的进程监控，进程 Idle 时间监控，进程等待 CPU 时间、处于等待锁状态的进程监控等。CPU检测与中央处理器（CPU）相关的瓶

33、颈，主要关注：CPU 使用率很高，多个处理器问题。在监控过程中可以识别的 CPU 问题有：当系统有多个处理器且最多使用和最少使用的处理器的使用百分率之差很高时，监控系统会产生“使用率差值百分率很高”的报警事件；当系统中安装的一个或多个设备占用过多处理器时间时，监控系统会产生“硬件忙”的报警事件；当某个进程使用处理器时间百分率过高时，监控系统会产生“进程数很高 ”的报警事件；检测在一定的时间范围内，平均 CPU 繁忙时间、平均用户 CPU 时间、平均系统 CPU 时间，采样周期包括 1 分钟、5 分钟、15 分钟、60 分钟等；当处理器使用率很高，但并不是由于特定进程或设备在运行时，监控系统会产

34、生“处理器忙”的报警事件；监控处于等待 I/O 的状态的 CPU 时间，当系统调用达到监控策略中的规定值时，监控系统会就此问题产生报警事件；在多处理器环境中监控 CPU 状态包括 CPU ID 、Online、Offline 状态等。系统属性系统属性检测与 Unix 系统有特定关联的瓶颈，主要关注：虚拟内存，Swap 区、负载平均，逻辑块读写等。在监控过程中可以识别的问题有：监控有关内存的使用情况，可以识别系统中可用内存过低，SWAP 可用空间过低，额外的或异常的系统页面调度，如 page-in 或 page-out，当这些情况的发生频率达到监控策略中的规定值时，监

35、控系统会就此问题产生报警事件，并即时发送到故障控制台和业务管理控制台；在一定的采样周期内，当存在过度从磁盘物理块读取或向磁盘物理块写入等情况时，监控系统会产生相应的报警事件；在一定的采样周期内，当存在过度从磁盘逻辑块读取或向磁盘逻辑块写入等情况时，监控系统会产生相应的报警事件；监控系统的平均负载，当系统内核运行队列中存在的进程超过监控策略中的规定值时，监控系统会就此问题产生报警事件；监控系统调用，当系统调用达到监控策略中的规定值时，监控系统会就此问题产生报警事件；这些报警事件会即时发送到故障管理控制台与业务管理控制台。用户属性用户属性检测与用户有特定关联的属性，主要

36、关注：用户名、用户 ID、Idle 时间、位置信息、登录时间、登录终端等。.3用用 ITM 实现实现 Windows 平台的监控平台的监控Windows 系统应监控以下类别系统参数：活动服务器页面DHCP 服务器 DNS 动态更新DNS 内存DNS 查询DNS WINS DNS Zone Transfer FTP 服务器统计 FTP 服务Gopher 服务HTTP 内容索引HTTP 服务ICMP 统计 IIS 统计 Indexing 服务Indexing 服务过滤器 IP 统计 Job Object Job Object 详细信息MSMQ 信息存储 MSMQ 队列MSMQ 服务

37、MSMQ 会话网卡 网段NNTP 命令NNTP 服务器 缓存设备相关性 设备Event Log 文件变更 文件变化趋势 逻辑磁盘 内存日志报告 对象虚拟内存 物理磁盘 打印作业 打印机进程CPU注册表服务器服务器工作队列 服务依赖性 服务系统线程打印队列进程 I/O RAS 端口SMTP 服务器 TCP 统计 UDP 统计 Web Service.4用用 ITCAM For database 实现对实现对 Oracle、SQL 等数据库监控等数据库监控ITCAM 实现实现 Oracle 数据库监控数据库监控提供关于用户指定的消息队列（等待、就绪、过期

38、状态）中的消息的数量；包括平均传播率；平均就绪消息等待时间，传播错误；过期消息数量；就绪消息数量；等待消息数量；就绪状态消息总等待时间。监控从 Oracle 告警日志中收集的详细信息。包括：消息 ID；消息内容；消息时间戳；上次报错周期；上次错误时间；上次管理操作错误时间；间隔期内管理操作次数；实例启动后管理操作次数；Critical 告警次数；间隔期内错误总数；实例启动后错误总数；Warning 告警次数。监控服务器实例的缓存使用信息，包括：目录缓存内条目数；目录缓存内固定条目数；清洗目录缓存次数；目录缓存读取次数；目录缓存命中率；目录缓存错失次数；目录缓存修改次数；目录缓存扫描次数；目录缓

39、存有效条目数；库缓存访问次数；库缓存命中率；库缓存请求次数；库缓存无效次数；库缓存重转次数；redo log 中现有 Get 次数；Redo log 现有 miss次数；Redo log 中 miss 百分比。监控指定 cluster 内的行链接的数量。监控服务器实例的配置信息，包括：默认配置是否使用；参数名；参数 ID；参数类型。监控服务器内锁的争夺情况，包括：最大争夺分布比例；锁命中率；最大允许 DML 锁数量；最大争夺内等待会话数；最多 waiters 的对象 ID；被 Block 的进程比例；等待的进程比例；最大的 DML 锁比例；指定样本时间内的：Blocker 数量，Buffer

40、锁数量，CI 锁数量，CS 锁数量，Cross-instance锁数量，Data 锁数量，DR 锁数量，DX 锁数量，DLL 锁数量，DML 锁数量，文件锁数量，Generic 锁数量，实例锁数量，库锁数量，Master 锁数量，Media 锁数量，Mount 锁数量，Mount-startup 锁数量，Redo 锁数量，行锁数量，SN 锁数量，SQ 锁数量，SV 锁数量，SGA锁数量，Space 锁数量，SC 锁数量，SH 锁数量，TS 锁数量，TT 锁数量，Transaction 锁数量，USE_ROW_ENQUEUE 锁数量；用户锁数量；Waiter 数；Write-atomic-log

41、-switch 锁数量等等。监控数据库的性能和可用性，包括：归档日志模式是否启用；自动归档；DB Block 大小；DB 文件打开数；数据库可用空间比率；最大允许打开文件数；最大文件打开比率；系统表空间空闲比例；系统表空间空闲待大小；数据库总空间；总 extent 数量；定义文件总数；脱机状态文件总数；总表空间大小。监控争夺协议的 dispatcher 进程，包括：Dispatcher 平均等待时间；Dispatcher 繁忙率；Dispatcher 名称；Dispatcher 网络地址；监控表空间内的文件信息，提供大小，空间信息，碎片等文件管理信息：包括：备份状态；文件 ID；文件名；文件状

42、态；最大空闲块 KB 数；表空间内最大连续空闲空间比例；文件分配的 Extent 数；空闲块数；表空间空闲比率；表空间名称；最近备份时间戳；文件或表空间的总空间。监控表空间内的索引信息：具体包括：索引名；索引类型；已删除比例；索引对象名；索引对象类型；表空间名等。监控一个命名空间内的库缓存信息，能够报告对库缓存的各类操作信息：包括：数据库名；Execution 命中率；Execution 命中次数；Get 命中率；Get 命中次数；Get 请求数；对象无效次数；命名空间；Reload 次数等。监控 listener 的状态：包括：Listener 名称，Listener 端口，Listener

43、 协议，Listener 状态等。监控等待锁和锁冲突的信息，能够报告用户 ID，被阻塞对象类型和锁模式等等具体包括：被阻塞会话锁住的对象名称、类型；阻塞会话的 ID；阻塞会话的用户 ID；锁模式；被锁对象 ID；等待会话的 ID；等待 LOCK 的用户 ID；监控日志信息报告回滚数据的使用和状态：具体包括：回滚段的平均 extent 数量；所有回滚段上的平均活动交易数和总活动交易数；缓存繁忙等待百分比；需要恢复的回滚段百分比及数量；活动回滚段大小；总在线活动回滚段数；总 pending 离线回滚段数；总回滚段的extent 数、extend 数、Shrink 数；总回滚段数；监控 buffer

44、 中在一个或者多个数据块中的分布锁，报告 PCM 锁的转换时间等；监控服务器实例的单个进程，报告进程的 ID，状态等详细信息，详细包括：是否后台进程；进程使用的 CPU 时间百分比；Latch 地址；是否 Latch 等待；Oracle 进程 ID；是否系统进程；操作系统进程 ID；进程地址；进程执行时间；进程序列号；进程启动时间；程序名称；CPU 时间；进程使用内存数；用户 ID 等。监控服务器实例的所有进程信息，报告 CPU 使用情况；进程活动；系统进程等等，详细包括：系统 Archive 标志；系统 Check Point 标志；系统 Locking 标志状态；系统 Log Writer

45、 标志状态；实例的最大并发进程数；活动进程与最大并发进程数占比；系统 Process Monitor标志状态；等待 Latch 的进程数；系统 Recovery 标志设置状态；应用进程使用 CPU 时间百分比；实例使用 CPU 时间百分比；请求平均等待时间；系统 Monitor 标志；Snapshot Refresh 标志设置状态；后台活动进程数；前台活动进程数等监控活动回滚段，报告状态、大小、交易负载、收缩等，详细包括：平均收缩字节数、活动extent 平均字节数、每次回滚段写入字节数、当前回滚段写入字节数、回滚段内活动交易数、回滚段优化字节数、回滚段数量、回滚段收缩次数、回滚段状态等监控表

46、空间内定义的段信息，包括数据大小、空间使用和碎片信息，包括：段剩余空间不足；段内初始 extent 大小；段内最大 extent 数；段内最小 extent 数；下一 extent 大小；自由列组数；自由列组内自由列数；已分配 extent 百分比；段名；段属主；段类型；表空间名；未分配 extent 数；表空间或文件字节数监控 server 实例，包括状态、CPU 使用；数据缓存大小和数据库报警日志等信息，详细包括：Archive 目标设备的剩余空间及使用空间；data collector 状态；SGA 内的数据缓存大小，日志缓存大小；实例的数据库是否 mount，是否 open 在用；服务

47、器实例使用 CPU 百分比；服务器状态；SGA 空闲空间百分比；总 SGA 大小；共享池大小；实例已启动时间；操作系统占用 CPU 百分比；磁盘内可创建 redo log 数量等报告 Oracle 系统状态、版本信息等企业视图，除 Server 属性包括内容外：目录缓存条目数；目录缓存命中率；日志缓存 miss 百分率；上一报错时间；上一间隔内错误总数；实例启动后报错总数等监控服务器实例，详细包括：是否开启 check point 进程；Distributed 选项是否开启；操作系统类型；parallel query 选项是否开启；parallel server 是否开启；Oracle 版本状

48、态；global SQL trace 工具是否使用；实例启动具体时间等监控服务器实例中的单个 session for a server instance. 报告 session 状态，waits、gets 和锁等信息，详细包括：客户进程 ID、用户 ID；session 执行正在执行命令；session 是否处于等待状态；session 正在等待的资源名称；session 正在等待的锁的地址；session 内最大可开启游标数；session 所属进程地址；进程执行程序名称；进程执行时间；session 模式名称；模式用户 ID；session 序列号；session 缓存命中率；sessio

49、n ID；session 状态；session 类型；session 内的阻塞变化数；session 内发生的物理读次数；使用本次 session 的用户 ID；session是否等待锁等信息监控实例内的所有 sessions 信息，报告总 session 数量；最大 session 数量和等待锁的 session数量等等；具体监控内容有：活动 session 数量；同时间内实例可支持活动的 session 总数；非活动 session 数量；等待被 SMON 进程清除的 killed session 数量；已活动的 session 百分比；等待锁的 session 总数；使用共享进程的 se

50、ssion 数量；实例内总 session 数量等信息监控实例的 SGA，提供.SGA 的相信信息，包括：SGA 的数据缓存大小；SGA 内的 redo log大小；SGA 最大空闲百分比；SGA 最小百分比；SGA 目录缓存百分比；SGA 空闲比例；SGA 库缓存比例；SGA 存储 PL/SQL 百分比；SGA 内共享池大小；总 SGA 空间等信息监控库缓存内装载的 SQL 语句内容，格式为 60 个字符之内，超过 60 个字符将被截断。监控实例内的各类系统统计信息，提供各类详细信息的平均、最大、最小 delta 值提供各种分类，包括统计信息，进程，sessions，锁，回滚段和数据库的详细

51、信息监控实例的性能统计信息，提供类似读写的平均数和打开的游标数以及死锁数等信息，详细内容有：check point 平均间隔；最长被阻塞交易时间，间隔期内死锁数和死锁超时数；Core Dump 目标设备空间使用率；当前打开游标数；间隔期内全表扫描行数；间隔期内行存储数监控单张表，尤其是行链接信息。监控表空间，提供表空间可用空间和段及回滚段的数量，如：表空间状态；表空间空闲比率；回滚段数量监控阻止回滚段到下一 extent 的交易的信息，包括回滚段正在写的 extent 数量；回滚段数量；交易序号；交易其实 extent 号；交易状态等预报收集历史数据的属性组要耗费的磁盘空间，当定义数据收集策略

52、后重点考虑磁盘容量ITM 实现实现 SQL Server 数据库监控数据库监控监控数据文件的空间使用情况，剩余空间所占的百分比，数据文件的大小。监控数据库的状态。监控数据库名，数据库的状态，数据库的空间使用情况。监控日志文件占用的空间使用情况，日志文件剩余空间所占的百分比。监控事务复制的相关信息：包括事务复制的状态、速度以及事务复制产生的延迟。监控数据库的错误汇总、数据库的访问情况汇总等。监控设备的剩余空间及剩余空间所占的空间百分比。报告被阻塞的进程 ID 和请求进程的 ID。监控页面锁、共享锁、高级锁、区域锁、锁更新等信息。监控总错误数，Total Errors

53、Current Interval 以及总的错误数目。当前的 CPU 利用率、总的磁盘 IO、总的 CPU 时间以及当前被分配的内存空间大小。当前的时间间隔、主机名以及各种进程的比例和系统 CPU 的使用情况。具体如下：各种进程的比例包括：坏进程所占比例被阻塞的进程所占比例被感染的进程所占比例处于 LOCKSLEEP 进程所占比例处于其他睡眠状态进程所占比例处于停止状态的进程所占比例CPU 使用情况：每一个应用程序所用的 CPU 资源每一个系统所用的 CPU 资源总进程的状态：所有的坏进程所有处于睡眠状态的进程所有被阻塞的进程所有被感染的进程所有被停止的进程所有处于 LOCKSLEEP 状态的进

54、程所有处于其它睡眠状态的进程所有被挂起的日志监控远程 SERVER 的 ID、状态和主机名。监控当前使用的缓冲区、处于激和状态的缓冲区和总的缓冲区大小等信息。监控缓存利用率、处于激和状态的缓存、总缓存大小等信息。监控 CPU 的使用情况：每一个应用程序占用的 CPU 资源；每一个进程占用的 CPU 资源；OS 占用的 CPU 资源。监控 Cache 工作状态：Cache 命中率、Cache 剩余空间、Cache 最大可用空间搜索、数据Cache 空间的大小、进程占用 Cache 的大小、SQL 代理进程失效的工作，正常使用的时间。监控网络的读写速率和磁盘读写速率，CPU 的使用情况，IO 忙的

55、情况。监控 IO 错误的间隔，自启动以来的所有 IO 错误，每个 IO 错误的平均时间间隔。监控数据库空间的碎片情况。监控 Client 主机名和 Client 的进程 ID。.5用用 ITCAM 实现对实现对 WebSphere、Tuxedo 的监控的监控针对客户企业中存在多厂商的中间件产品例如 Websphere、Tuxedo 等以及部署在上面的 B/S、C/S应用都可以通过 ITCAM for Application 和 ITCAM for J2EE 进行系统、完善的监控。使用 ITCAM For Application 不用对应用做任何改动，就可以实现深层的应用/交易监

56、控。ITCAM For Application 主要对基于 J2EE 的应用程序进行实时监控和历史数据分析，它能够发现并且报告 J2EE 应用的健康度。它的监控贯穿整个应用流程，如应用程序服务器、中间件适配器、传输协议、数据库、并且能够监控后台如 Tuxedo、IMS 等主机系统。ITCAMfWS 可以收集应用程序请求周期的数据，然后存储到监控数据库，数据包括请求开始，结束的时间，所用的中央处理器时间等等，并且能够通过一层层的递进跟踪找到每个类，每个方法的响应时间，中央处理器时间，从而定位发生交易失败、响应恶化的请求，并找到应用程序需要改进优化的地方。ITCAM For Application

57、 不需要用户更改任何 J2EE 和 Mainframe 的代码，收集到的数据能够用来帮助应用维护人员和应用开发人员分析系统和应用程序的健康度。除了应用级别的数据被收集外，系统级别的数据，例如，应用服务器的状态、中央处理器的使用、内存的使用、数据库连接池、JVM 线程池、EJB 的使用等等，也会被收集，用来辅助用户去分析问题，解决问题。ITCAM For Application 对于这些数据提供了实时的图形化的监控界面。对于当前环境中基于 WebSphere 的标准 J2EE 应用，可以通过部署 ITCAM For Application 监控来快速实现监控。对于当前首要的报警需求，可以根据业务

58、特征进行定义，例如对某些系统的特定重要交易的性能进行监控，并在它们发生异常时进行报警。同时，对于资源层面和应用服务器整体的状态，也可以设置对应的报警。附：资源报警列表CPU平台 CPU 平均使用百分比JVM CPU 平均使用百分比内存JVM 堆大小垃圾回收频率垃圾回收时间垃圾回收后的平均 JVM 堆大小资源池JDBC 池使用百分比JDBC 并发等待数线程池使用百分JCA 池使用百分比应用能力请求频率会话数不可用的服务器平均响应时间未捕获的 Java 异常数附：应用性能报警列表请求发生次数方法发生次数SQL 发生次数请求消耗的 CPU 时间方法消耗的 CPU 时间请求的驻留时间已完成方法的驻留时

59、间已完成SQL 的驻留时间已完成请求的等待时间方法的等待时间请求驻留时间正在进行请求的未捕获异常方法的未捕获异常请求的锁定获得时间正在进行请求的锁定获得时间已完成方法的锁定获得时间已完成当上述请求的响应发生异常时，可发出报警。同时也可以设定对应用的全局性报警：应用会话数超过某个值应用平均响应时间超过某时间指标JVM 堆大小大于某百分比JVM CPU 占用超过某百分比JDBC 池使用百分比超过某百分比应用服务器不可用（宕机或无法响应）.6用用 TPC 实现对存储的监控实现对存储的监控随着客户业务不断扩大，其 IT 软件平台以及硬件平台也在不断的进行扩容，而处理这些需求的人员数目却

60、没有增加，IT 员工经常不得不在情况最糟的需求高峰时，超量供应包括存储量在内的 IT 资源。存储区域网络的使挑战更为严峻，使得解决存储容量供应成为一个人力密集性的过程：多达 50 个单独步骤，即使是一个专家，也要花费好几天的时间。结果 - IT 环境变得非常不灵活、昂贵、无法充分利用而且难以管理。通过项目的实施同时借助于针对磁盘、数据和结构的 TPC 软件，可以帮助用户简化和自动化企业存储基础设施的管理：1)管理文件系统和数据库的容量利用率，并自动化文件系统容量供应。 2)管理、监视和控制 SAN 结构。 3)从单一用户界面执行多设备的设备配置和管理。 4)调优和前摄性管理 SAN 上受支持的