輕鬆應對IDC機房帶寬忽然暴漲問題

https://blog.51cto.com/oldboy/909696

 

1【提出問題】

【實際案例一】

凌晨3:00點某公司（網站業務）的一個IDC機房帶寬流量忽然從平時高峯期150M猛增至1000M，以下圖：

 

 

該故障的影響：直接致使數百臺服務器沒法鏈接，該機房所有業務中斷。

【實際案例二】

某年某月某日夜老男1孩接到學生緊急求助，公司網站（web遊戲業務）平時幾十M帶寬，結果忽然跑滿100M，持續100M已經好久。過後，該學生的總結開頭以下，

凌晨一點接到報警短信，網站沒法訪問。立馬拿起筆記本上網查看，發現整個機櫃的網絡都沒法正常訪問。第一感受是否是IDC網絡出問題了，給機房打電話反饋回來的信息是機房網絡正常，可是帶寬流量異常(100M帶寬的流量峯值已跑瞞)。

該故障的影響：直接致使數十臺服務器沒法鏈接，該機房所有業務中斷，且故障持續時間長。

【實際案例三】

某月某日，接到運維的朋友緊急求助，其公司的CDN源站，源站的流量沒有變更，CDN那邊的流量無端超了好幾個G，不知道怎麼處理？ 老男孩補充，曾遇到過一張圖片不到一天，跑了20多T的一張流量。
該故障的影響：因爲是購買的CDN，雖然流量多了幾個G，可是業務未受影響，可是，這麼大的異常流量，持續下去可直接致使公司無端損失數萬元。解決這個問題體現運維的價值。

 

事不過三，暫時先舉3個例子吧。這三個案例都是運維工做中實際遇到的故障，事發忽然且須要緊急處理。在實際論壇或羣裏看到朋友反饋的此類問題，也多達數次，其中差很少各類鳥都有，老鳥、中鳥，小鳥。
大部分朋友解決起來，腦殼裏沒思路（反射弧直接定位DDOS），解決起來耗時長，形成的了業務長時間中斷。老鳥解決起來也是循序漸進，首先會反射爲DDOS問題，結果解決時間加長了，若是能提早作好預案，恢復速度可能就會好不少，下面老男孩就來談下我的的一些見解。

2 【分析問題】
  1)IDC帶寬被佔滿的緣由不少，常見的有：

  a.真實遭受DDOS攻擊（遇到過幾回，形成影響的很少見，其中還有黑客勒索的案例）。
  b.內部服務器中毒，大量外發流量（這個問題老男孩接警5次以上）

  c.網站元素（如圖片）被盜連，在門戶頁面被推廣致使大量流量產生（接警3次以上）

  d.合做公司來抓數據，如：對合做單位提供了API數據接口（有合做的公司的朋友瞭解這個）

e.購買了CDN業務，CDN猛抓源站（這個次數也很多）。

  f.其餘緣由還有一些，不廣泛就不提了。

  2)CDN帶寬異常，源站沒異常。

  這類問題基本都是緩存在CDN的數據被頻繁訪問引發的。解決方法見結尾案例。

  3) CDN帶寬異常，源站也異常。

    可能緣由如公司作推廣，大量數據訪問，熱點數據cache裏不全。或CDN問題致使數據回源（有關CDN回源率問題及提高回源率經驗，之後再和你們分享）。影響就是帶寬高，後端靜態服務器及圖片及存儲壓力大（解決辦法見老男孩的7層門戶網站架構案例文章http://oldboy.blog.51cto.com/2561410/736710）

 

3 【解決問題】
   分析了問題的可能緣由，就比如較排查了。

     a.真實遭受DDOS攻擊

       DDOS問題的解決老男孩已經寫了原創文章（http://oldboy.blog.51cto.com/2561410/845349），提供了17條解決經驗思路，供你們參考，這裏就不提了，那麼實際上

