IT运维管理解决方案V1.0(29页).doc

《IT运维管理解决方案V1.0(29页).doc》由会员分享，可在线阅读，更多相关《IT运维管理解决方案V1.0(29页).doc（29页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、-IT运维管理解决方案V1.0-第 29 页系统运维管理整体解决方案目 录第一章项目概述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总体结构71.2.1.1ITM架构81.2.1.2TPC架构101.2.1.3ITCAM架构101.2.1.4Netcool网络及事件管理平台111.2.1.5报表系统架构111.2.2架构分析122项目实施

2、技术方案122.1监控功能122.1.1与事件管理平台整合122.1.2用ITM实现对操作系统的监控132.1.2.1磁盘监控：132.1.2.2文件监控：142.1.2.3网卡142.1.2.4NFS统计142.1.2.5RPC统计142.1.2.6进程152.1.2.7CPU152.1.2.8系统属性152.1.2.9用户属性162.1.3用ITM实现Windows平台的监控162.1.4用ITCAM For database实现对Oracle、SQL等数据库监控182.1.4.1ITCAM实现Oracle数据库监控182.1.4.2ITM实现SQL Server数据库监控212.1.5用

3、ITCAM 实现对WebSphere、Tuxedo的监控222.1.6用TPC实现对存储的监控242.1.7事件管理实施252.1.8报表管理实施252.1.8.1报表展现262.1.9数据采集频率272.1.10报警处理282.1.10.1报警分级282.1.10.2报警方式282.2分布式支持282.3系统安全性292.4扩展接口292.4.1与Tivoli其他产品的接口292.4.2二次开发的接口292.4.3通用代理（Universal Agent）292.5性能分析302.6方案总结312.7本方案的优势31第三章IT运维流程管理方案324.1需求分析324.2流程设计334.3 T

4、ivoli 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服务水平管理384.4 Tivoli Service Request Manager的技术实现394.4.1 Tivoli Service Request Manager体系架构39第一章 项目概述客户IT环境复杂,IT资源类型众多,维护难度高,亟需建立一个集中的运维监控体系

5、。以达到IT资源的集中管理、综合分析，提高工作效率和运维质量的目标。项目建设的整体目标为： 整体规划、分布实施、重点突破，务求实效，作为整个系统与网络监控平台建设的知道思想； 采用成熟的技术，配置要平衡； 具有良好的稳定性、高效性、安全性、灵活性； 具有良好的开放性，有较好的兼容能力； 具有较强的扩充能力； 需要能保护现有投资。总体需求分析包括： 监控：主机、存储、网络、应用（数据库、中间件），故障告警、性能分析、自动发现 2.服务流程：服务台、事件管理、故障管理、变更管理、发布管理、配置管理、知识库 3.多维度展现： 4.报表：第二章 监控技术方案1 系统总体框架设计1.1 设计原则客户信息

6、系统的管理必须采用有效的方法，在客户信息系统整个范围内实施管理策略和流程。客户信息系统的管理体系侧重在如何提供一个适合客户信息系统的低风险的IT管理模式，设计、建构、实施一个统一、集成并可扩展的管理结构，实现对复杂的计算机系统有效的管理。客户信息系统面对的是复杂的管理对象和多种管理需求。如果没有一套统一、集成的管理系统，在网络、系统和服务发生变化时，或者管理任务发生变化时，将可能导致管理体系大的调整，管理员可能需要花费很长时间和精力重新学习新的管理技能，从而导致管理效率的下降。最终将导致管理工作实施的周期加长，管理错误增多。统一和集成的管理将帮助最好的利用管理员的技能和精力，对客户系统进行高效

7、、准确的管理。根据客户信息系统平台建设需求和我们的经验，在设计信息监控平台时应满足以下原则：1.1.1 管理系统自动化对于客户信息系统而言，建构在管理平台上的，统一、集成的管理模式可以降低管理系统维护的费用和风险，主要体现在： 能够识别出管理复杂系统存在的困难和长远发展的问题，从而得到避免，防止用户重复投资 减少对将各种单点管理工具勉强组合在一起工作，以满足管理工作的需要 避免重复的管理工作，减少管理功能上的重复 管理平台可以实现各管理应用间的通信，以更好的解决问题 自动化管理减少管理员维护工作量，可以在统一平台上完成自动管理和监控，从而提高管理效率。1.1.2 管理系统化该平台要对客户信息系

