智能化运维之IT系统统一监控预研报告

1、IT 系统统一监控预研报告目录IT 系统统一监控预研报告 11 引言 32 平台建设的目标 32.1 建立健全企业 IT 运行监测指标体系 32.2 完善公司业务监测指标体系，保障业务连续性 42.3 管理业务系统容量 53 平台架构 53 1 平台技术架构 5采集层 6处理层 63.1.3 展现层 63 2 平台功能架构 74 对新核心系统建设的要求 84 1 规范系统日志输出 84 3 提供服务持续可用性监控方法 105 结论 111引言随着信息系统规模持续扩大，业务应用的不断增加，服务用户对象的日益增 多，IT运维管理人员逐渐面临着三大难题：(1) 设备和业务种类繁多，各类资料信息分散，

2、导致位于一线的IT运维监 控人员感知故障的速度晚于信息系统的使用用户，且故障发生后缺乏对信息系统 的整体把控；而后台管理人员也往往因为信息系统 性能数据和故障数据的匮乏而 缺少对系统运行健康度的了解。(2) 核心机房可能分布于多个地点，部署范围广泛，设备繁杂，对于大批最 网络设备、主机服务器、应用系统没有一个统一的监控平台，不能制定统一的故 障预警管理策略，故障预警效率低，业务恢复时间慢 ；(3) 对关键核心业务系统的运行健康程度缺乏评估手段和预警措施，只能被动等待问题发生，无法提前采取技术手段和管理手段规避问题。在此背景下，总分公司一线运维人员数量多但是经验不足，后台运维工程师经验丰富但是数

3、量少，这些矛盾促使我司在新系统建设时需同步建设一套一体化 的IT运维监控和服务预警平台，协助以自动化的手段完成信息系统的监测和维 护。2平台建设的目标2.1建立健全企业IT运行监测指标体系首先，平台的主要目标是加大对公司内部各遗留及专有监控系统的整合力 度，提高IT运控中心对公司内其他分支机构IT系统管理、检测和把控能力，建 立并完善IT系统监控、IT运行事件响应、IT系统故障处理、IT健康度报告、IT 运行问题跟踪和反馈机制，引人自动化IT运维管理工具，从而在公司内部建立 健全运行管理控制能力，实现IT健康度和业务连续性治理。在此基础上，进一步优化监控策略，实现对设备及服务项全面、细粒度的监

4、 测，预警和管理，主要包含以下方面：（1）打造多平台环境下安全稳定髙效的检测代理及检测工具 ；（2 ）在实现对各类业务系统、硬件和网络设备、机房环境等实时检测的基 础上，完善对新核心系统的全流程监控， 根据性能数据进行预警，并将性能数据 和故障数据引入事件管理平台进行后续治理，以可视化的方式向运维人员提供一 览式的IT服务健康状况视图；（3）构建集成监控平台，对平台的检测插件、检测机制、预警算法、视图 展现等监控资源进行统一管理，实现大屏集中式告警，便于后台管理人员直观地 看到系统整体健康程度；通过视图的灵活组合可以快速定位故障点，结合知识库 缩短处理时间。因此，IT运维自动化是一组将静态的设

5、备结构转化为根据 IT服务需求动态 弹性响应的策略，目的就是实现IT运维的质量，降低成本。2.2完善公司业务监测指标体系，保障业务连续性随着公司信息化的发展，IT技术已经从业务支持逐步走向与业务的融合，并成为公司稳健运营和发展的支柱。公司内部很多业务流程都已经在IT部门的支持下实现了流程的再造和优化，提炼并制定了相应的流程图、流程文件及流程 运作机制。但是目前我们对于公司内部业务风险的管控尚处在初步阶段 。各类业 务流程依然面临着来自内部和外部的各种业务风险。例如内部业务风险主要来自于员工和服务商对信息系统的不当应用，如非授权操作或误操作；外部业务风险 主要来自于外部的不安全事件，如黑客攻击、

