系统运行管理方案.docx

系统运行管理方案.docx

《系统运行管理方案.docx》由会员分享，可在线阅读，更多相关《系统运行管理方案.docx（90页珍藏版）》请在冰豆网上搜索。

系统运行管理方案

系统运行管理方案

1监控管理

监控管理主要是通过对被管对象的配置数据、性能数据、告警数据的统一采集，实现对IT基础设施、应用软件以及业务的监控，主动发现被管对象当前的故障或告警信息并进行处理，保障xxxxIT系统的稳定运营。

1.1.1IT基础设施监控

IT基础设施监控是指对xxxx所有主机、数据库、中间件、网络、存储、备份等设备及软件进行统一监控，及时发现平台类的告警。

1.1.1.1统一采集与控制

根据xxxx移动核心系统运维监控管理平台技相关的要求，本期IT基础设施监控数据采集的范围包括各种设备的告警、性能、配置数据。

采集范围包括但不限于：

IT基础设施监控的管理范围包括xxxx所有生产环境的IT基础设施，包括但不限于以下IT基础设施对象：

支持类型

主机

IBMHPSUNPCServer（Windows/Linux）

数据库

OracleSybaseDB2SQLServerInfomixMySql

存储

EMCIBMSUNHPHDS

网络设备

思科华为北电等

防火墙

fortigate思科netscreen等

中间件

WeblogicTuxedowebsphereTomcatBES等

备份

veritas等

本系统提供的采集代理主要包括：

主机设备监控代理、数据库库监控代理、中间件监控代理、网络设备监控代理、日志监控代理、存储、备份采集代理。

主机设备采集代理：

主要通过shell、操作系统命令对主机的性能信息、配置信息、告警信息进行采集。

如CPU使用率、内存使用率、SWAP交换分区使用率、文件系统使用率、磁盘IO等性能信息；主机名、地址、型号、CPU信息、内存信息、操作系统版本、逻辑卷、内置盘等信息；主机状态、主机内置盘状态、主机网卡状态、主机Cluster状态、关键进程状态等故障信息；

数据库采集代理：

主要通过SQL对数据库的字典和视图的查询封装，查看数据库相关的配置信息、性能信息、告警信息采集。

配置信息主要包括：

数据库名、版本信息、归档方式、共享内存大小、表空间大小、数据文件或设备名等信息。

性能信息主要包括：

共享内存使用率、数据缓存读命中率、表空间使用率、表空间读写次数、数据文件读写次数、数据库锁数量、数据库用户会话数等。

告警信息主要包括：

数据库状态、表空间状态、死锁等故障信息。

中间件采集代理：

中间件的类型主要但不限于WEBLOGIC、TOMCAT、WEBSPHERE、TUXEDO、BES等。

主要通过JMX对WEBLOGIC、TOMCAT；PMI对WEBSPHERE；TUXEDO自带管理命令对TUXEDO进行监控，通过探测对TUXEDO服务的可用性进行监控。

网络设备采集代理：

主要通过SNMP协议轮询、TRAP两种方式采集网络设备（路由器、交换机、防火墙等）的配置、性能、告警信息。

SNMP轮询方式：

通过SNMP轮询方式，周期性的轮询相关MIB信息（包括公有MIB信息和厂商私有MIB信息），获得相应的配置数据、性能数据。

SNMPTrap方式：

通过监听SNMPTrap端口，实时接收来自于网络设备的Trap消息，经过消息预处理后，生成告警数据。

配置数据主要包括设备型号、设备CPU大小、设备内存大小、设备缓存大小、IP地址等信息；性能数据主要包括设备CPU利用率、设备内存利用率、设备缓存利用率、端口误码率、端口丢包率等；告警信息主要包括网元状态、设备端口状态、网络链路状态、域名解析服务、NTP服务状态、IP地址重复等故障信息。

日志监控代理：

主要通过对日志文件的关键字进行全量或者增量的检索，当发现异常关键字时，及时产生信息点，通过分析处理，产生告警，及时通知用户。

存储设备采集代理：

对存储设备进行配置、性能、告警数据的采集。

配置信息：

存储阵列标识、类型、容量、RAID方式、磁盘、主机通道卡、磁盘适配卡等信息；性能信息主要包括：