8、统进行综合管理。系统的构成层次从下至上为：物理网络层、系统层、数据库层及应用层，只有做到对所有资源的统一管理，才能全面的管理好系统资源。任何管理上的遗漏，都将成为系统故障出现的隐患。同时在单一管理环境下，实现对所有IT资产的集中化管理,并且对所有的平台都有统一的操作界面及管理, 简化操作。 全面的管理，提高客户信息系统的整体可用性。 减少系统管理人员对问题的定位时间。1.1.3 管理系统实时性IT系统管理平台的监控对象是重要的IT资源，这些IT资源承载着多个关键的业务系统，对于监控系统来说，要在系统发生问题时实时的捕捉，确保信息的实时、完整。1.1.4 管理系统简单直观性系统应采用直观监控界面

9、，并采用直观、清晰的展现形式；同时系统还应具有操作简便、使用方便的功能。1.1.5 管理系统对资源的占用在实现管理的同时，必然会占用一定的网络系统资源，如何尽量减少资源的占用，是实现有效的管理系统的重要因素。因此在IT系统平台的选择上，需要管理平台对资源的占用最少，尽量采用单一代理，轻客户端程序，以减少对系统资源的占用。同时管理平台需要具有分布式结构，以减少管理对网络资源的占用。1.1.6 管理体系的开放性管理系统的开放性，是设计客户监控系统的一个原则。管理系统需要符合业界标准，以实现对各种资源的统一管理和与其它管理软件的集成。同时管理系统需要开放开发接口，以方便客户扩展管理功能。 该系统管理

10、需要基于开放的管理平台，遵循业界标准，并提供管理接口： 网络管理基于SNMP标准网管协议 系统管理平台基于面向对象标准：Object Management Group(OMG)：Object Request Broker ArchTECture (CORBA) 支持第三方厂商的应用集成，为系统管理的选型提供更高的灵活性 开放的API支持用户应用软件的集成，为系统管理的内容扩充提供发展余地1.1.7 管理系统的安全性管理系统自身的安全性是保证管理工作正常进行的关键因素，因此在设计监控系统时，充分考虑了管理系统的安全性，包括： 提供管理工作的安全审计控制和日志记录 提供方便维护的安全通信结构，如信

11、息的加密 提供完整的策略和框架，并能适应组织的变化，灵活地设定管理人员的角色及权限客户系统监控需要管理平台具有优秀的体系安全管理，以保证管理的安全。1.1.8 管理系统的扩展性该监控系统平台规模会随着网络、系统、应用的扩展而扩展，因此选择的信息运维平台的扩展性对保护投资有重要意义。扩展性主要体现在： 管理功能的扩展 管理范围的扩展客户监控系统平台体系建立在企业级管理平台基础之上，具有优秀的扩展性，用户可以在需要时增加管理模块，扩展管理节点，保护现有网络系统以及应用管理投资。1.2 方案概述1.2.1 总体结构IBM Tivoli管理总体架构如下：最底层为管理对象层，包括数据中心内部的各种被管理

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

13、SNMPOmnibus下面就每个产品的具体实现进行说明：1.2.1.1 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 Warehouse对

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

15、ing的底层实现技术，实现对数据库、J2EE服务器、应用服务器等的中间件和应用的监控。1.2.1.4 Netcool网络及事件管理平台 Netcool/OMNIbus 提供了业务最为强大的事件处理能力使IT管理人员更高效地进行原始数据的访问、处理和显示。通过增加智能化来提高事件分析功能，该功能具备先进的程序语言和数据触发器，从而允许进行批处理和更复杂的数据处理操作，这为先进的商业服务管理和服务质量管理提供了一个坚实的基础。Netcool/OMNIbus 应用软件包括一个成品软件模块库，从安全、声音和IP、DSL/宽带、无线、转换器和路由器、企业管理系统和应用软件等超过一千个环境中收集并整理错误

16、信息。Netcool/OMNIbus居于各类Netcool解决方案的核心，包括那些商业服务管理、服务质量管理、安全管理，以及先进的关联和诊断Netcool解决方案。Netcool/OMNIbus还为IT管理团队提供有关其基础架构和业务的重要信息，以及Netcool套件中那些备受赞誉的功能，包括可扩展性、覆盖面、适应性，还有已成为实时错误管理解决方案的公认标准的快速部署能力。Micromuse公司首席技术官Craig Farrell 表示：“Netcool/OMNIbus产品以经被全球范围内超过一千八百家用户选中，作为其Netcool解决方案的一部分，为大型企业和服务提供商提供安全、可升级的管理

