【51CTO專訪】去年12月份，51CTO編輯有幸采訪到了SinaEdge平臺運維主管劉宇，他也是LinuxTone.org的創造人之一，在自動化運維方向有一定的研究。在了解到新浪CDN系統的代碼發布機制后，劉宇給大家分享了新浪CDN服務器的監控機制，對監控這方面技術感興趣的朋友可以多多關注。

[[80838]]

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系統頻道，千萬不要錯過哦！