磁盘IO速率、LUN的IO速率、磁盘IO读写频率、LUN的IO读写频率、CACHE读命中率、CACHE写命中率等；告警信息主要包括存储阵列状态、硬盘物理状态、硬盘逻辑状态、存储CACHE状态、磁盘适配卡状态、主机通道卡状态等故障告警信息。

备份设备采集代理：

主要采集设备CPU大小、设备内存大小、介质（池）空间大小、备份服务进程状态、备份结果、磁带库设备机械状态、备份CPU占用率、备份内存占用率、介质（池）的剩余空间、磁头距最近一次清洗时间等。

1.1.1.2数据采集

图：

运维监控管理平台数据采集原理

★信息点采集模板界面化配置

根据监控对象可灵活配置改对象需要监控的信息点、采集频率等信息，并支持模板的远程下发、更新。

★采集代理远程下发、启停与集中监控

可在下发采集模板时同步下发采集代理并进行友好的下发过程的可视化能力，下发后可自动启动采集代理。

提供集中的采集设备监控代理运行监控界面，便于维护人员实时监测各个代理的运行情况，并提供便捷的重启、模板和代理程序更新功能。

图：

采集代理监控

★采集代理组件化封装

根据不同的监控对象和采集方式的差异化，对目前的监控代理进行组件化封装：

Ø主机设备监控代理

Ø数据库库监控代理

Ø中间件监控代理

Ø网络设备监控代理

Ø日志监控代理

Ø存储设备监控代理

Ø备份设备监控代理

图：

采集模板下发

图：

模板及代理下发进度提示

图：

模板下发日志可追溯

图：

采集代理集中管控

1.1.1.3告警处理

告警处理是针对来自IT基础设施的告警信息进行统一处理，以便快速确认故障，缩短排障时间，为及时恢复系统运行打下良好基础。

包括：

告警定位、告警过滤、重复告警压缩、告警信息丰富、告警前转、告警操作等。

⏹告警定位

告警定位是通过对告警信息的查看确定故障可能发生的位置。

【主要功能】

告警故障定位应与被管对象和被管对象关联关系相结合，应能建立告警列表展示信息中相关元素和被管对象之间的关系。

对于一个告警，可根据这个关系自动确认发生告警的被管对象，进而查看与被管对象关联的其它对象情况。

可以对被管对象的最小粒度进行定位，如应用资源和关键业务点。

图：

告警定位

⏹告警过滤

告警过滤是指对大量重复的告警信息和次要、无意义的告警信息进行过滤，以避免告警风暴和无效告警或非关心告警的干扰，以提高监控与处理的效率。

【主要功能】

按维护要求和管理部门的要求及实际管理情况，针对单位时间内发生大量告警或者已知告警，设置过滤规则，过滤从底层产生的告警信息中不重要的信息，减少轻微告警的干扰，以提高监控与处理的效率。

告警过滤需要提供灵活的过滤规则，可按告警对象、告警级别、告警类别、告警标题、告警时间等设置过滤规则。

被过滤的告警信息可以选择是否入告警数据库。

对已设定的过滤规则需要提供保存和修改功能，便于维护人员灵活选择。

告警过滤应实现对以下告警的过滤：

用户确认一段时间内可以忽略的告警

周期产生的维护类告警

已进入服务管理流程进行处理，一定时间内重复发送的告警

特殊情况下，只需要记录不需要展现的特殊资源的相关告警

⏹告警压缩

告警压缩是对不同时间产生的相同告警，将其合并成一条告警信息，同时累计该告警的次数，更新最后发生时间等。

图：

告警定位

【主要功能】

在进行告警压缩时，应只在活动告警库中保留一条压缩后的告警信息。

在进行告警压缩时，应更新告警记录的发生次数、最后发生时间等信息。

在对告警进行压缩时，应能够灵活的定义压缩规则，应提供可视化的压缩规则编辑功能。

⏹告警信息丰富

告警丰富功能主要是对告警信息增加描述，使得告警信息更加详细和直白，方便系统维护人员更快的了解告警信息。

【主要功能】