17、骨干。Netcool/OMNIbus 增强了我们行业领先的可扩展性、高效率和性能，并针对多区域服务管理提供更多的功能性，内建更多操作智能标准，从而保持了我们的行业领先地位。这些提升能使IBM的客户实现更高的操作效率，并更为高效地访商业服务管理数据。”1.2.1.5 报表系统架构数据展示平台从各管理模块收集性能数据，其中，主机系统运行监控、中间件运行监控、数据库运行监控数据从IBM Tivoli系统数据库中获取，并汇总到本系统的报表统计模块。报表统计模块包含实时报表、历史报表、运行月报、趋势报告、比较报告、主机健康报告子系统，可对监测数据实时统计和分析，并出具分析报告。并根据实际情况可以以曲线、

18、饼图、柱图、表格等形式进行展示，并可以根据用户需求把巡检性能报告定时发送到管理员的邮箱中。该系统可以根据管理员的需求设定不同用户以及不同的访问权限。1.2.2 架构分析由于客户系统监控规划的监控对象估计在100台以上，考虑到Tivoli监控服务器HUB TEMS(Tivoli Enterprise Monitoring Server)负载会比较大，我们会采用Remote TEMS来分担负载。可以考虑按照机房来规划remote tems。ITM OS agent、ITM for Message and Collaboration、ITM for Database agent、ITCAM For

19、Web Resource agent先连到remote tems，然后由remote tems去和hub tems通信，再由tivoli enterprise portal server进行展现。这样的设计，一方面方便了各机房系统管理员的维护工作；另一方面，HUB TEMS的负载减小很多，故可以不用对HUB TEMS做failover，减少了一台PC服务期的采购，为客户节省了成本。每个Agent配置primary remote tems和secondly remote tems。正常情况下，agent和primary remote tems通信，当primary remote tems出现问题

20、的时候，agent会自动连接到secondly remote tems。这样的设计，可以保障agent和hub tems的通信，相当于是做了remote tems的failover。由于历史数据可以存放在agent端，采集经常也是由agent自己驱动，所以当TEMS出现问题的时候，数据采集还是正常进行，不会出现历史数据丢失。2 项目实施技术方案2.1 监控功能2.1.1 与事件管理平台整合对于应用系统来说，网络、设备、各种分布式的系统、数据库系统、中间件、各种应用程序都会产生各自的事件，在系统出现故障时，故障信息通过事件的方式显示在管理员的控制台上。对于大型网络系统，一个系统管理员往往要面对成

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

22、息及事件的事件集成机制，专门收集网的IT环境产生的事件。使管理员只需要面对一个事件控制台，就可以查看网络中发生的所有事件。同时，事件可以按照来源、类型进行分组，管理员可以方便的进行查看。事件处理-对于各种信息事件进行处理。包括对事件进行过滤，滤除某些不重要的设备的不重要的事件，避免事件风暴的产生，减轻管理员的工作量。同时Omnibus提供强大的事件相关处理机制(Event Correlation)，管理员可以定义事件处理的规则、流程，在收到事件后，会自动经过流程处理，将多个不同事件之间的相关性进行分析，将根源事件显示到控制台上。管理员可以通过定义不同的事件处理流程，完成故障的定位，相关事件的分

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

24、内存数据库中，通过SQL语句命令，可以查询并产生ASCII、Binary等格式，供第三方工具分析。2.1.2 用ITM实现对操作系统的监控实现的指标列举如下（不限于此）：2.1.2.1 磁盘监控：监控系统上配置的物理磁盘的相关属性，主要监控内容包括Inode、,Mount 点,以及磁盘空间使用率、数据传输率、平均等待时间及繁忙程度等： 基本信息监控：包括磁盘名监控： 监控当前文件系统Mount的物理盘名称；系统名监控：监控当前系统的主机名等； Inode监控：监控磁盘当前的Inode总数、正在使用的Inode的数量、剩余的Inode数量、某个文件系统上分配的Inode数量，以及Inode使用率

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

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

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

28、ute 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流量，修正相关问题。2.1.2.5 RPC统计检测与 RPC有特定关联的瓶颈，主要关注：调用及错误信息

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

30、程开始时间、进程运行时长、启动该进程的命令行等； 进程状态监控如：监控处于不存在、活动、正在运行、停止、睡眠、等待状态的进程等； 监控启动该进程的终端名、用户名、Major Fault、Minor Fault、进程的优先级等； 在处理其中当前运行的进程监控，处于运行队列中等待CPU的进程监控，进程Idle时间监控，进程等待CPU时间、处于等待锁状态的进程监控等。2.1.2.7 CPU检测与中央处理器（CPU）相关的瓶颈，主要关注：CPU使用率很高，多个处理器问题。在监控过程中可以识别的CPU问题有： 当系统有多个处理器且最多使用和最少使用的处理器的使用百分率之差很高时，监控系统会产生“使用率差

