• 保存到桌面  加入收藏  设为首页
IDC话题

从100台以下到1000+台服务器的运维思路变迁

时间:2017-08-17 11:12:11   作者:顾凯   来源:精硕科技   阅读:79   评论:0
内容摘要:常说一千个人心中有一千个哈姆雷特,一千个运维的心中有一千种运维的方法,没有一个方法是万能的、可以适用所有的场景,具体问题还得具体分析,我将这五年的经历大致分了三个阶段:
        从几十台到几千台服务器的运维过程中,监控系统的变迁经历。常说一千个人心中有一千个哈姆雷特,一千个运维的心中有一千种运维的方法,没有一个方法是万能的、可以适用所有的场景,具体问题还得具体分析,我将这五年的经历大致分了三个阶段:
第一阶段:200台以下
第二阶段:200~1000台
第三阶段:1000+(1000以上和2000以上没啥区别了)
每个阶段的分界点也不是那么精确的,就是一个大概的时期,变化都是一个逐渐的过程。

一、 机器数量小于200台的阶段


        这个时期需求简单,主要用于通知问题、快速定位解决问题,大致总结一下,主要需求就三点:
        1. 简单,易用;
        2. 稳定运行;

        3. 能够报警,邮件,短信。


        基于以上需求,可以使用比较流行开源的监控软件Nagios,Cacti,Zabbix,Ganglia,etc。流行的开源产品有较多的文档,可快速上手,并且有大量的前人使用经验,可以避免许多问题,即使遇到问题也容易找到解决办法。其中邮件报警一般是都支持的,短信需要自己对接一下短信平台。
 
        我们在早期的时候选择了Nagios和Cacti,选择Nagios主要是个人原因,我最熟悉,使用Cacti是因为对交换机的监控特别方便,几乎是傻瓜式的。其实在这个阶段,不管是哪一个监控产品,基本都可以满足需求,选择的因素还是看个人喜好,这个时期运维同学是可以偶尔任性一下的。

二、机器数量200到1000的阶段
 
        这个时期,需求开始变得复杂,不过主要还是用于通知、告警,避免同样的问题再次发生,我在这个时期主要做了以下事情:
 
        1. 统一监控内容:将基础监控进行统一,默认每个机器都包含CPU,内存,磁盘空间等基础信息监控;
 
        2. 覆盖式监控:将所有机器均纳入监控,除去基础监控以外,最重要的当属业务监控,尽可能的覆盖业务流程,通过自定义监控减少和去除重复的问题,保障业务稳定运行。
 
        3. 及时通知,确保无漏报:将所有监控分类,根据重要程度、紧急程度等,分别用邮件,微信,短信,电话等不同级别的方式通知,确保每个监控都有人处理,并且对于重要的业务采用call死你的方式,不处理就一直通知。
        在这个时期对Nagios进行了深入的研究,编写自定义脚本、大量增加各种监控项,将Nagios大部分的插件如nrpe、nsca和功能充分使用。
 
        随着机器越来越多,需要监控的服务也越来越多,告警信息出现爆发式增长,每天收到上千封报警邮件。有个小插曲,我应该是第一个将腾讯企业邮箱撑爆的人,不是容量撑爆了,是邮件的数量超过了他们数据库的最大值,导致我在一周内没办法收发邮件,也没办法删除。
 
        这个阶段的后期,也就是快接近1000台机器的时候,Nagios的监控功能已经无法满足需求了,并且Nagios图形功能总是捉襟见肘,于是开始思考超过1000台的情况了,摆在面前的路有两条:
        1. 根据自己的需求继续深度开发Nagios;

        2. 自建监控。


        这时候有些朋友会想:换一个别的开源监控就能解决了。使用开源软件的最大问题就是,这个软件有什么功能你才能用什么功能,没有的功能要么自己开发,要么放弃使用,大量报警只是一个改变的转折点,经过长时间的使用和积累,通用的、普适的开源监控产品已经不能完全满足庞大复杂的需求了。
 
        经过很长一段时间的慎重考虑,我决定自己搞一套监控系统,其实也是因为之前深入了解Nagios的整体架构和运作模式,觉得自己做一套也不是不可能的。

三、机器数量超过1000台的阶段


        经过前期的思索和准备,到这个阶段开始开发自己的监控系统,解决痛点,完成需求,主要有几个事情:

        1. 具备目前在用的Nagios所有功能:比照Nagios去做,覆盖原来的功能,并针对Nagios的问题进行优化改进,然后在替代了Nagios之后再升级。(第一步最重要了,如果连之前的Nagios的功能都不能替代,自建之路只能在这里就停下了。)
 
         2. 将告警进行整理,化繁为简,减少重复告警:当出现轰炸式告警信息之后,如果不进行及时整理势必会将真正需要处理的事情耽误,并且由于某些原因,比如线路问题,会发生重复告警,所以必需要将告警信息进行处理再发出,预警信息由之前的每天3000+,下降到现在每天300以内。

         3. 分离告警和显示:前面的监控系统,基本上告警功能和显示功能均在一起,不同机房的信息也需要汇总在中心节点后统一显示和告警。重要的告警的处理是分秒必争的,也跟界面显示无关,所以我在设计的时候将显示和告警功能进行了一次分离,在本地机房进行报警,然后再集中展示。
 
          4. 分布式部署,避免单点:每个机房设置一个分节点,就是上面说的报警节点,设置一个中心节点,先在各个机房告警,然后汇总在中心展示。分节点与中心节点互备,通过智能DNS进行切换,如中心节点宕机,DNS自动切换到一个分中心节点,分节点升级为中心节点。
分布式节点切换示意图从100台以下到1000+台服务器的运维思路变迁


IDCsped 提供最新的IT互联网资讯,本着分享传播的宗旨,我们希望能帮助更多人了解需要的信息!

部分文章转载自互联网、部分是IDCsped原创文章,如果转载,请注明出处:www.idcsped.com !
微信号:13430280788  欢迎加微信交流!

标签:运维1000台服务器    
相关评论

销售电话:13760852008

Copyright © 2012-2017 | www.idcsped.com 版权所有

  湘ICP备12006439号