【51CTO專訪】去年12月份，51CTO編輯有幸采訪到了SinaEdge平臺(tái)運(yùn)維主管劉宇，他也是LinuxTone.org的創(chuàng)造人之一，在自動(dòng)化運(yùn)維方向有一定的研究。在了解到新浪CDN系統(tǒng)的代碼發(fā)布機(jī)制后，劉宇給大家分享了新浪CDN服務(wù)器的監(jiān)控機(jī)制，對(duì)監(jiān)控這方面技術(shù)感興趣的朋友可以多多關(guān)注。

[[80838]]

SinaEdge平臺(tái)運(yùn)維主管 劉宇（@守住每一天）

51CTO：監(jiān)控這塊，對(duì)CDN來(lái)說(shuō)如何？

劉宇：說(shuō)實(shí)話，監(jiān)控這塊一直也是大頭，我們出去跟別人聊也是聊監(jiān)控這一塊，服務(wù)器這塊其實(shí)是很容易，但是要想把它做到快、精準(zhǔn)、細(xì)致，有著很大的挑戰(zhàn)。

51CTO：就是在機(jī)器多了的情況下？

劉宇：機(jī)器數(shù)量對(duì)監(jiān)控部署也是挑戰(zhàn)，CDN的布點(diǎn)和其他的服務(wù)布點(diǎn)策略不太一樣。為了最大化節(jié)約成本，通常會(huì)選擇2-3線城市，并且跨多個(gè)運(yùn)營(yíng)商。特別是過(guò)多的小運(yùn)營(yíng)商，延遲通常都比較大，延遲別說(shuō)十幾毫秒，十幾秒那種都很正常。我們一般統(tǒng)計(jì)的平均標(biāo)準(zhǔn)至少都在一秒以上。

51CTO：那兩個(gè)大運(yùn)營(yíng)商還好點(diǎn)。

劉宇：兩個(gè)大運(yùn)營(yíng)商之間還算比較穩(wěn)定，但是還是會(huì)有遇到延遲放大的情況。越到地方就越明顯，當(dāng)機(jī)房變得越來(lái)越多時(shí)，挑戰(zhàn)也就越大，所以說(shuō)其實(shí)這一塊監(jiān)控其實(shí)會(huì)比較麻煩。我們目前的話監(jiān)控主要針對(duì)于應(yīng)用層面和物理層?？梢韵攘牧奈锢韺用娴陌伞?/p>

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

劉宇： 由CDN的機(jī)房比較分散，我們?cè)谂袛嘁粋€(gè)機(jī)房故障時(shí)，不能單純從一條鏈路故障來(lái)判斷，比如A機(jī)房down掉的情況，不能主觀意識(shí)的從我們的核心結(jié)構(gòu)去觀察到它，這個(gè)機(jī)房，不通了，或者是已經(jīng)死掉了，對(duì)吧。因?yàn)镃DN的話，除了管理之外，我們還可以對(duì)用戶，從用戶層面上來(lái)講，有可能這個(gè)機(jī)房是OK的。但是從管理級(jí)別上來(lái)講，這個(gè)機(jī)房是不ok的，因?yàn)樗豢煽亍?/p>

從運(yùn)維角度上來(lái)講，因?yàn)椴豢煽亓耍俏揖蛻?yīng)該標(biāo)記為不可用了。但是實(shí)際上，有可能你無(wú)法做到它不可控了、不可用了，你就去把服務(wù)切掉，因?yàn)橛锌赡苓@個(gè)機(jī)房所承載的服務(wù)量會(huì)比較大。特別是高峰期，做這種流量標(biāo)注的時(shí)候會(huì)影響到用戶的質(zhì)量，其他服務(wù)機(jī)房的帶寬的成本就會(huì)上升。所以我們自己開(kāi)發(fā)了一套監(jiān)控體系，取了一個(gè)名字叫Bench。（很多公司都這么叫，呵呵）它主要的功能就是說(shuō)，第一個(gè)是從多機(jī)房的維度去探測(cè)這一個(gè)機(jī)房。如果說(shuō)我在這一個(gè)時(shí)間之內(nèi)判斷，比方說(shuō)我的維度是五個(gè)機(jī)房，有三個(gè)地方探測(cè)這個(gè)機(jī)房不可用了，那就把這個(gè)機(jī)房標(biāo)記為不可用。它是真的不可用了，這是第一個(gè)維度。

