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

1、word完美格式IT系统统一监控预研报告精心整理学习帮手目录IT系统统一监控预研报告 11 引言 32 平台建设的目标 32.1 建立健全企业IT运行监测指标体系 32.2 完善公司业务监测指标体系，保障业务连续性 42.3 管理业务系统容量 53 平台架构 53. 1平台技术架构 53.1.1 采集层 63.1.2 处理层 63.1.3 展现层 63. 2平台功能架构 64 对新核心系统建设的要求 84. 1规范系统日志输出 84. 3提供服务持续可用性监控方法 95 结论 101引言随着信息系统规模持续扩大，业务应用的不断增加，服务用户对象的日益增 多，IT运维管理人员逐渐面临着三大难题：

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

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

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

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

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

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

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

9、统管理员可以分析系统 性能状况，并记录进事件管理平台。上述综合展示通过业务视图、逻辑拓扑、重 要设备、告警统计各个不同视图，将 运维管理工作所关注的内容有序、实时、全 面地呈现出信息系统资源和业务系统的整体运行状况。3. 2平台功能架构一体化IT运维监控模型基于松耦合体系架构，采取灵活模块化组装、云计算 灵活部署结构，实现“监控、管理、管控”三个方面协同处理过程，其功能架构 如下：统一访问门户通过一次登录，即可对所有的平台功能进行操作， 针对不同 的登录用户，可以提供专门的个人桌面和辅助工具。一一一一I集中Jft蛙理中心i1l 1 1 综/金分折 1 fl hi? ft itK就一门户t A摘

10、g申心j Ml石語it阳|人墀城采集理甲台计那*n助腹务任筹訝用11:n ftr I ft|斤j遐Jitft廿ca：Brrn监测台可以定义服务视图，将性能，流量，报表，拓扑等系统管理所关心的 信息在不同样式的视图上集中体现出来。运行服务平台以IT管理流程为核心，对运维的主要工作进行规范化的管理， 并实现设备维修、值班的管理。统一事件管理平台能够提供统一的企业级网络事件管理。通过从各种网络设 备和管理平台收集网络事件信息，并进行必要的分析和自动化处理工作。集成数据网管系统，提供数据网管标准接口以供信息交互，完成事件的统一 管理，使网络和系统中的各种资源得到更加高效的利用和综合管理。系统管理提供对

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

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

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

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

15、）从web页面对应用程序功能进行语义监控，比如“页面加载错误”、“ Error500 ”、” Error404 ”；b）对用户访问质量的监控，页面加载时常；c）对程序主逻辑进行监控，判断主逻辑是否正常；d）如果主逻辑正常，贝U对程序自身占用资源的合理性、程序的性能、和程 序的分支功能进行判断；e）另外对程序占用的资源情况进行监控：CPU资源的占用，内存资源的占 用，文件句柄的使用情况，网络句柄的使用情况，文件状态的进程数；f）服务的监控指标，数据加载的情况，模块的处理能力（平均耗时，队列长度，线程池的使用率），模块间通讯的状态（平均连接时间，读、写错 误数），模块运行时间；g）系统用户的操作习惯，完成功能模块操作的时长；4. 3提供服务持续可用性监控方法服务化是应用系统发展的方向，但服务的监控及问题的排查，一直困扰运维 人员，尤其是多层服务之间调用问题的排查是相当困难的（例如：服务调用 A-B-C-D,最终结果依次返回D-C-B-A，中间任何环节出现问题，结果都 返回不到A）。建议在新系统的建设过程中考虑提供服务的自测工具和监控方 法，服务的自测工具以便让运维人员进行手动的排查问题；监控方法，主要是将系统服务的监控纳入监控管理