6、机房环境变化等。对应用系统进行 业务监控，能够及时识别业务风险，有效进行相应的主动规避操作， 避免造成损 失。2.3管理业务系统容量通过业务监控平台可以密切监控业务系统性能，包括系统的业务处理量、处 理性能、各资源使用状况等，通过对系统资源瓶颈的分析，可以降低或提高业务 系统容量；3平台架构3 .1平台技术架构运维平台能够对各类计算机设备、网络设备、安全产品、应用系统等IT设备运行状况和各种网上行为 进行集中监控，对各类设备进行 全面集中的统一管 理，及时发现各类异常情况、快速定位各类事件故障并 自动形成“工单”、自动 分派，再由调度系统进行分派，由系统按预定流程规则进行自动化处理或人工处 理

7、的运维业务信息管理系统。使运维工作由被动变主动，由手动处理变成自动处 理，并大大降低了运维人员的工作强度，具备良好的延展性，如下图所示：羽妇M析1如上图所示，一体化运维监控平台的系统整体框架由下及上划分为 3层数据 采集息（采集层）、数据处理层（处理层）和数据使用层（展现层）。此外，通过平 台的管理控制台，在各个层面都能够对平台进行全方位的配置管理。采集层采集层主要负责采集信息系统的性能数据和故障数据，通过在信息系统服务 器上部署Age nt,或者通过SNMP协议采集等多种方式与外围系统对接， 获取所 述基础数据。采集层被动地接收平台服务器发出的采集指令，执行相关的信息采 集插件，将采集到的数

8、据放人队列和数据库中，便于后续的分析和数据挖掘。处理层数据处理层根据不同监控对象的自身特点和运维管理需要，灵活定制相应的 性能指标集，定义所述性能指标集中每个指标的监测范围、数据来源 ，计算方法、 预警阈值、测量频度参数，通过实时和历史性能图表，进行监测、分析和确定系 统性能瓶颈，若超过预警阈值的状况，自动建立事件，并通知运维人员，由调度 系统进行指派，由运维人员手动处理或按照流程规则由自动化运维工具处理。展现层展现层分信息系统全局视图、系统健康度巡检报表、检测数据査询三个部分。 全局视图可以展现实时监视告警情况，利用巡检报表，系统管理员可以分析系统 性能状况，并记录进事件管理平台。上述综合展