第二個(gè)維度是用戶層面的，就是說(shuō)，我去模擬這個(gè)地區(qū)之內(nèi)的用戶的請(qǐng)求。比方說(shuō)這個(gè)機(jī)房是在廣州，那我就模擬廣州用戶的請(qǐng)求，我在湖北，我就看湖北用戶的請(qǐng)求，然后去判斷它在這種情況下的不可用。如果說(shuō)它不可用了，我們就預(yù)警，標(biāo)記這個(gè)機(jī)房為不可用的。如果只是單次的情況，比如從我們監(jiān)控層面來(lái)講，經(jīng)常會(huì)用有網(wǎng)絡(luò)顧客打來(lái)說(shuō)丟包啊什么的，我們大部分時(shí)間都采用忽略不計(jì)，除非影響故障時(shí)間特別長(zhǎng)。

51CTO：丟包都忽略不計(jì)么？

劉宇：只是簡(jiǎn)單的丟包、延遲，我們一般都會(huì)忽略不計(jì)。我們公司的網(wǎng)絡(luò)架構(gòu)包括外網(wǎng)和內(nèi)網(wǎng)，通常我們?cè)诠芾砑?jí)別的都在內(nèi)網(wǎng)，所以說(shuō)監(jiān)控級(jí)別大部分在內(nèi)網(wǎng)，所以有可能它只是內(nèi)網(wǎng)的抖動(dòng)，不會(huì)涉及到公網(wǎng)的抖動(dòng)。如果說(shuō)公網(wǎng)級(jí)別沒(méi)有任何問(wèn)題，我們通常就不管。這種大網(wǎng)絡(luò)抖動(dòng)會(huì)三五分鐘就抖一次，這很正常。如果說(shuō)我三五分鐘抖一次我就清一次服務(wù)，有可能你的服務(wù)還沒(méi)有在一分鐘之內(nèi)生效--根據(jù)一個(gè)TTL時(shí)間，像Google設(shè)的是90s，各個(gè)公司的都不一樣，一般是在60s或90s之內(nèi)才生效--那還不夠你來(lái)回去倒騰的。除非說(shuō)有那種大的那種網(wǎng)絡(luò)抖動(dòng)，影響服務(wù)特別嚴(yán)重的問(wèn)題。

51CTO：這種情況多嗎？

劉宇：這種大的網(wǎng)絡(luò)抖動(dòng)，說(shuō)起來(lái)確實(shí)也挺多的，一年怎么的也給你搞個(gè)一兩回吧。這種情況沒(méi)辦法去避免的，不單只是新浪的用戶，全中國(guó)的這種用戶都會(huì)受到這種大網(wǎng)抖動(dòng)的波及。這是屬于我們的不可控，不過(guò)我們還是照樣忽略不管。如果確定是大網(wǎng)抖動(dòng)，那誰(shuí)都不好，我為什么還要?jiǎng)铀?？你?dòng)它反而會(huì)有更大的風(fēng)險(xiǎn)存在，這種風(fēng)險(xiǎn)控制與其做還不如不做。

但是前提就是，你要在第一時(shí)刻去判斷它到底是屬于哪兒的故障。如果確定是機(jī)房的不可用，那你必須要在一定時(shí)間之內(nèi)去響應(yīng)。所以說(shuō)在服務(wù)器這層，我們還是做了很多改進(jìn)的。畢竟，系統(tǒng)底層的這種負(fù)載服務(wù)的監(jiān)控，誰(shuí)都能做，包括像網(wǎng)絡(luò)的，網(wǎng)卡，系統(tǒng)，IO，內(nèi)存，CPU這些，我覺(jué)得還是比較簡(jiǎn)單的。

51CTO：網(wǎng)絡(luò)的可訪問(wèn)性，是按照運(yùn)營(yíng)商和地域去監(jiān)控的么？

劉宇：對(duì)，根據(jù)運(yùn)營(yíng)商和地域，必須是兩個(gè)緯度。比如說(shuō)我是長(zhǎng)寬的用戶，那我天天去測(cè)別的也沒(méi)意義。