应能够实现告警信息与告警对象的配置数据的关联，对告警信息进行丰富，增加对告警信息的描述，如对于主机告警，丰富相应的厂家，型号，设备描述信息等；对于数据库告警，丰富相应的数据库版本，字符集等信息；对于应用及业务关键点对象，应能够将其支撑的应用业务信息进行丰富，以便维护人员及时了解发生告警设备的全方位信息，针对不同情况分别处理。

图：

告警定位

⏹告警前转

告警前转将告警信息以各种手段（手机短信、EMAIL等）转至指定的维护人员。

【主要功能】

告警前转的设置条件：

告警级别、告警发生时间、告警标题、告警类型、告警地区、告警内容关键字模糊匹配、需要通知的相关系统和人员等。

一旦本系统接收到被管对象的告警信息，自动的根据告警前转过滤条件进行过滤匹配，并根据设置的前转方式，自动通过短信等形式发送给相应的管理人员或维护人员。

可以根据告警数据的内容自由定义短信内容，在手动前传时，可以手工编辑短信内容，短信内容应该简单明了。

图：

告警前转

⏹告警操作

告警操作主要包括告警确认、告警清除、告警级别调整、转事件单等。

【主要功能】

支持根据告警对象、告警级别、告警类别、告警时间等属性设置自动转事件单的规则。

可提供可视化的转事件单规则编辑功能；

图：

告警派单

可提供根据告警的属性字段设置自动确认规则的功能，并能根据自动确认规则对符合条件的告警进行自动确认，告警确认需要提供灵活的过滤规则，应能够通过组合不同的告警信息字段设置告警过滤规则。

图：

告警确认

可提供根据告警的属性字段设置自动清除规则的功能，并能根据自动清除规则对符合条件的告警进行自动清除；可提供可视化的自动清除规则编辑功能，并且能够对清除的告警设置告警清除标志。

图：

告警清除

根据系统告警已发生时长、告警发生次数方面发生的变化，重新调整告警级别，保证根据正确的告警系统处理的正确性。

图：

告警升级

1.1.1.4性能处理

⏹性能数据计算与汇总

对预处理后的数据进行必要的计算、汇总形成所需的性能指标。

处理后的性能数据保存到数据库中，供分析和呈现使用，性能数据的保留时间可配置。

针对部分不需要保留较长时间的性能数据，在统计汇总后，可将历史数据进行清理，减少系统对存储空间的浪费。

（批注：

与技术规范”预处理完成后的数据的保留时间，应该根据不同的数据类型进行区分”要求呼应起来）

图：

指标计算规则

⏹性能数据阀值预警

性能数据反映了系统及应用的运行状况，是判别被管资源运行是否正常的关键数据。

性能数据一旦超出预先设定的阀值时，可及时触发性能阀值越限告警，该告警称为性能阀值告警。

提供基于应用系统性能指标趋势数据的分析处理功能，实现性能预警，并为分析优化工作提供必要的依据。

提供设定、查询、修改、删除性能阀值的工具，针对统一性能指标，可设多个阀值进行分级告警。

性能阀值告警的内容应能比较全面地描述该性能数据超出阀值的情况，方便分析、排除事件。

图：

性能数据阀值预警

⏹性能数据梯度预警

系统提供梯度告警的功能，也就是两个时间点的性能数据差值如果超过了门限，则应该上报告警。

这种告警不同于性能数据的阀值告警，性能数据的阀值告警只是对一个时间点上的性能数据设定了门限，而梯度告警则是对两个时间点的性能数据的差值设定了门限。

梯度告警能够迅速发现性能数据的异常变化。

图：

性能数据梯度预警

⏹性能数据汇总统计

为了性能数据分析和呈现，以及事件的分析，系统应能定期生成统计数据。

通过分析历史指标的情况，预测未来的发展，提升管理层次，达到面向服务品质的管理。

图：

CPU汇总

1.1.1.5拓扑处理

拓扑图的生成可支持手工配置或导入，也可通过系统自动发现并注册实现，以上几种方式都是以CMDB为基础，进而获取每个节点在拓扑图中的位置和它们间的依存关系，从而构建出整个IT运营网路，通过实时刷新拓扑图，可反映出当前网络中节点的最新状态，帮助运维人员从宏观上对对整个IT支撑系统的运行情况有直观的掌握，进一步提高运维的效率。

