IT系统监控方案设计

 一、平台建设背景

随着业务发展，公司业务系统逐渐增多，线上系统的数量也在不断增加，依靠过去人工巡检系统的方式发现系统故障、潜在风险及安全隐患的方式效率越来越低下且运维人员的工作强度及压力也在不断增加，为了提高发现系统故障的及时性、系统维护的专业性、规范化、科学性同时也能把运维人员从重复的工作中解放出来去做更多有意义的事情，因此我们亟需引入新的监控手段、工具来协助运维工程师解决当前的问题。

二、建设目标

为保证自有软件平台运行稳定性，对线上平台进行自动化监控，合理设置监控粒度及监控对象。尽可能的把潜在问题在萌芽状态解决及消除隐患，以此提高IT技术支持部门的整体集成能力和交付系统运行质量。

建设监控平台的终极目标如下所示：

1. 及时发现潜在的问题化被动为主动维护；

2. 为平台性能优化提供直观参考依据；

3. 提高系统维护的专业性和规范性；

4. 提高用户体验，降低服务宕机时间。

三、监控平台功能与内容

1、集中监控管理

负责收集和处理来自系统中的各类告警信息，并进行告警信息的汇聚和根源分析，帮助运维人员找出故障发生的原因，快速定位故障点并包含网络、主机、数据库及应用管理（系统软硬件配置信息、系统性能指标、故障告警和日志管理）。

具体实现：对于日志的归档工作采用本地shell及信息收集引擎的方式将系统信息及异常日志集中存储到监控平台做分析并进行告警、生成报表等工作。

2、统一监控管理界面和多样的告警方式

 通过布局合理的图形化界面集中反映网络、系统、数据库和应用的实时状态，通过手机短信、邮件以及页面等多种方式进行告警。

3、自定义告警优先级策略

一般的监控到的结果是成功或者失败，如Ping不通、访问网页出错、连接不到Socket，发生时这些称之为故障，故障是最优先的告警。除此之外，还能监控到返回的延时、内容等，如Ping返回的延时、访问网页的时间、访问网页取到的内容等。利用返回的结果可以自定义告警条件，如Ping监控的返回延时一般是10-30ms之间，当延时大于100ms时候，表示网络或者服务器可能出现问题，引起网络响应慢，需要立即检查是否流量过大或者服务器CPU太高等问题。

4、自定义告警信息内容标准

当服务器或应用发生故障时告警信息内容非常多，如告警运行业务名称、服务器IP、监控的线路、监控的服务错误级别、出错信息、发生时间等。预先定义告警内容及标准使收到的告警内容具有规范性及可读性。这点对于用短信接受告警内容特别有意义，短信内容最多是70个字符，要在70个字符完全知道故障内容比较困难，更需要预先定义内容规范。如：“视频直播服务器10.0.211.65 在2012-10-18 13:00电信线路监控第到1次失败”，清晰明了的知道故障原因。

5、短信告警功能

目前平台可以实现按照不同业务、责任人通过139邮箱告警功能自动发送告警短消息到相应运维工程师手机之上。

同时可以实现调用第三方API方式进行系统告警功能，第三方API只需须留有手机号码，短信内容变量即可完成短信的即时发送功能。

6、通过邮件接收汇总报表

实现每天收到一封网站服务器监控的汇总报表邮件，花两三分钟总体了解网站和服务器的状态。

7、监控管理标准

实现对网络运行状态、系统服务质量和故障告警等的实时监控管理。

8、丰富的数据报表分析功能

 结合上述的各项功能，系统能够根据工作需要产生标准格式报表,并能够按条件生成和调整各类报表，以满足IT系统管理及审计等多种需求。

四、平台监控对象

编号	类型	监控范围	备注
1	网络	交换、路由、F5	网络设备性能参数指标、性能指标超限告警
2	主机	Linux、Windows	监视服务器性能参数指标、性能指标超限告警
3	中间件	Nginx、Tomcat	监视中间件性能参数指标、性能指标超限告警
4	流媒体	Wowza、Nginx	监视流媒体性能参数指标、性能指标超限告警
5	数据库	MySQL	监视数据库性能参数指标、性能指标超限告警

五、平台架构设计

1、平台架构逻辑拓扑

平台设计架构如下图5.1所示

           

平台采用统一监控，集中展现的方式实现对设备的监控。监控服务器通过部署在各监控对象上的引擎收集信息，通过报表服务器进行过滤、加工、整理，通过统一门户进行展现及短信告警功能。

2、可用性原则

 监控管理软件的部署不应对原有的系统结构、安全策略等方面做较大修改和调整，对原有系统性能影响最小化，不能对生产系统自身的运行造成不良影响，不能干扰系统的正常运行；尽量少的占用消耗原系统的资源、网络资源。