說(shuō)真的，對(duì)于小運(yùn)營(yíng)商，我接觸的時(shí)間是也算比較長(zhǎng)的，從以前做CDN到現(xiàn)在一直在接觸小運(yùn)營(yíng)商。小運(yùn)營(yíng)商的網(wǎng)絡(luò)質(zhì)量真的讓人無(wú)法忍受，因?yàn)樗麄兂隹趲捠窍匏赖摹?duì)于他們而言，出口帶寬就是成本：就像我們?nèi)ベI帶寬一樣，他們的出口帶寬也是他們花錢買的。像北京長(zhǎng)寬他們出口的時(shí)候，網(wǎng)通帶寬比較貴，所以他們寧可去買電信的帶寬來(lái)做出口，相對(duì)來(lái)說(shuō)比較便宜。其實(shí)這樣也能保證服務(wù)質(zhì)量，他們更多的是內(nèi)部強(qiáng)制你去緩存啊，做cache呀，劫持啊，各種花哨都想出來(lái)了，無(wú)外乎就是省這點(diǎn)錢。所以說(shuō)我們要是做北京長(zhǎng)寬的這種點(diǎn)，你去探測(cè)網(wǎng)通節(jié)點(diǎn)，有可能他們本來(lái)就網(wǎng)通出口就很少，你還要做這種探測(cè)，數(shù)據(jù)上就沒(méi)什么意義，因?yàn)樗Ｄ甓加衼G包、抖動(dòng)。

51CTO：那服務(wù)層基本上就是這樣。應(yīng)用層的監(jiān)控涉及到哪些？

劉宇：應(yīng)用層面，我這邊因?yàn)樯婕暗降臉I(yè)務(wù)線比較多，所以對(duì)我來(lái)說(shuō)也是一個(gè)比較大的挑戰(zhàn)。因?yàn)槲疫@邊涉及到業(yè)務(wù)有：CDN，大文件，小文件，動(dòng)態(tài)，點(diǎn)播、直播。

51CTO：不同的產(chǎn)品線會(huì)有自己的應(yīng)用運(yùn)維吧。

劉宇：對(duì)于我而言，不分產(chǎn)品線，面對(duì)的就是新浪所有的客戶：所有在我這邊加速的都是我的客戶。每一個(gè)客戶的監(jiān)控都是必不可少的。對(duì)于這一級(jí)別的客戶，一個(gè)應(yīng)用就是一個(gè)Application，一個(gè)Application會(huì)有多個(gè)Channel，因?yàn)樗卸鄠€(gè)域名。每個(gè)Channel都會(huì)做一個(gè)監(jiān)控，這就是最基本的對(duì)應(yīng)用層面的監(jiān)控。另外一個(gè)層面是監(jiān)控它的源站可不可用。如果源站沒(méi)了，那我CDN去哪兒也抓不了。有可能用戶反應(yīng)故障的時(shí)候，第一時(shí)間你會(huì)發(fā)現(xiàn)不是我們CDN的問(wèn)題，是源的問(wèn)題，源掛掉了那我也沒(méi)辦法。所以，源站出現(xiàn)問(wèn)題時(shí)我們會(huì)發(fā)送自動(dòng)通知，告知客戶，你的源站在這個(gè)時(shí)間點(diǎn)之內(nèi)出現(xiàn)了網(wǎng)絡(luò)抖動(dòng)、網(wǎng)絡(luò)不可達(dá)、哪個(gè)點(diǎn)到哪個(gè)點(diǎn)出了問(wèn)題，或類似的情況。

我們自己更多的是保障我們節(jié)點(diǎn)回源的情況，只要回源就OK。網(wǎng)絡(luò)鏈路的情況是我們優(yōu)化的重點(diǎn)。對(duì)于我們?cè)凑灸菈K，主要是HTTP層面的監(jiān)控，保證服務(wù)響應(yīng)是正常的，確保網(wǎng)絡(luò)層面的正常。

51CTO：其實(shí)就像你說(shuō)的比如說(shuō)HTTP這個(gè)層面就已經(jīng)算是一個(gè)應(yīng)用層面的東西了。那么，具體到用戶訪問(wèn)每個(gè)頁(yè)面的響應(yīng)這個(gè)層級(jí)呢？

劉宇：那一層我們叫服務(wù)質(zhì)量監(jiān)控，不叫應(yīng)用層監(jiān)控了。如果說(shuō)你說(shuō)那一級(jí)的話，我前段時(shí)間還在和朋友討論說(shuō)我們這一塊是怎么做的。我們自己也是開(kāi)發(fā)的這一套應(yīng)用的這種監(jiān)控。

