| 为更好、更有效地保障系统上线后的稳定运行，对于信息系统设施中的硬件资源、性能、带宽、端口、进程、服务等都必须有一个可靠和可持续的监测策略和机制，需要明确定义监控的对象、方式，设定告警的优先级、标准等，具体策略包括以下内容。
|
|
|
| （1）监控对象：在一个规模较大的网络中，监控的对象可能包括服务器、防火墙、交换机、路由器等设备及运行在各对象上的服务，不需要将所有的对象都放到监控系统中，监控策略的设计首先应明确监控对象。
|
|
|
| （2）故障告警方式：对监控系统而言，一定要有合适的故障告警机制。目前常用的告警机制包括邮件、短信、MSN、Web页面显示等几种手段，这几种手段中，短信告警最佳。
|
|
|
| （3）告警时效和间隔的选择：由于网络通信等不可控因素，可能存在故障误报的情况，不应将告警发送设置成一次探测不成功就发送。此外，故障告警开始发送以后，在收到确认排除前会持续发送，因此需要合理设置告警发送的间隔。
|
|
|
| 告警时效和间隔的策略参考建议：探测4次失败开始告警，告警间隔10分钟，总共发送8次，然后停止发送，假如第3次没有人去处理，监控工具电话通知，没有回应则取消该对象的监控，并记录该次事件。
|
|
|
| （4）监控平台地点的选择：对于一个规模较大的网络，为解决南北互连问题一般会采取在多个地点建立数据中心的方法，这时需要对不同地理位置的服务器进行监控，也会遇到访问慢的问题。解决这个问题有几种方式：①选择一个到各个位置访问都顺畅的数据机房；②采取分布式监控平台，各处自己收集监控信息，然后到一处汇总；③各数据中心单独建立监控平台。
|
|
|
| （5）定义告警优先级策略：对于监控到的事件，通常将访问网页出错、连接不到Socket等故障设置为优先告警。此外，对返回的延时、内容的信息，如访问网页的时间、访问网页取到的内容及其他数据指标等，可自定义告警条件，如对Ping监控的返回延时一般是10～30ms，当延时大于100ms时，表示网络或者服务器可能出现问题，引起网络响应慢，需要立即检查是否有流量过大或者服务器CPU太高等问题；当监控到磁盘空间超过一个阈值时，可能会引起数据库损坏，服务响应变慢等问题，需要告警进行检查和处理。
|
|
|
| （6）定义告警信息内容标准：当服务器或应用发生故障时告警信息内容非常多，如告警运行业务名称、服务器IP、监控的线路、监控的服务错误级别、出错信息、发生时间等。预先定义告警内容及标准能使收到的告警内容具有规范性及可读性。这一点对于用短信接收告警内容特别有意义，短信内容最多是70个字符，要用70个字符完全明确故障内容比较困难，更需要预先定义内容规范。例如，“视频直播服务器10.0.211.65在2012-10-1813：00电信线路监控到第1次失败”，清晰明了地告知故障信息。
|
|
|
| （7）通过邮件接收汇总报表：设计固定周期收到网站服务器监控的汇总报表邮件，运维人员只需花很少的时间就能大致了解网站和服务器状态。
|
|
|
| （8）定义故障告警主次：对于监控同一台服务器的服务，需要定义一个主要监控对象，当主要监控对象出现故障时，只发送主要监控对象的告警，其他次要的监控对象暂停监控和告警。例如，用Ping来做主要监控对象，如果Ping不通出现Timeout，表示服务器已经宕机或者断网，这时只发送服务器Ping告警并持续监控Ping，因为再继续监控和告警其他服务已经没有必要。这样既能大大减少告警消息数量，又可以让监控更加合理、更加有效率。
|
|
|
| （9）规范本地部署的监控脚本，并归纳总结：对在本地部署的监控脚本要进行统一规范的部署并记录到知识管理系统中以便沉淀及优化。
|
|
|
| （10）实现对常见性故障业务自我修复功能：实现对常见性故障业务自我修复功能脚本进行统一部署，并对修复后的故障进行检查，一般告警检查频次不多于3次。
|
|
|
| （11）对监控的业务系统进行分级：如设置类似“一级系统7×24小时告警，二级系统7×12小时告警，三级系统5×8小时告警”这样的业务系统分级标准。
|
|
|
京公网安备 11010502032051号 | 营业执照