IBM解决方案
?磁盘时间百分比率 ?每秒读取字节数 ?传送速率
?每秒写入字节数 ?物理磁盘可能碎片 ?物理驱动器速率
监控打印机 ?当前时间百分率 ?作业错误数
?每日作业错误数 ?未就绪错误数 ?每日未就绪错误数 ?缺纸错误数
?每日缺纸错误数
监控进程 ?进程句柄泄漏 ?进程CPU使用率
监控服务 ?服务失败 ?服务停止
监控TCP/IP ?分段率 ?ping数值 ?段ReXmit
2.3.3 使用IBM Tivoli Monitoring for Databases来监控数据库
IBM Tivoli Monitoring for Databases能够实现对Informi、MS SQL Server、DB2、Oracle等各种数据库系统关键资源的自动监控,帮助管理员及时发现故障和故障隐患。IBM Tivoli Monitoring for Databases对于各类数据库提供了大量的资源模型,针对XX的监控需求,我们建议实施以下一些主要的资源模型来实现对XXInformix、DB2数据库的监控:
IBM解决方案
Informix数据库监控:
?Server State:监控Informix Server的状态。 ?Deadlocks:监控数据库死锁的数量。 ?DML Lock Ratio:DML锁利用率
?Logical Log Usage:监控Logical Log的剩余空间百分比。 ?Chunks:监控数据库Chunk的数量。 ?Dbspace:监控数据库的空间使用状况。 ?Cache Hit Ratio:监控数据库的缓存命中率。 ?Active Transaction:监控数据库活动交易的数量 ?Archive:监控Informix Onbar备份进程的更新状态 ?LRU Queues:监控LRU队列 ?Overflow:监控用户线程溢出 ?Rollback Rate:监控回滚率
?Virtual Processors:监控虚拟处理器的CPU利用率
?Writes:监控Chunk writes、LRU Writes和Forground Writes
?Waits:监控Buffer Waits、Lock Waits、Checkpoint Waits和Latch wait
DB2数据库监控:
?Instance Status:监控数据库Instance状态 ?Database Activity:监控数据库的活动 ?Locks and Deadlock:监控数据库锁和死锁 ?Direct I/O:监控数据库I/O情况 ?Buffer Pool:监控数据库的缓存 ?Lock Wait:监控等待锁资源的应用数量 ?Sort:监控Sort
?Logging:监控DB2数据库的日志功能 ?Package Cache:监控Package缓存
?Replication Capture:监控DB2 Replication的Capture组件 ?Sorting:监控数据库管理器、数据库和应用的Sorting活动 ?SQL Cursor Activity:监控SQL Cursor的数量 ?SQL Statement Activity:监控数据库的Statement活动 ?Table Activity:监控数据库表的活动
以上各个Monitor均设置相应的阈值,当监控返回值达到阈值时进行报警。
IBM解决方案
2.3.4 使用IBM Tivoli Monitoring for Domino来监控IBM Domino
IBM Tivoli Monitoring for Massaging and Collaboration: Domino能够实现对IBM Domino进行自动监控,帮助管理员及时发现Domino故障和故障隐患。
IBM建议XX监控以下Domino资源
?Domino Database Management:监控Domino数据库的状态 ?Domino Mail Statistics Monitor:监控Mail系统状态 ?Domino Replicator Status:监控复制状态 ?Domino Server Avaliability:监控服务器可用性
?Domino Server Health:监控Domino服务器的健康状况。 ?Domino SMTP Mail Statistics Monitor:监控SMTPMTA中的邮件 ?监控Domino性能,包含以下参数: ? DPSCalendarEntry ? DPSDatabaseAccess ? DPSNABSearch ? DPSNetEchoDPS ? DPSReplicateLocal ? DPSRoundTripMail ? DPSWebAccess
2.3.5 使用IBM Tivoli Enterprise Console来集中管理事件
事件相关处理是专门针对建立企业控制中心面临的难题:问题根源分析。当企业控制中心建立后,超过每天数十万条报警事件的分析是管理员面对的难题,报警事件包括网络、操作系统、数据库、应用的告警和通知事件,通过简单的过滤处理很难找到问题的根源,必须使用复杂的相关分析引擎进行处理,才能将每天几十万条报警事件转化为几十条名明确的根源故障报警,才能进行有效管理。例如:当一个网络资源出现故障时,监控系统会在每一个轮询周期发送一个报警。这样,一个报警会重复出现多次,处理规则可以自动处理重复事件,只报出第一条收到的事件和重复的次数。IBM Tivoli Enterprise Console可以提供上述功能。
IBM Tivoli Enterprise Console(TEC)是各类监控报警信息和系统日志信息的管理中心。提供集中的事件展示、事件报警和处理。我们建议实施的事件管理内容包括:
TEC主要的功能是提供不同来源事件相关处理能力,这样可以确定问题的根源。例如:一个核心交换机的模块故障导致多种报警,有网管系统的报警,有操作系统、数据库、中间件、应用的多个报警,事件数量可能高达数百个,而交换机故障报警可能淹没在这数百个报警事件之中,导致处理问题时间很长。通过TEC的相
IBM解决方案
关性处理规则,会确定出是交换机的模块故障导致这数百个报警,确定问题根源,从而大大减少故障处理的时间。
下面列举一些网络事件相关性分析的实例:
网络事件的过滤、上报与相关性处理
网络中一旦发生错误,就会有大量的相关事件产生,因此,对收集到的事件进行过滤、相关性处理是很重要的。另外,由于我们要设计两级网管结构,网络事件的上报规则也会对网管系统有很大的影响。
过滤规则
对持续的、内容重复的告警(如网络持续报告某端口Down)进行过滤; 对Cisco Syslog中Debug级别的信息进行过滤; 对其它级别低、用户不关心的信息进行过滤。
相关性处理规则
某一Interface Down,如在一分钟内又Up,且之后五分钟没有再Down,则两条进行相关性处理为一条Up/Down。
如某一Interface在五分钟之内超过2次Up/Down,则把这多条Up/Dwon信息相关性处理为一条“链路不稳定”信息。
对于重要服务器和PC,Interface Up/Down信息与Node Up/Down信息进行相关性处理为一条。
上游路由器Down事件和下游结点Down事件进行相关性处理为一条。
如果对某一个性能监控设置了两个阀值,比如CPU利用率超过50%是3级告警,超过80%是4级,则超过高级别阀值时,两条告警进行相关性处理为一条。
事件集中: ? ?
Tivoli监控事件的集中:将IBM Tivoli Monitoring和Tivoli Manager for Databases产生的报警事件统一发送到TEC。
系统日志和出错信息的集中:通过Tivoli Logfile Adapter将UNIX系统的日志信息和错误报告(AIX Error Report)发送到TEC。
IBM解决方案
?
应用信息的集中:通过Tivoli Logfile Adapter将重要应用的Log信息发送到TEC。
事件报警和处理:
针对不同类型、严重性级别的事件,通过声音报警、弹出窗口等多种方式报警,或者根据策略将告警信息送到故障处理系统。
2.3.6 应用监控
应用监控主要通过监视应用日志达到监控的目的,日志的监控通过IBM Tivoli Enterprise Console的Logfile Adapter。定义应用日志文件的格式后,Logfile Adapter可以自动将日志文件中出现的报警经过过滤后实时发送到事件管理中心,便于第一时间进行响应。
下图展示了日志管理的原理:
Tivoli管理服务器定义应用日志格式模板——黄色小块,下发到被管理服务器后自动开始侦测日志变化,将事件格式化并过滤后发送到事件管理中心——Tivoli
百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读,免费范文网,提供经典小说综合文库IBM Tivoli系统监控方案详解(4)在线全文阅读。
相关推荐: