十万级服务器监控系统开发架构

十万级服务器监控系统开发架构

十万级服务器监控系统开发架构
发布时间:2017-05-13 来源:济南网站建设

济南企业网站建设公司为您分享《十万级服务器监控系统开发架构》。

  1、 监控系统架构

  阅历了很多公司,监控系统大概都是从无到有,该阅历的也都阅历了。所谓监控系统,大概的架构如下:

  ◆在服务器布置一个Agent,它负责收集数据;

  ◆由网上转发到一个散布式管道再转接,就像搭积木一样;

  ◆进行汇总;之后把监控数据分两个部分

  ●一是数据库存储,次要做监控数据显现和后续排盘考题。

  ●二是制定患上多的监控的报警项。

  做一些简略的,像CPU跨越90%就会报警;另有一些庞大的,像60秒以内跨越两次。厥后也会支持一些集群类的报警监控。这个模块也是很简略,它次要便是在若干的文件的公式,然落后行监控数据的判断,判断之后发现了极度,就会产生一些新闻,然后上一个模块。我们只是进行判断,不进行报警。之后会有一个模块进行各种后端的报警,像而今一些公司 有微信报警、短信报警等等的,都在这部分支持。

  ◆存储部分

  豆瓣、百度、360等等,后端琐碎的事比较多,但是也有用MySQL的。实践上这部分也很简略,可以认为是一个散布式的Linux,便是把一些数据往文件数据库里传,上面是一个WEB端。以上是大概架构。

  2、 设计思路

  ◆每个模块就干一件事,把这件事干患上精致和优良。

  ●之后会细化一下模块里的详细内容。

  ●要scalable,flexible,可以恣意横向扩展,适应各种防火墙ACL。

  ●在360的时辰机房比较多,各种防火墙的ACL极度多,360下另有患上多子公司,会出现各种走访的征象。要适应各种系统,就会通过一些模块来适应。

  ◆正视代码复用。

  一套系统除去网络框架,每个模块的代码都在100行,并且是C语言写的。我们最后把这个网络框架都做在了一个网络库,这个是多线程的。

  3、 这个系统面对甚么难点?

  技巧量。

  就艺龙而言而今系统范围较小,天天产生160GB,360是500GB/天,百度离开太久了就不清楚了。这个数据量照样稍微比较大的,便是这个系统是工钱造的DDoS系统,每个监控端收集项目,我们在艺龙比较少,这种比较少,每个服务器上监控项大概二百多个,默认的频率是5秒钟一次的收集点。可以说每秒钟大概有40多条数据的收集。

  这个系统根本上不克不及做Cache,必需实时运算。由于服务器监控系统,我们做服务端应当都晓得,延迟报警,还不如不报。报警一旦出了题目,就要尽可能快的把这个东西报进去。除非是一些弗成控的要素,如短信网关,或运营商短信发送延迟等。结论是,90%都要在15秒以内保障人人手机能收到。这对我们在各种关键下尽管即便减少各种各样的延迟甚么的提出较高的要求,换言之,高可用。这种监测系统作为一种服务器的根底架构存在,可用性必需比线上高,由于它施展最大作用的时辰都是公司出了大题目标时辰,这个时辰必必要扛的住各种各样的网络环境,把实在的环境反馈之前。关于这种线上的可用性要求高于线上服务最多一个数目级。像CPU延续5次90%不报警,要是我们这个数据里有任何丢点,可能会招致报警报不进去。是以关于数据的完全性要求也是比较高的。便是在任何一个模块宕机或网络隔离,这种环境下也不允许出现任何的损失。

  高吞吐。

  由于这个系统是典型的写的比较多,读极度极度随机的过程。读取决于人人对数据项的检讨,汇总,绘图的需求。所以根本上一个月以内的数据必要随时的调进去。高吞吐也是我们面对的次要题目。

  多平台。

  百度用的是Linux,Windows用的比较少。百度的挑战在于机器比较多,像千分之一的环境在百度根本天天能出个一百台。之前我们共事做过一个分享,便是说一些经验。在服务器吞吐量尤其大的时辰,千分之一的环境也要斟酌。360是FreeBSD。艺龙是Windows,或许占服务器的一半。

  4、处理筹划

  针对数据量,HBase,自定义协议减少Overhead。数据量这个题目不大,用的技巧在于说,监控数据的传输,依据一些私有的协议,也是一些历史缘故原由,那时用Json患上多。也实验过用别的,但是对监控系统偶然辰,比方出丢点,像追的时辰Json可以,用别的就追不上了。

  高实时。对等多线程异步非壅塞、实时计较、长跟尾。我们这个系统不克不及用一些很高延迟的东西,比方说卡罗普你想都不用想了,另有像而今比较火的流式系统,所以也没有采用。

  高可用。我们这个系统不克不及有单点,并且有一个要求,你是统一个机房,不克不及降级。便是要是这个机房停电了,这个机房不监控也罢,但是你患上晓得它停电了。但是剩下的机房必需保障监控没有受到任何影响,并且还要保障15秒这个事。这是我创造的词,惰性智能选路这个其实也很简略,甚么叫惰性呢?像网络挂了,连不上了,我们Agent可以连到别的上,这个很简略,便是我们想门径让Agent让它晓得有这个的存在,我们不用DS传统法子。我们启动的时辰,或哪儿出了题目,我们拿到另外一个连,这个策略极度简略,但是这个东西作为一个接口,之前的Agent,由于网络断了会试下一个,便是终极会迁移到离它比来的,网络状态最好的,便是很默契的到达智能,而不用斟酌它跟谁跟尾。异常的,下游往下游发的时辰也是用的相应策略。另有高可用,我们要保障这个数据不克不及丢。便是有一点必必要保障,便是这个监控数据由于第一手拿到的都是本机的一些Agent,这个Agent必需保障数据到了让报警的谁人模块拿到。我们这个便是Agent拿到这个数据之后,翻译的这个模块只会进行转发,上面的收到确认之后传已往,最后再给。保障这个数据必然到了下游。由于这种东西的强保障,所以说也会招致性能上的窘境,便是说我们要保障数据不丢,又要保障高性能,这后面我们再说这个是如何做的。

  高吞吐。cache,照样cache。没有甚么好说的,认为一样平凡cache能处理的高并发都不是难点。

  多平台。那时我们做这个的时辰golang还没进去,所以都是用的C++。时间计数器一出题目甚么都出了题目,时钟欠好了,准时器到计较性能全都完蛋,Windows是一个极度坑的平台,厥后幸而有了golang,防备了Agent只能找极度桀?的人写的局限。

  5、 如何优化性能?

  ◆zlib流式紧缩

  这个写起来没那末好弄,但是听起来挺简略的。

  ◆pipeline滑动窗口

  ●之前说从Agent收集到数据,经由层层模块转发,如许就会招致要乞降回应的延迟会极度大,在大延迟的环境下如何保障高吞吐量,于是发数据的时辰,比方在翻译模块都是进行批量转发,那里回一个Ok。工程师说,在应用层又造了一个TTP,这个东西比较无聊。

  ◆协议改造,Protobuf

  ◆数据兼并

  ◆function-filter优化,那时优化也走了患上多弯路:

  ●profiler,而今CPU行为不是教科书里说的那些东西,而今CPU的架构体系不是常人能了解的了。我们的设法是各种都去实验,终极选择好用的。

  ●散布式改造,这个容易升高速度,终极没有再实验。

  6、走过弯路的感想

  所谓轻便即牢靠,我们曾做这种东西的时辰,便是关于数据转发和如何弄曾做了一些版本,也走了一些弯路,缓缓发现弄的越庞大坑越多,尤其是在限制要求尤其高的环境下,最后返璞归真,接续优化,进去的便是每个模块极端简略,感到便是散布式管道,都可以在linux系统里找到影子。做到轻便,由于有的模块,我们写代码都晓得,从产物来看,便是从这儿到那儿。写代码要是在设计上庞大化,患上多东西都绕,加班加点也不必然能弄明确。是以而今艺龙斟酌的便是从轻便出发,不要弄庞大的东西。

  结语:十万级服务器监控系统开发架构尚可承继圆满,愿往日更上一层楼。

互联网资讯
建站咨询:0531-85932880    24小时电话:155-0866-2880
欢迎咨询柏拉图网络科技