⏹拓扑管理

通过CMDB对象实例树，可方便的对拓扑图中的节点，及节点间的关系进行维护，系统支持对节点的增加、删除、修改属性，状态及更改不同节点间的依附关系等。

图：

网络拓扑

⏹拓扑监测

拓扑监测是根据拓扑模型，对在模型上定义的关键节点，节点关键性能、质量指标数据进行实时监控，将业务系统运行中出现的告警、预警信息直观呈现在拓扑模型中，来实现对应用系统运行状态的专题式监控，及时发现用户关注的异常。

支持通过拓扑图关联到应用节点详细信息页面，可根据时间段来查询该节点的告警信息列表，进而进行相关告警处理如告警确认、告警级别调整、告警清除等操作；

支持通过拓扑图关联到应用节点详细信息页面，可根据时间段来查询该节点的历史指标数据，以表格或走势图的方式展现，支持业务指标数据导出功能，导出格式包括但不限于文本、EXCEL等文件格式；

拓扑视图支持定时无闪烁刷新功能，刷新频率不宜过高，以不影响系统性能和展现效果为基准，也不宜过低，否则无法达到监测的实时性要求。

图：

拓扑监测

⏹应用拓扑

以IT系统内的业务类型作为索引来组织被管资源的业务拓扑结构。

典型的业务拓扑图是一个树型结构，实现业务与IT基础设施关联关系的直观展现。

系统提供方便的图形化配置修改工具，允许管理维护人员灵活修改相关联资源等基本配置信息。

以下以某电信运维监控管理平台拓扑处理为例：

图：

应用拓扑

点击HB计费：

图：

节点拓扑

点击具体节点：

图：

地市拓扑

以应用系统作为索引来组织应用软件包含的被管资源的拓扑结构。

应用拓扑体现应用软件被管资源的分布和关联情况。

系统通过提供方便的图形化配置修改工具，允许管理维护人员灵活修改组成应用系统的相关联资源等基本配置信息。

拓扑图能够展现应用软件被管资源的运行状态，包括应用软件的配置信息、告警信息和性能信息，且可以实现相关拓扑图的自动生成。

图：

计费生产流程拓扑

1.1.1.6操作控制

主要完成运维监控管理平台控制模块与被监控对象之间的操作指令传递与结果反馈通道，以便完成对被管对象的自动化控制,在运维监控管理平台中的主要应用为进程、服务的启停和调用等。

图：

操作控制

操作控制主要是通过以下方式登录到设备上执行操作。

SNMP方式：

支持SNMP接口的系统，可以此方式得到；

telnet方式：

通过telnet等方式对网元进行操作；

Agent方式：

通过在服务器上安装Agent控制服务器的操作；

ssh方式：

大量操作控制采用安全的ssh执行；

FTP/TFTP方式：

FTP等文件方式传输配置文件；

rlogin方式：

远程登录后执行；

Rsh、rexec方式：

直接远程执行相应的操作；

NT登录方式：

登录到NT上执行相应的操作；

HTTPS方式：

通过HTTPS对相应的网元执行操作；

Webservice方式：

对于支持webservice的应用系统采用本方式；

图：

操作控制截面图

1.1.2应用软件监控

应用软件监控是通过对xxxx的各IT应用（进程池、进程、接口和数据文件、日志等）进行监控，及时发现系统应用软件的异常，并确定故障原因，进行故障定位和处理，保证应用软件正常运行，提高IT应用软件运行管理水平。

1.1.2.1进程监控

提供对应用进程的监控管理，确保系统可靠、稳定地运行。

支持对各进程运行状态进行监视，能够实时查看进程名称、进程号、进程启动路径、进程状态、进程说明信息等相关运行信息。

当进程异常终止时，能够生成相应告警。

在UNIX操作系统上，经常出现由于资源竞争而导致死锁的一些进程，从操作系统的进程状态上看这些进程是正常的，但从业务功能角度，这些进程实际已处于僵死状态，因为它们已不能处理任何业务逻辑。

运维监控管理平台支持对进程日志是否增长等方式发现僵死进程并告警。

