监控服务器-谈在线网站服务器监控（五）之展望篇

发布时间：2018-01-04 所属栏目：建站经验

一 : 谈在线网站服务器监控（五）之展望篇

　　综合上几遍的连载，让我们对在线监控有全面的认识。现在的在线监控已经满足我们监控网站服务器大部分要求。人们对网站服务器依赖性越来越高，但网络的脆弱性确没本质改善，技术员还在艰苦的跟木马、被攻击、被入侵、互联不通等进行搏斗。

　　在线监控并不是简单Ping下IP、测试下网页，然后发出几条短信告警这么简单。在线监控还能为你做更多的东西，以我们多年从事IDC的经验，我们认为在线监控将会加强以下几个方面的发展：

　　一、智能化监控数据分析

　　添加越多的监控对象就等于对网站服务器进行越精密细致的监控，有任何风吹草动都逃不过监控的法眼。但我们的监控本质不是为了收到一大堆告警信息，而是为了确切的知道潜在的故障和已经发生的故障。如监控的网站发出告警，是WEB服务出现问题、还是单纯监控的站点出故障、还是系统CPU太高，单纯只收到网站告警是无法知道确切故障原因。在线监控需要对采集到大量的监控数据进行智能化分析，然后发出确切的故障告警消息。

　　二、安全性监控

　　服务器出现故障其中一个很重要原因是安全性被破坏，如被恶意添加超级管理员、服务器被植入病毒、网站被挂马等，安全性被破坏之后很快就会出现故障，谁都知道监控到安全性出现问题立即告警比发生故障后再告警更有效。需要监控安全性的对象：

　　1、操作系统用户和用户组被修改，如被添加超级管理员、普通用户被提权等。

　　2、被添加未知系统服务。

　　3、被添加未知进程。

　　4、被添加未知自启动项。

　　5、防火墙被修改。

　　三、趋势化告警

　　任何故障发生前都有个趋势，从正常的值变到非正常值。如硬盘容量在不断减少，CPU使用率在不断的增大等。在趋势过程中，在线监控先根据以前数据、平均数据、当前数据，自动计算趋势速度和趋势方向，发出趋势预测。如趋势将向异常方向发展，将立即发出趋势告警，并提示将在什么时候引起故障，甚至会给出需要添加设备、购买带宽等建议。

　　四、故障自动处理

　　接到故障告警，肯定是十万火急奔去机房或者远程连接服务器。网管们最痛苦是什么?是接到告警;更痛苦的是什么?是接到告警没办法处理。通过故障自动处理，大部分的故障可以自动恢复正常或者减缓带来的损失。如监控到某个网站访问异常，立即自动关闭该网站;监控到网络流量过高，立即自动关闭占用流量的程序以免影响其它服务器等。

　　五、更准确的网站性能监控

　　在线监控站点是有限的，不可能遍布全国甚至全世界每个地方，并且监控点都布置在机房，机房的带宽越比一般宽带上网的要大，所以通过机房监控点监控性能不能完全模拟到真实环境。使用共享的理念，让每个站长参与网站性能的监控，获取更准确的网站性能数据。