遭受真實DDOS攻擊併產生影響的並非最多見的。

     b.內部服務器中毒，大量外發流量。

     這個問題的解決比較簡單，可能有的朋友說，看看服務器流量，哪一個機器帶寬高處理下就行了。其實否則，實際解決比這複雜得多，帶寬打滿，全部監控都是看不到的。
    比較好的思路，是聯繫機房肯定機房自身無問題後（機房通常無法幫咱們的），請機房斷開鏈接外部IP服務器的網線，如負載均衡器，僅保留××× SERVER，而後斷掉內部服務器出網光關的線路，切斷外發流量源頭。
     接下來查看監控流量服務，判斷外發流量的服務器，而後進行處理。
     其實，這個問題的發生及快速定位和不少公司的運維規範、制度關係很大，老男孩在給一些公司作運維培訓分享時發現這個問題很嚴重（表象很好，內部運維規範、制度欠缺不少），你們都討論的很深刻，實際用的仍是和聊的有差距。。

      好比有的公司開發直接FTP鏈接隨時發佈代碼，或者由開發人員負責定時屢次上線。而運維人員又不知曉，結果致使問題發生定位時間長，這點建議各公司的老大多思考下。
     老男孩的運維思路是，若是把網站機房比喻爲一座房子，那首先要堵住後門（內部），其次是監控好前門（作好安全，留個小窗戶給外面人看，即80端口服務，同時安排站崗值班的）。
     網站的無休止的隨時隨意發佈代碼，對網站的穩定影響是相當重要的。對運維人員對故障的定位快慢也很關鍵。根據老男孩不徹底調查，約50%以上的重要運維故障都是程序代碼致使的，這也是老男孩給企業作培訓分享時，灌輸建議CTO的，多把網站穩定的責任分給開發，而不是運維。若是這個思想不扭轉，網站不穩定情況就難以改變。
  c.網站元素（如圖片）被盜連
    這個屬於網站的基本優化了，apache,lighttpd,nginx都有防盜鏈的方案，必需要搞。說到這也提個案例，老男孩的一個學生，到了企業工做，發現人家網站沒有防盜鏈，結果上來沒有周知老大，直接作防盜鏈了,而後美滋滋的當時還給我留言，說給公司搞防盜鏈了，頗有成就，結果致使公司對外合做的業務，都是小叉子了，幸好發現的及時沒出大問題。
  d-e.合做公司來抓數據，如：對合做單位提供了API數據接口或購買了CDN業務。

    最多見的就是購買CDN服務，如：CDN新建一個節點（可能數十機器），直接來咱們IDC原戰來抓數據（有的作好點的夜裏來抓）。把原站抓的流量暴漲，嚴重的致使服務宕機。幾家CDN公司，都有過這樣的問題。這點但願CDN公司看到了，能改善，畢竟用戶上帝嘛。

     固然和電信，聯通，GOOGLE,BAIDU，詞霸等公司的合做，也會有流量暴高的狀況，這裏麪包括了爲合做的站搜索引擎爬蟲爬數據的問題。有時雖然帶寬流量不高，可是服務器或數據庫撐不住了，搜索引擎專門喜歡爬咱們的站內搜索，DISCUZ，CMS等早期的開源程序的搜索都是全站like %%方式去數據庫搜索的，幾個爬蟲過來，直接就掛掉了，固然這不是本文要討論的，解決方案之後再聊。

  f.其餘緣由還有一些，不廣泛就不提了。

    上面的幾點比較常見，其餘緣由就很少見了，所以，做罷，打這麼多字真不輕鬆啊。

4 【苦練內功】

首先，老男孩強調下，你們要常常培養下本身的內心素質，遇到問題不能發慌。遇到很多朋友，處理緊急故障時，大腦都空白缺血了，手抖的沒法敲擊鍵盤了，這樣的狀態如何解決故障呢？若是老大在後面看着就更是雪上加霜了，甚至有個別學生直接跟老男孩哭鼻子了，宕機幾分鐘損失上萬，負不起責任。

 其實上面的你們的表現都是正常的，沒什麼不對的，曾經老男孩也是這樣過來的，也是不斷的挑戰本身才練出來的。
但願朋友們能多提早作功課，不要問題來了在思考解決辦法，臨時的應對必定會是手忙腳亂的，即便是老鳥。若是提早有預案和防範演練，問題發生後就坦然得多，這能夠擴展到運維的方方面面，DB,WEB,備份，恢復，流量等。
5 【亡羊補牢】

發生問題後，要充分總結，爭取下次發生了，能提高速度，固然最好不發生。其實，運維人員挺悲催的，開發的下班就沒事了，咱們還得7*24開手機，來個短信提心吊膽的，甚至看到有個門戶DBA發微薄，說making love時均可能被報警短信打斷。1、提早優化運維制度、規範。2、提早優化網站結構、單點故障。3、留足備用帶寬及服務器資源，把控好風險。4、完善的監控策略及響應機制等。