图：

进程监控图

系统支持对某一时刻的进程状态进行记录拍照，在后续时刻发现与拍照记录不一致时，可按拍照状态复原；发现进程运行状态与拍照状态不符时的及时告警，通知运维人员。

1.1.2.2进程池监控

进程池监测是指对若干个具有相关性的应用进程进行集中管理监控，进程池的主要作用是在有多个客户端并发请求时提高服务器的处理效率。

⏹系统能够进程池的配置信息进行管理，包括最大进程数量、最小进程数量以及进程池对应的日志文件。

⏹系统能够通过进程池所应当包含的进程数量等性能数据的处理与分析，及时发现进程池的异常情况，保障系统正常运行，并为分析优化工作提供必要的依据。

在性能数据处理过程中，保证处理的完整性和连续性。

⏹当出现异常情况时，应能够生成相应告警并转发对应处理人员。

1.1.2.3文件积压监控

对应用系统间文件类传输接口进行积压监控，及时发现进程异常和接口异常。

1.1.2.4应用服务监控

提供对中间件的应用服务和ORACLE的job进行监控，当中间件的应用服务异常，或者ORACLE的job异常时，能够生成相应告警。

1.1.2.5侦听监测

可集中监测CRM、服务开通等系统后台侦听的运行状态信息，当侦听异常时，系统可提供集中的操作功能，重启目标侦听进程。

图：

应用侦听监控图

1.1.2.6队列监测

可集中监测服务开通后台消息队列的实时运行信息，当当前队列深度接近系统设置的最大队列深度时时，系统可及时触发告警，提醒业务支撑人员进行及时处理。

图：

队列监控图

1.1.2.7Web应用监测

可集中监测前台Web应用的运行状态、挂起线程数、超时时长，当挂起线程数较多时，系统可及时触发告警，提醒业务支撑人员进行及时处理。

图：

web监控图

1.1.2.8接口平台监测

系统可及时监测各个接口平台运行服务的运行状态和响应性能信息，针对运行异常和性能较差的服务系统可及时触发告警，并能够对服务当天的探测性能和历史响应能力进行图形化的展示。

图：

服务运行状态实时监控

图：

各接口服务响应性能对比监测

图：

接口服务响应性能趋势分析（分时及历史分析）

1.1.3业务监控

业务监控主要是对xxxx业务受理、充值缴费、停复机等端到端的客户感知度强的业务流程进行监控，主动发现这些业务流程中影响客户感知度的因素，如开通时长、充值可用性等，并不断优化系统，逐步提升内外部客户的满意度。

业务监控主要包括对业务建模、业务运营指标实时监控、业务运营质量分析、业务可用性探测等。

1.1.3.1业务建模

业务活动模型的要素包括业务关键点、业务指标、关键点间的关联关系，业务活动模型是指通过对业务进行梳理，建立业务过程模型描述关键点间的逻辑关系，并以过程模型为基础描述业务关键点与指标的关系，关键点间的关联关系。

构成业务关键点、业务指标、关键点间关联关系的多维关系模型。

图：

业务建模图

业务活动建模采用从业务活动监控需求出发、至上而下的方法，建模从过程上大体可以分为以下几个步骤：

梳理需求、建立过程模型、建立关键点与指标的关系、建立关键点间的关联关系。

⏹业务过程建模

业务过程建模首先通过对关键业务的流程梳理，确定业务处理过程中的监测关键点，以业务处理过程的视角描述关键点之间的关系，形成业务处理过程模型。

然后根据监测需要建立相应的监测指标体系，指标通过对业务基础数据的抽取和计算，来体现业务关键点的业务状态。

业务过程建模的方法：

图：

业务建模方法示意图

1.确定业务流程监测范围，选择重点需要监控的业务流程；

2.确定流程的关键点，即业务过程中的关键处理环节。

主要从监控需求出发，选择流程中容易出问题或者需要重点关注效率的环节作为关键点；

3.梳理关键点的指标。

抽取的关键业务指标能够对关键点的业务处理状态进行直观准确反映。

指标的类型一般包括业务可用性、业务及时性、业务准确性、业务处理量、积压量等；