31、值百分率很高”的报警事件； 当系统中安装的一个或多个设备占用过多处理器时间时，监控系统会产生“硬件忙”的报警事件； 当某个进程使用处理器时间百分率过高时，监控系统会产生“进程数很高 ”的报警事件； 检测在一定的时间范围内，平均CPU繁忙时间、平均用户CPU时间、平均系统CPU时间，采样周期包括1分钟、5分钟、15分钟、60分钟等； 当处理器使用率很高，但并不是由于特定进程或设备在运行时，监控系统会产生“处理器忙”的报警事件； 监控处于等待I/O的状态的CPU时间，当系统调用达到监控策略中的规定值时，监控系统会就此问题产生报警事件； 在多处理器环境中监控CPU状态包括CPU ID 、Online

32、、Offline状态等。2.1.2.8 系统属性检测与 Unix系统有特定关联的瓶颈，主要关注：虚拟内存，Swap区、负载平均，逻辑块读写等。在监控过程中可以识别的问题有： 监控有关内存的使用情况，可以识别系统中可用内存过低，SWAP可用空间过低，额外的或异常的系统页面调度，如page-in或page-out，当这些情况的发生频率达到监控策略中的规定值时，监控系统会就此问题产生报警事件，并即时发送到故障控制台和业务管理控制台； 在一定的采样周期内，当存在过度从磁盘物理块读取或向磁盘物理块写入等情况时，监控系统会产生相应的报警事件； 在一定的采样周期内，当存在过度从磁盘逻辑块读取或向磁盘逻辑块写

33、入等情况时，监控系统会产生相应的报警事件； 监控系统的平均负载，当系统内核运行队列中存在的进程超过监控策略中的规定值时，监控系统会就此问题产生报警事件； 监控系统调用，当系统调用达到监控策略中的规定值时，监控系统会就此问题产生报警事件；这些报警事件会即时发送到故障管理控制台与业务管理控制台。2.1.2.9 用户属性检测与用户有特定关联的属性，主要关注：用户名、用户ID、Idle时间、位置信息、登录时间、登录终端等。2.1.3 用ITM实现Windows平台的监控Windows系统应监控以下类别系统参数： 活动服务器页面 DHCP 服务器 DNS 动态更新 DNS 内存 DNS 查询 DNS W

34、INS DNS Zone Transfer FTP 服务器统计 FTP 服务 Gopher 服务 HTTP 内容索引 HTTP 服务 ICMP 统计 IIS 统计 Indexing 服务 Indexing 服务过滤器 IP 统计 Job Object Job Object 详细信息 MSMQ 信息存储 MSMQ 队列 MSMQ 服务 MSMQ 会话 网卡 网段 NNTP 命令 NNTP 服务器 缓存 设备相关性 设备 Event Log 文件变更 文件变化趋势 逻辑磁盘 内存 日志报告 对象 虚拟内存 物理磁盘 打印作业 打印机 进程 CPU 注册表 服务器 服务器工作队列 服务依赖性 服务

35、系统 线程 打印队列 进程I/O RAS 端口 SMTP 服务器 TCP 统计 UDP 统计 Web Service2.1.4 用ITCAM For database实现对Oracle、SQL等数据库监控2.1.4.1 ITCAM实现Oracle数据库监控 提供关于用户指定的消息队列（等待、就绪、过期状态）中的消息的数量；包括平均传播率；平均就绪消息等待时间，传播错误；过期消息数量；就绪消息数量；等待消息数量；就绪状态消息总等待时间。 监控从Oracle告警日志中收集的详细信息。包括：消息ID；消息内容；消息时间戳；上次报错周期；上次错误时间；上次管理操作错误时间；间隔期内管理操作次数；实例启

36、动后管理操作次数；Critical告警次数；间隔期内错误总数；实例启动后错误总数；Warning告警次数。 监控服务器实例的缓存使用信息，包括：目录缓存内条目数；目录缓存内固定条目数；清洗目录缓存次数；目录缓存读取次数；目录缓存命中率；目录缓存错失次数；目录缓存修改次数；目录缓存扫描次数；目录缓存有效条目数；库缓存访问次数；库缓存命中率；库缓存请求次数；库缓存无效次数；库缓存重转次数；redo log中现有Get次数；Redo log现有miss次数；Redo log中miss百分比。 监控指定cluster内的行链接的数量。 监控服务器实例的配置信息，包括：默认配置是否使用；参数名；参数ID