儘可能不打無準備之戰。兵法雲，知己知彼，百戰不殆。運維又未嘗不是這個理？

6 【實戰解決案例】

說了這麼多了，都是理論，再給個案例吧【摘自老男孩Linux培訓-shell培訓教案中的例子】，這裏要特別感謝白開水兄弟給予的支持。

下面的例子適合於網站流量很高，可是，還沒達到全網癱瘓的嚴重地步時的解決方案，適合咱們本身的IDC機房及CDN業務（若是是CDN,那麼，分析處理能夠交給CDN，本身下載CDN日誌分析也可）。

範例7：分析圖片服務日誌，把日誌（每一個圖片訪問次數*圖片大小的總和）排行，取top10，也就是計算每一個url的總訪問大小

說明：範例7的生產環境應用：這個功能能夠用於IDC及CDN網站流量帶寬很高，而後經過分析服務器日誌哪些元素佔用流量過大，進而進行優化裁剪該圖片（見老男孩發佈的《淘寶的雙十一超大流量應對文章點評》），壓縮js等措施。

本題須要輸出三個指標： 【訪問次數】    【訪問次數*單個文件大小】   【文件名（能夠帶URL）】

解答：

測試數據

59.33.26.105 - - [08/Dec/2010:15:43:56 +0800] "GET /static/p_w_picpaths/photos/2.jpg HTTP/1.1" 200 11299 "http://oldboy.blog.51cto.com/static/web/column/17/index.shtml?courseId=43" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

59.33.26.105 - - [08/Dec/2010:15:43:56 +0800] "GET /static/p_w_picpaths/photos/2.jpg HTTP/1.1" 200 11299 "http://oldboy.blog.51cto.com/static/web/column/17/index.shtml?courseId=43" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

59.33.26.105 - - [08/Dec/2010:15:44:02 +0800] "GET /static/flex/vedioLoading.swf HTTP/1.1" 200 3583 "http://oldboy.blog.51cto.com/static/flex/AdobeVideoPlayer.swf?width=590&height=328&url=/`DYNAMIC`/2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"

124.115.4.18 - - [08/Dec/2010:15:44:15 +0800] "GET /?= HTTP/1.1" 200 46232 "-" "-"

124.115.4.18 - - [08/Dec/2010:15:44:25 +0800] "GET /static/js/web_js.js HTTP/1.1" 200 4460 "-" "-"

124.115.4.18 - - [08/Dec/2010:15:44:25 +0800] "GET /static/js/jquery.lazyload.js HTTP/1.1" 200 1627 "-" "-"

法一：經過兩個數組來計算

由於咱們要的最終結果是某個文件的訪問次數和消耗的流量，因此考慮創建以文件名爲索引的兩個數組，一個存儲訪問次數，一個保存消耗的流量，這樣當使用awk按行遍歷文件時，對次數數組+1，同時對流量數組進行文件大小的累加，等文件掃描完成，再遍歷輸出兩個數組既能夠獲得該文件的反問次數和總的流量消耗。

[root@locatest scripts]# awk '{array_num[$7]++;array_size[$7]+=$10}END{for(x in array_num){print array_size[x],array_num[x],x}}' access_2010-12-8.log |sort -rn -k1|head -10 >1.log

法二：

[root@locatest scripts]# awk '{print $7"\t" $10}' access_2010-12-8.log|awk '{S[$1]+=$2;S1[$1]+=1}END{for(i in S) print S[i],S1[i],i}'|sort -rn|head -10 >2.log

[root@locatest scripts]# diff 1.log 2.log

[root@locatest scripts]# cat 1.log

57254 1 /static/js/jquery-jquery-1.3.2.min.js

46232 1 /?=

44286 1 //back/upload/course/2010-10-25-23-48-59-048-18.jpg

33897 3 /static/p_w_picpaths/photos/2.jpg

11809 1 /back/upload/teacher/2010-08-30-13-57-43-06210.jpg

10850 1 /back/upload/teacher/2010-08-06-11-39-59-0469.jpg

6417 1 /static/js/addToCart.js

4460 1 /static/js/web_js.js

3583 2 /static/flex/vedioLoading.swf

2686 1 /static/js/default.js