【51CTO专访】去年12月份，51CTO编辑有幸采访到了SinaEdge平台运维主管刘宇，他也是LinuxTone.org的创造人之一，在自动化运维方向有一定的研究。在了解到新浪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系统频道，千万不要错过哦！