我們主要是結(jié)合兩點(diǎn)。第一個(gè)是我們自己的開(kāi)發(fā)的系統(tǒng)，也是去模擬用戶的請(qǐng)求，記錄HTTP所有的狀態(tài)過(guò)程和響應(yīng)時(shí)間，這種其實(shí)跟基調(diào)是一樣的；另一方面是基調(diào)的監(jiān)控，兩方面的結(jié)合。因?yàn)榛{(diào)做預(yù)警不是特別的理想，它可能你去定義某一個(gè)監(jiān)控項(xiàng)，比如某一個(gè)地域，某一個(gè)監(jiān)控閥值出現(xiàn)了怎么樣的情況之后給你發(fā)個(gè)預(yù)警，但是它如果信息量過(guò)多的情況下，它的結(jié)合就過(guò)度了。

我們自己來(lái)做就不會(huì)存在這樣的問(wèn)題，所以說(shuō)也是個(gè)雙向互補(bǔ)。比方說(shuō)像DNS的時(shí)間，有可能DNS這塊出了問(wèn)題，所以說(shuō)如果它不OK，你也沒(méi)有辦法。因?yàn)橐话氵@估計(jì)5~10毫秒，一般5毫秒，3毫秒就搞定了，然后再一個(gè)就是首包的時(shí)間。當(dāng)你DNS響應(yīng)完成之后，你的客戶端去服務(wù)器可能去取數(shù)據(jù)，這個(gè)時(shí)候你有個(gè)首包的過(guò)程，完成TCP三次握手之后，這個(gè)首包時(shí)間我們要做一個(gè)監(jiān)控，如果你的首包時(shí)間過(guò)長(zhǎng)，一般有可能就是這個(gè)服務(wù)出現(xiàn)了一個(gè)負(fù)載壓力，它的首包響應(yīng)通知不了，那就已經(jīng)下降了。這個(gè)時(shí)候就是我們要關(guān)注的重點(diǎn)。

另外一個(gè)就是下載時(shí)間。下載時(shí)間就要分兩個(gè)層面了，第一個(gè)是是否Cache，是不是要回源了？如果下載時(shí)間過(guò)長(zhǎng)的情況下，如果我們自己這邊確定Cache好的，它還會(huì)響應(yīng)緩慢，那有可能就是IO壓力。其實(shí)時(shí)間長(zhǎng)了，經(jīng)驗(yàn)多了，就能判斷出來(lái)這個(gè)IO的壓力。因?yàn)槠渌捻憫?yīng)層面的都很正常，但是它就下載的慢，然后一看這里還是Cache，接著你再看它是Memcache還是內(nèi)存Cache。

如果說(shuō)它是在內(nèi)存緩沖，那么有可能OK。這個(gè)url可能訪問(wèn)量比較少，它還沒(méi)有被轉(zhuǎn)化到內(nèi)存，它還在硬盤里面去。有可能這個(gè)時(shí)候這個(gè)機(jī)器會(huì)有一定負(fù)載，它也是IO壓力，只有IO壓力響應(yīng)慢了，之后才你會(huì)特別慢。然后你再去判斷，如果說(shuō)沒(méi)有被Cache，會(huì)去回源取了的，那回源取了之后你再去查看，對(duì)Cache我們所說(shuō)的那種監(jiān)控對(duì)不對(duì)，他回源是不是正常的，如果回源的話這時(shí)候網(wǎng)絡(luò)抖了一下，那對(duì)不起這個(gè)時(shí)候肯定慢了，因?yàn)槲一卦慈?shù)據(jù)在通知用戶的時(shí)候就已經(jīng)慢了，下載時(shí)間就變成0。

所以說(shuō)從這個(gè)數(shù)據(jù)上面我們就能很好的去看得到用戶整個(gè)取得的這個(gè)過(guò)程，它好不好慢不慢其實(shí)都能看得出來(lái)。

總體來(lái)說(shuō)，新浪CDN的監(jiān)控體系從物理層可用性（設(shè)備、節(jié)點(diǎn)、網(wǎng)絡(luò)狀態(tài)）、應(yīng)用層面可用性（HTTP）、服務(wù)質(zhì)量（類基調(diào)）三個(gè)維度出發(fā)，結(jié)合業(yè)務(wù)特性做優(yōu)化工作，并把相關(guān)的數(shù)據(jù)結(jié)合更加精密，每一個(gè)監(jiān)控項(xiàng)都需要不斷深入細(xì)化、調(diào)試。慢工做細(xì)活，監(jiān)控就是個(gè)細(xì)活。

非常感謝劉宇的分享，我們后續(xù)還會(huì)推出專訪的第三部分，CDN故障響應(yīng)機(jī)制及修復(fù)措施。對(duì)此次系列專訪感興趣的朋友，請(qǐng)您持續(xù)關(guān)注51CTO系統(tǒng)頻道，千萬(wàn)不要錯(cuò)過(guò)哦！