服务器监控策略浅谈

服务器监控策略浅谈 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

作者：田逸（ [email]sery@163.com[/email] ）from《网管员世界》2008年第10期

 

记得数年前刚开始做服务器管理的时候 , 就遇上主机托管机房出问题 , 不能为我们放置的服务器提供有效的带宽 . 当时不知道实际情况 , 就不断地打电话过去问 , 服务商老是拿被***来敷衍用户 , 说一会就正常了 . 于是我就在办公室一遍又一遍的刷新网页 ,ping 服务器 ip. 现在想起来 , 真是笨死了 . 后来 , 随着监控平台的完善和部署 , 管理服务器对于我们说就容易多了 . 一个监控平台就相当于多了一双眼睛 , 而且是全天候的 , 相信有不少服务器管理人员从中受益 . 前几天 , 跟人在 qq 群交流监控的话题 , 其中一人云 : “晚上没完没了的收到监控系统的发送的报警短信，受不了 …” 。不言而喻，这是一个不好的监控措施，实际上监控已经失去了它的意义。

 

监控平台有了，还得有好的策略，才能让它发挥巨大的作用。本人从事服务器管理多年，也毫无疑问的使用监控平台来作为一种管理工具，让我的管理工作既直观又轻松。在这里基于我过去的经验，简单的讨论一下监控策略，权当抛砖引玉，希行家指正。

 

策略一：监控对象选择

在一个规模较大的网络中，监控的对象可能包括服务器、防火墙、交换机、路由器等等设备，以及运行在各对象上的服务。但是，我们没必要把所有的对象都放到这个监控系统中来。比如把某些测试系统放到监控中，就会产生如上那位老兄整个晚上收到报警短信的麻烦。因此，选择正确的监控对象是实施有效监控的前提，个人建议，只有那些重要级别高的，不能随便停止服务的对象――如在线交易系统――才是值得监控的对象。当然，服务器的使用者总希望你把它监控上，哪怕它不是那么重要。

 

策略二：故障报警方式选择

老板非常希望我们不知疲倦的坐在计算机旁，但是他只是一厢情愿而已。对监控系统而言，一定要有合适的故障告警机制。目前常用的告警机制包括：邮件、短信、 msn 、 web 页面显示等几种手段，这几种手段中，短信报警最佳。因为在夜间睡梦中，我们没办法随时收邮件，但是短信去能唤醒我们，通知我们发生故障了，而且在老板和用户发现这个故障以前。对于没有通道的机构来说，租用ｓｐ提供的服务是比较稳妥的方式，其他如用移动飞信等方式都不怎么考谱，不适合关键性业务运营。另外我使用了一个小技巧，让监控平台每天下午给我发一条短信，不管有没有故障都发，这样以便让我知道短信接口是否正常。

 

策略三：故障报警时效和间隔的选择

由于网络通信等不可控因素，因此可能存在故障误报的情况。如果把报警发送设置成一次探测不成功就发送报警信息就不是个好策略。经验表明：探测３－４次都失败再发送信息，并不耽误我们去处理故障。假如探测一次失败就报警，即可以很快把手机短信空间塞满，又会让你睡不好觉。

故障报警开始发送以后，一般会没完没了的发送，直到故障排除恢复正常，才会发一条类似“ *** is ok! ”的短信。报警发送间隔设置，也是需要费一番心思，设短了，不停的消耗你的短信费用，设长了，恐怕不足以唤醒沉睡的人；如果没有人去处理故障，也没有人去停止这个通知，报警信息就会一直发送下去。

那怎么样是一个合适的范围呢？我的做法是：探测４次失败开始报警，报警间隔１０分钟，总共发送８次，然后停止发送，假如第３次没有人去处理，我会电话通知，没回应则取消该对象的监控，并记录该次事件。

策略四：监控平台地点的选择

对于一个规模比较大的网络，为了解决南北互联问题而采取多个地点建立数据中心的办法。这时需要对不同地理位置的服务器进行监控，也会遇到访问慢的问题。解决这个问题有几种方式：１、选择一个到各个位置访问都顺畅的数据机房；２、采取分步是监控平台，各处自己收集监控信息，然后到一处汇总；３、各数据中心单独建监控平台。各人可以根据自己的实际情况自行选择。

 

策略五：流量控制和安全

有不少商业解决方案采取 snmp 和客户端软件来监控各个对象，这会引起额外的流量和带来安全问题。因此尽量不要使用 snmp 这样比较占资源的协议（具称 snmp v3 似乎有所改进）。开源解决方案 Nagios 在这方面做得比较完美，值得推荐一下。它可以以插件方式先收集到各监控对象的信息，然后再传送到监控服务器上，大大节省网络带宽。