4.通过关键点间的关联关系梳理指标之间的关联关系。

关键点间的关联关系包含某几个关键点间的关联关系、具体的关键点与整个业务过程的关联关系；

5.确定指标的分析方法，包括针对单个指标、以及多个指标之间关系的分析方法。

例如新装机流程监控：

图：

新装机流程示意图

梳理需求

建模的首要工作是通过业务活动监控的需求分析，明确监控的业务范围和要点，然后对范围内的业务及监控要点间关系进行高度概括性的描述，把相关监控要点与业务处理过程的具体环节进行映射，形成业务活动监控的需求模型。

需求模型梳理是为过程建模做准备，它没有统一的标准，主要依据是业务过程的实际情况及业务人员的经验。

建立过程模型

业务活动监控的基本任务是监控平台完成的业务交易和信息处理情况，控制业务差错，保障业务质量，为业务流程优化提供依据，提高业务运营能力和管理水平。

而业务交易和信息处理是以业务流程的方式进行的，因此将业务处理过程作为业务活动监控的视角，对关键业务进行深层次的信息整理和展现，将业务监控深入到业务过程内部，关注业务处理过程的细节，通过细节信息的展现，展示关键环节的业务处理状态，找出业务流程瓶颈，进而发现业务存在或潜在的问题，是业务活动监控的有效手段。

业务过程建模作为业务活动监控的实现基础，通过对关键业务流程的梳理，将关键的业务流程展开，确定业务处理过程的监控关键点，以业务处理过程的视角描述关键点之间的关系。

业务过程建模的主要工作为：

基于需求梳理的结果，根据功能综述、分类和规则，确定业务过程的关键点（即为业务过程的关键处理环节），定义关键点之间的关系，并绘制业务流程图，体现关键点间的过程与逻辑关系。

过程建模包含以下内容：

❑绘制业务流程图，从业务活动监控需求出发，根据需求梳理结果，将关注的业务关键点以流程图的方式进行关联，业务流程图包括业务总体流程、业务内部处理流程及关键点联动流程；

❑流程图中标出过程关键点，包含业务支撑及管理人员关心的业务监控点及相关处理过程节点，业务关键点的确定以监控需求及关联分析为出发点，不必求全求大。

图：

业务建模过程图

建立关键点与指标的关系

根据过程模型，遵照规范化思想建立关键点与业务指标之间的关联关系。

对于所抽取的业务过程关键点，抽取关键业务指标，如业务处理量、积压量、处理效率及业务准确性指标，抽取的关键业务指标能够对关键点的业务处理状态进行直观准确反映。

建立关键点与指标的关系包含以下内容：

●在每个关键流程点上，根据需求模型，抽取关键业务指标，指标包括基础的KPI指标和综合性的KPI指标，指标要落实在具体的关键点上；

●关键点指标的抽取从关键点本身的监控需求出发，也要兼顾关键点间的关联关系，考虑到对整个业务过程的监控分析需求；

●定义相关业务指标的采集周期、维度、采集方式、方法，从业务监控的需求和业务实际情况出发进行综合考虑，在尽量体现业务活动监控实时性要求的同时，也要充分评估对生产系统的影响。

图：

业务建模指标图

建立关键点间的关联关系

关键点间的关联关系包含某几个关键点间的关联关系、具体的关键点与整个业务过程的关联关系。

关键点间的关联关系，具体体现为不同关键点的同类指标间的关系，通过对关键点指标进行分类及规整，形成相关指标类，根据过程模型，并结合业务经验积累定义相关关键点同类指标的关联关系，进而建立关键点间的关联关系。

关键点间的关联关系是业务活动监控的分析要点，如某业务过程的关键点一的业务处理量和关键点二的业务处理量存在固定比值关系，某业务过程的关键点一的处理时长指标和关键点二的处理时长指标存在构成关系。

关键点与业务过程的关联关系具体体现为关键点业务指标与整个业务过程同类业务指标间的关系，通过对关键点业务指标的归并形成整个业务过程的关健业务指标，定义具体关键点指标与业务过程关键指标的关联关系，进而建立某一关键点与整个业务过程的关联关系。

如某业务过程的关键点1的处理时长指标和整