9、示通过业务视图、逻辑拓扑、重 要设备、告警统计各个不同视图，将 运维管理工作所关注的内容有序、实时、全 面地呈现出信息系统资源和业务系统的整体运行状况 。3 . 2平台功能架构一体化IT运维监控模型基于松耦合体系架构，采取灵活模块化组装、云计算 灵活部署结构，实现“监控、管理、管控”三个方面协同处理过程，其功能架构 如下：统一访问门户通过一次登录，即可对所有的平台功能进行操作， 针对不同 的登录用户，可以提供专门的个人桌面和辅助工具。蜒一门户f Ki (Hr1転KlTlftW帚萍書4(L#«fll H -?«% 儘曲潇fl <V-ITJI1F检 n jiPrrttFf

10、nttEK#-_- 一二K-ft 科 H fl!%»*»平會flwftnIJtt札卷蛍舟就ftI'y.nfT橄H监测台可以定义服务视图，将性能，流量，报表，拓扑等系统管理所关心的 信息在不同样式的视图上集中体现出来。运行服务平台以IT管理流程为核心，对运维的主要工作进行规范化的管理 并实现设备维修、值班的管理统一事件管理平台能够提供统一的企业级网络事件管理。通过从各种网络设 备和管理平台收集网络事件信息，并进行必要的分析和自动化处理工作。集成数据网管系统，提供数据网管标准接口以供信息交互，完成事件的统一 管理，使网络和系统中的各种资源得到更加高效的利用和综合管理。系

11、统管理提供对服务器、存储设备、操作系统、数据库、中间件、综合管理, 实现系统故障告警管理、系统性能管理、拓扑与配置管理。接收来自防火墙、人侵检测、端口扫描等安全系统的告警，并将这些告警实 时呈现给信息网络安全部门，以采取进一步的响应动作，保障网络系统的正常运 行，并对网络流量进行监听和分析。4对新核心系统建设的要求4 . 1规范系统日志输出目前核心业务系统的日志输出没有统一的规范，有些日志采用Iog4j进行输 出，有些直接在系统中采用 System.out在nohup.out文件中进行输出，给运 维监控分析排查问题带来较大的困难，建议在新系统的建设过程中，统一规范日志的输出：(1)规范日志信息

12、级别日志信息输出的优先级从高到低至少应分为五档，分别是Fatal、ERROR、WARN、INFO、DEBUG。这些级别用来指定这条日志信息的重要程度。在测试阶段可以打开所有级别的日志，系统上线后只允许输出INFO以上级别(含INFO ）。各级别的日志信息作用如下 ：致命（ Fatal ）严重的错误，系统无法正常运行，如硬盘空间满等。这 个级别很少被用，常暗含系统或者系统的组件迫近崩溃。错误（ Error ） 系统可以继续运行，但最好要尽快修复的错误。这个级 别用的较多 ，常常伴随 Java 异常，错误 （Error） 的环境不一定会造成系统的崩溃， 系统可以继续服务接下来的请求。警告（ War

13、n ）系统可以正常运行，但需要引起注意的警告信息。这个 级别预示较小的问题，由系统外部的因素造成的，比如用户输入了不符合条件的 参数。信息（ Info ） 系统运行的主要关键时点的操作信息，一般用于记录业务 日志。但同时，也应该有足够的信息以保证可以记录再现缺陷的路径。这个级别 记录了系统日常运转中有意义的事件。调试（ Debug ）系统运行中的调试信息，便于开发人员进行错误分析 和修正，一般用于程序日志，关心程序操作 （细粒度 ），不太关心业务操作 （粗粒 度）。系统出现问题时，必须抛出异常，在处理异常时记录日志，且日志级别必 须是前三个级别（ FatalErrorWarning ） 中的一

14、种。（2） 日志中除包含错误信息外，还需包含如下信息：a）Web 应用系统发生异常时， 日志信息中需包含， 系统操作用户的信息， 发生异常时的业务数据、系统功能、程序代码信息及完整的 SQL 语句；b）接口类服务发生异常时，日志信息中需包含，接口调用的URL，调用端和被调用端的实地址，交互报文，报文的检查结果，接口响应时常；c）在日志中，记录关键程序和数据库交易的处理时长， 并根据事先预定的 阈值，在日志中以醒目的方式完整的显示超过阈值的程序代码的方法名 或 SQL 语句，以便运维监控人员分析，排查性能隐患。4 2 预留应用系统监控接口，便于监控系统采集相关指标 在核心的建设过程中， 需预留监

15、控接口， 应用监控系统通过调用核心系统的 监控接口，来采集包括但不限于以下指标：a） 从 web 页面对应用程序功能进行语义监控，比如“页面加载错误”、 “Error500 ” 、” Error404 ；”b ）对用户访问质量的监控，页面加载时常；c）对程序主逻辑进行监控，判断主逻辑是否正常；d ） 如果主逻辑正常，则对程序自身占用资源的合理性、程序的性能、和程 序的分支功能进行判断；e）另外对程序占用的资源情况进行监控 :CPU 资源的占用，内存资源的占 用，文件句柄的使用情况，网络句柄的使用情况，文件状态的进程数；f）服务的监控指标，数据加载的情况，模块的处理能力（平均耗时，队列 长度，线

16、程池的使用率），模块间通讯的状态 （平均连接时间，读、写错 误数 ），模块运行时间；g ） 系统用户的操作习惯，完成功能模块操作的时长；4 3 提供服务持续可用性监控方法服务化是应用系统发展的方向， 但服务的监控及问题的排查， 一直困扰运维 人员，尤其是多层服务之间调用问题的排查是相当困难的（例如：服务调用A->B->C->D ，最终结果依次返回 D->C->B->A ，中间任何环节出现问题， 结 果都返回不到 A ）。建议在新系统的建设过程中考虑提供服务的自测工具和监控 方法，服务的自测工具以便让运维人员进行手动的排查问题； 监控方法，主要 是将系统服务的监控纳入监控管