　　本文作者：中域互联应用与服务(http://www.118cy.com)在admin5原创首发，转载留下文章出处。

　　上一篇《谈在线网站服务器监控(四)之使用的主要在线监控服务网站推荐》

二 : 专访刘宇：解密新浪CDN服务器监控机制

【51CTO专访】去年12月份，51CTO编辑有幸采访到了SinaEdge平台运维主管刘宇，他也是LinuxTone.org的创造人之一，在自动化运维方向有一定的研究。在了解到新浪CDN系统的代码发布机制后，刘宇给大家分享了新浪CDN服务器的监控机制，对监控这方面技术感兴趣的朋友可以多多关注。

专访刘宇：解密新浪CDN服务器监控机制_cdn服务器

SinaEdge平台运维主管刘宇（@守住每一天）

51CTO：监控这块，对CDN来说如何？

刘宇：说实话，监控这块一直也是大头，我们出去跟别人聊也是聊监控这一块，服务器这块其实是很容易，但是要想把它做到快、精准、细致，有着很大的挑战。

51CTO：就是在机器多了的情况下？

刘宇：机器数量对监控部署也是挑战，CDN的布点和其他的服务布点策略不太一样。为了最大化节约成本，通常会选择2-3线城市，并且跨多个运营商。特别是过多的小运营商，延迟通常都比较大，延迟别说十几毫秒，十几秒那种都很正常。我们一般统计的平均标准至少都在一秒以上。

51CTO：那两个大运营商还好点。

刘宇：两个大运营商之间还算比较稳定，但是还是会有遇到延迟放大的情况。越到地方就越明显，当机房变得越来越多时，挑战也就越大，所以说其实这一块监控其实会比较麻烦。我们目前的话监控主要针对于应用层面和物理层。可以先聊聊物理层面的吧。

51CTO：好的，那先聊物理层面的。

刘宇：由CDN的机房比较分散，我们在判断一个机房故障时，不能单纯从一条链路故障来判断，比如A机房down掉的情况，不能主观意识的从我们的核心结构去观察到它，这个机房，不通了，或者是已经死掉了，对吧。因为CDN的话，除了管理之外，我们还可以对用户，从用户层面上来讲，有可能这个机房是OK的。但是从管理级别上来讲，这个机房是不ok的，因为它不可控。

从运维角度上来讲，因为不可控了，那我就应该标记为不可用了。但是实际上，有可能你无法做到它不可控了、不可用了，你就去把服务切掉，因为有可能这个机房所承载的服务量会比较大。特别是高峰期，做这种流量标注的时候会影响到用户的质量，其他服务机房的带宽的成本就会上升。所以我们自己开发了一套监控体系，取了一个名字叫Bench。（很多公司都这么叫，呵呵）它主要的功能就是说，第一个是从多机房的维度去探测这一个机房。如果说我在这一个时间之内判断，比方说我的维度是五个机房，有三个地方探测这个机房不可用了，那就把这个机房标记为不可用。它是真的不可用了，这是第一个维度。

第二个维度是用户层面的，就是说，我去模拟这个地区之内的用户的请求。比方说这个机房是在广州，那我就模拟广州用户的请求，我在湖北，我就看湖北用户的请求，然后去判断它在这种情况下的不可用。如果说它不可用了，我们就预警，标记这个机房为不可用的。如果只是单次的情况，比如从我们监控层面来讲，经常会用有网络顾客打来说丢包啊什么的，我们大部分时间都采用忽略不计，除非影响故障时间特别长。

51CTO：丢包都忽略不计么？

刘宇：只是简单的丢包、延迟，我们一般都会忽略不计。我们公司的网络架构包括外网和内网，通常我们在管理级别的都在内网，所以说监控级别大部分在内网，所以有可能它只是内网的抖动，不会涉及到公网的抖动。如果说公网级别没有任何问题，我们通常就不管。这种大网络抖动会三五分钟就抖一次，这很正常。如果说我三五分钟抖一次我就清一次服务，有可能你的服务还没有在一分钟之内生效--根据一个TTL时间，像Google设的是90s，各个公司的都不一样，一般是在60s或90s之内才生效--那还不够你来回去倒腾的。除非说有那种大的那种网络抖动，影响服务特别严重的问题。

51CTO：这种情况多吗？

刘宇：这种大的网络抖动，说起来确实也挺多的，一年怎么的也给你搞个一两回吧。这种情况没办法去避免的，不单只是新浪的用户，全中国的这种用户都会受到这种大网抖动的波及。这是属于我们的不可控，不过我们还是照样忽略不管。如果确定是大网抖动，那谁都不好，我为什么还要动它呢？你动它反而会有更大的风险存在，这种风险控制与其做还不如不做。

但是前提就是，你要在第一时刻去判断它到底是属于哪儿的故障。如果确定是机房的不可用，那你必须要在一定时间之内去响应。所以说在服务器这层，我们还是做了很多改进的。毕竟，系统底层的这种负载服务的监控，谁都能做，包括像网络的，网卡，系统，IO，内存，CPU这些，我觉得还是比较简单的。

51CTO：网络的可访问性，是按照运营商和地域去监控的么？

刘宇：对，根据运营商和地域，必须是两个纬度。比如说我是长宽的用户，那我天天去测别的也没意义。

说真的，对于小运营商，我接触的时间是也算比较长的，从以前做CDN到现在一直在接触小运营商。小运营商的网络质量真的让人无法忍受，因为他们出口带宽是限死的。对于他们而言，出口带宽就是成本：就像我们去买带宽一样，他们的出口带宽也是他们花钱买的。像北京长宽他们出口的时候，网通带宽比较贵，所以他们宁可去买电信的带宽来做出口，相对来说比较便宜。其实这样也能保证服务质量，他们更多的是内部强制你去缓存啊，做cache呀，劫持啊，各种花哨都想出来了，无外乎就是省这点钱。所以说我们要是做北京长宽的这种点，你去探测网通节点，有可能他们本来就网通出口就很少，你还要做这种探测，数据上就没什么意义，因为它常年都有丢包、抖动。

51CTO：那服务层基本上就是这样。应用层的监控涉及到哪些？

刘宇：应用层面，我这边因为涉及到的业务线比较多，所以对我来说也是一个比较大的挑战。因为我这边涉及到业务有：CDN，大文件，小文件，动态，点播、直播。

51CTO：不同的产品线会有自己的应用运维吧。

刘宇：对于我而言，不分产品线，面对的就是新浪所有的客户：所有在我这边加速的都是我的客户。每一个客户的监控都是必不可少的。对于这一级别的客户，一个应用就是一个Application，一个Application会有多个Channel，因为它有多个域名。每个Channel都会做一个监控，这就是最基本的对应用层面的监控。另外一个层面是监控它的源站可不可用。如果源站没了，那我CDN去哪儿也抓不了。有可能用户反应故障的时候，第一时间你会发现不是我们CDN的问题，是源的问题，源挂掉了那我也没办法。所以，源站出现问题时我们会发送自动通知，告知客户，你的源站在这个时间点之内出现了网络抖动、网络不可达、哪个点到哪个点出了问题，或类似的情况。

我们自己更多的是保障我们节点回源的情况，只要回源就OK。网络链路的情况是我们优化的重点。对于我们源站那块，主要是HTTP层面的监控，保证服务响应是正常的，确保网络层面的正常。

51CTO：其实就像你说的比如说HTTP这个层面就已经算是一个应用层面的东西了。那么，具体到用户访问每个页面的响应这个层级呢？

刘宇：那一层我们叫服务质量监控，不叫应用层监控了。如果说你说那一级的话，我前段时间还在和朋友讨论说我们这一块是怎么做的。我们自己也是开发的这一套应用的这种监控。

我们主要是结合两点。第一个是我们自己的开发的系统，也是去模拟用户的请求，记录HTTP所有的状态过程和响应时间，这种其实跟基调是一样的；另一方面是基调的监控，两方面的结合。因为基调做预警不是特别的理想，它可能你去定义某一个监控项，比如某一个地域，某一个监控阀值出现了怎么样的情况之后给你发个预警，但是它如果信息量过多的情况下，它的结合就过度了。

我们自己来做就不会存在这样的问题，所以说也是个双向互补。比方说像DNS的时间，有可能DNS这块出了问题，所以说如果它不OK，你也没有办法。因为一般这估计5~10毫秒，一般5毫秒，3毫秒就搞定了，然后再一个就是首包的时间。当你DNS响应完成之后，你的客户端去服务器可能去取数据，这个时候你有个首包的过程，完成TCP三次握手之后，这个首包时间我们要做一个监控，如果你的首包时间过长，一般有可能就是这个服务出现了一个负载压力，它的首包响应通知不了，那就已经下降了。这个时候就是我们要关注的重点。

另外一个就是下载时间。下载时间就要分两个层面了，第一个是是否Cache，是不是要回源了？如果下载时间过长的情况下，如果我们自己这边确定Cache好的，它还会响应缓慢，那有可能就是IO压力。其实时间长了，经验多了，就能判断出来这个IO的压力。因为其他的响应层面的都很正常，但是它就下载的慢，然后一看这里还是Cache，接着你再看它是Memcache还是内存Cache。

如果说它是在内存缓冲，那么有可能OK。这个url可能访问量比较少，它还没有被转化到内存，它还在硬盘里面去。有可能这个时候这个机器会有一定负载，它也是IO压力，只有IO压力响应慢了，之后才你会特别慢。然后你再去判断，如果说没有被Cache，会去回源取了的，那回源取了之后你再去查看，对Cache我们所说的那种监控对不对，他回源是不是正常的，如果回源的话这时候网络抖了一下，那对不起这个时候肯定慢了，因为我回源取数据在通知用户的时候就已经慢了，下载时间就变成0。

所以说从这个数据上面我们就能很好的去看得到用户整个取得的这个过程，它好不好慢不慢其实都能看得出来。

总体来说，新浪CDN的监控体系从物理层可用性（设备、节点、网络状态）、应用层面可用性（HTTP）、服务质量（类基调）三个维度出发，结合业务特性做优化工作，并把相关的数据结合更加精密，每一个监控项都需要不断深入细化、调试。慢工做细活，监控就是个细活。

非常感谢刘宇的分享，我们后续还会推出专访的第三部分，CDN故障响应机制及修复措施。对此次系列专访感兴趣的朋友，请您持续关注51CTO系统频道，千万不要错过哦！

三 : shell脚本监控MySQL服务是否正常

监控MySQL服务是否正常，通常的思路为：检查3306端口是否启动，ps查看mysqld进程是否启动，命令行登录mysql执行语句返回结果，php或jsp程序检测（需要开发人员开发程序）等等；

方法1：监听3306端口