37、；参数类型。 监控服务器内锁的争夺情况，包括：最大争夺分布比例；锁命中率；最大允许DML锁数量；最大争夺内等待会话数；最多waiters的对象ID；被Block的进程比例；等待的进程比例；最大的DML锁比例； 指定样本时间内的：Blocker数量，Buffer锁数量，CI锁数量，CS锁数量，Cross-instance锁数量，Data锁数量，DR锁数量，DX锁数量，DLL锁数量，DML锁数量，文件锁数量，Generic锁数量，实例锁数量，库锁数量，Master锁数量，Media锁数量，Mount锁数量，Mount-startup锁数量，Redo锁数量，行锁数量，SN锁数量，SQ锁数量，SV锁数

38、量，SGA锁数量，Space锁数量，SC锁数量，SH锁数量，TS锁数量，TT锁数量，Transaction锁数量，USE_ROW_ENQUEUE锁数量；用户锁数量；Waiter数；Write-atomic-log-switch锁数量等等。 监控数据库的性能和可用性，包括：归档日志模式是否启用；自动归档；DB Block大小；DB文件打开数；数据库可用空间比率；最大允许打开文件数；最大文件打开比率；系统表空间空闲比例；系统表空间空闲待大小；数据库总空间；总extent数量；定义文件总数；脱机状态文件总数；总表空间大小。 监控争夺协议的dispatcher进程，包括：Dispatcher平均等待时

39、间；Dispatcher繁忙率；Dispatcher名称；Dispatcher网络地址； 监控表空间内的文件信息，提供大小，空间信息，碎片等文件管理信息：包括：备份状态；文件ID；文件名；文件状态；最大空闲块KB数；表空间内最大连续空闲空间比例；文件分配的Extent数；空闲块数；表空间空闲比率；表空间名称；最近备份时间戳；文件或表空间的总空间。 监控表空间内的索引信息：具体包括：索引名；索引类型；已删除比例；索引对象名；索引对象类型；表空间名等。 监控一个命名空间内的库缓存信息，能够报告对库缓存的各类操作信息：包括：数据库名；Execution命中率；Execution命中次数；Get命中率

40、；Get命中次数；Get请求数；对象无效次数；命名空间；Reload次数等。 监控listener的状态：包括：Listener名称，Listener端口，Listener协议，Listener状态等。 监控等待锁和锁冲突的信息，能够报告用户ID，被阻塞对象类型和锁模式等等具体包括：被阻塞会话锁住的对象名称、类型；阻塞会话的ID；阻塞会话的用户ID；锁模式；被锁对象ID；等待会话的ID；等待LOCK的用户ID； 监控日志信息报告回滚数据的使用和状态：具体包括：回滚段的平均extent数量；所有回滚段上的平均活动交易数和总活动交易数；缓存繁忙等待百分比；需要恢复的回滚段百分比及数量；活动回滚段大

41、小；总在线活动回滚段数；总pending离线回滚段数；总回滚段的extent数、extend数、Shrink数；总回滚段数； 监控buffer中在一个或者多个数据块中的分布锁，报告PCM锁的转换时间等； 监控服务器实例的单个进程，报告进程的ID，状态等详细信息，详细包括：是否后台进程；进程使用的CPU时间百分比；Latch地址；是否Latch等待；Oracle进程ID；是否系统进程；操作系统进程ID；进程地址；进程执行时间；进程序列号；进程启动时间；程序名称；CPU时间；进程使用内存数；用户ID等。 监控服务器实例的所有进程信息，报告CPU使用情况；进程活动；系统进程等等，详细包括：系统Arc

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

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

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

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

46、ssion类型；session内的阻塞变化数；session内发生的物理读次数；使用本次session的用户ID；session是否等待锁等信息 监控实例内的所有sessions信息，报告总session数量；最大session数量和等待锁的session数量等等；具体监控内容有：活动session数量；同时间内实例可支持活动的session总数；非活动session数量；等待被SMON进程清除的killed session数量；已活动的session百分比；等待锁的session总数；使用共享进程的session数量；实例内总session数量等信息 监控实例的SGA，提供.SGA的相信信息，包括：SGA的数据缓存大小；SGA内的redo log大小；SGA最大空闲百分比；SGA最小百分比；SGA目录缓存百分比；SGA空闲比例；SGA库缓存比例；SGA存储PL/SQL百分比；SGA内共享池大小；总SGA空间等信息 监控库缓存内装载的SQL语句内容，格式为6