告别“救火式”IT运维时代，如何打造高效运维监控系统？

我们常说，IT运维人员要有危机意识，明白有可能出现哪些问题，出现这些问题后该如何去迅速处理。

下面我们就针对如何做好系统运维的监控工作，提出几点建议：

一、上线之前的准备工作

1、首先是备份，做好定时备份策略，备份所有你认为重要的数据，并且定期检查你的备份是否有效、全面;

2、日志轮换，无论你想用哪种轮换方式，控制日志增长避免驱动器已满是你的目的;

3、做一定的安全措施，如防火墙iptables的访问控制，用denyhosts防止黑客远程暴力破解;4、mysql远程登录权限等等;

5、最后就是服务器、网元设备的监控。

二、监控策略

1、定义告警优先级策略

一般的监控到的结果是成功或者失败，如Ping不通、访问网页出错、连接不到Socket，发生时这些称之为故障，故障是最优先的告警。除此之外，还能监控到返回的延时、内容等，如Ping返回的延时、访问网页的时间、访问网页取到的内容等。

利用返回的结果可以自定义告警条件，如Ping监控的返回延时一般是10-30ms之间，当延时大于100ms时候，表示网络或者服务器可能出现问题，引起网络响应慢，需要立即检查是否流量过大或者服务器CPU太高等问题。

2、定义告警信息内容标准

当服务器或应用发生故障时告警信息内容非常多，如告警运行业务名称、服务器IP、监控的线路、监控的服务错误级别、出错信息、发生时间等。

预先定义告警内容及标准使收到的告警内容具有规范性及可读性。这点对于用短信接受告警内容特别有意义，短信内容最多是70个字符，要在70个字符完全知道故障内容比较困难，更需要预先定义内容规范。如：“视频直播服务器10.0.211.65在2012-10-18 13:00电信线路监控第到1次失败”，清晰明了的知道故障信息。

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

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

4、 集中监控和分布式监控相结合

主动(集中)监控虽然能不需要安装代码和程序，非常安全和方便，但缺少很多细致的监控内容，如无法获取硬盘大小、CPU的使用率、网络的流量等，这些监控内容非常有用，如CPU太高表示有网站或者程序出问题，流量太高表示可能被攻击等。

被动(分布式)监控常用的是SNMP(简单网络管理协议)，通过SNMP能监控到大部分你感兴趣的内容。大部分操作系统支持SNMP，开通管理非常方便，也非常安全。SNMP缺点是比较占用带宽，会消耗一定的CPU和内存，在CPU太高和网络流量大情况下，无法有效进行监控。

5、定义故障告警主次

对于监控同一台服务器的服务，需要定义一个主要监控对象，当主要监控对象出现故障，只发送主要监控对象的告警，其它次要的监控对象暂停监控和告警。

例如用Ping来做主要监控对象，如果Ping不通出现Timeout，表示服务器已经当机或者断网，这时只发送服务器Ping告警持续监控Ping，因为再继续监控和告警其它服务已经没有必要。这样能大大减少告警消息数量，又让监控更加合理、更加有效率。

6、本地监控脚本的规范化部署

对在本地部署的监控脚本要进行统一规范的部署并记录到KM系统。

7、实现对常见性故障业务自我修复功能

实现对常见性故障业务自我修复功能脚本进行统一部署并对修复后故障进行检查告警检查频次不多于3次。

8、对监控的业务系统进行分级

一级系统实现7*24小时告警，二级系统实现7*12小时告警，三级系统实现5*8小时告警。

9、 监控范围及目标

实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理;

同时自动收集、过滤、关联和分析各种管理功能产生的故障事件，实现对故障的提前预警和快速定位;

对网络和业务应用等IT资源的性能进行监控，定期提供性能报表和趋势报表，为性能优化及未来系统扩容提供科学依据。

通常情况下，我们可以将监控对象这么来分：

服务器监控，主要监控服务器如：CPU 负载、内存使用率、磁盘使用率、登陆用户数、进程状态、网卡状态等。

应用程序监控，主要监控该应用程序的服务状态，吞吐量和响应时间，因为不同应用需要监控的对象不同，这里不一一列举。

数据库监控，只所以把数据库监控单独列出来，足以说明它的重要性，一般监控数据库状态，数据库表或者表空间的使用情况，是否有死锁，错误日志，性能信息等等。

网络监控，主要监控当前的网络状况，网络流量等。