流量暴漲擒兇記
田逸（[email protected]） from《網路管理與運維》
某天，月黑風高，寒風凌厲。迷糊中，一陣急促的**響起，來電告知，數個機房的頻寬暴漲，需要立即處理，否則idc服務商要拔網線了。一看時間，大概是凌晨2點了，真悲催啊！
先登入監控系統檢視流量。平時流量最大的乙個伺服器的頻寬跑滿1g了（因為當時急著處理故障，沒留下截圖），而正常情況下，它的頻寬峰值穩定在600m-700m/s的樣子，如下圖所示：
檢視其它伺服器，頻寬圖基本拉成一條直線，把100m跑滿了（這些機器效能差，頻寬為100m）。
儘管多個機房多個伺服器頻寬都超平常很多，基本可以確定是出問題了。但心裡還是不放心，擔心是cacti監控不准或者出了故障。因此又單獨登入數個流量大的伺服器，使用iptraf這樣的工具實時檢視，結果真的與cacti給出的結果一致。
1、使用者通過web藉口編輯和上傳檔案到源站伺服器；
2、源站用rsync同步檔案到中轉伺服器；
3、邊緣伺服器配置成快取，然後根據需要從中轉伺服器抓取所需的物件儲存起來。
為了提高可用性和負載均衡，邊緣伺服器從2個中轉伺服器抓取檔案。
一般來說，引起流量暴漲的原因無外乎有：遭受***、**市場推廣、系統或程式異常、***程式。通過詢問相關市場人員，答覆說近期沒有任何市場推廣；再問程式設計師，有沒有修改程式或新增外掛程式，答覆都是否定的。再讓管理人員檢視後台統計資料，但統計資料並沒有跟流量同步暴增。由此判斷，出問題的原因只剩下系統異常和******兩種情況。被植入***的機率很小：程式是通過***上傳的，並且只有靜態內容。
情況緊急，不可能每個伺服器都登入一片。因此先從流量最大的查起，再查流量次大的。檢查的專案包括：
(1)系統日誌：看是否有核心報錯；
(2)web日誌，統計ip**是否過於集中；
(3)檢視tcp狀態，了解請求情況；
(4)用工具iptraf檢視連線數最多的ip。
通過上述措施，得知連線數最多的ip不是來自使用者，而是來自伺服器之間的相互請求。通過查出來的ip，登入改伺服器，看是否發生了什麼？通過檢查程序、系統日誌、網路狀況都未找到原因。隨手執行了一下crontab –l 看有沒有什麼自動任務，結果發現有乙個指令碼，而且是每10鐘執行一次。我印象中沒寫個這樣乙個指令碼的。開啟一看，內容如下：
#!/bin/bash
path=`grep proxy_cache_path /usr/local/nginx/conf/vhosts/apk_cache.sery.com.conf |awk ''|sed 1d`
for i in `ls $path`; do
grep -a -r apk $path/$i/* | strings |grep "key:" >/tmp/cache_list$i.txt
grep -v apk$ /tmp/cache_list$i.txt >> /tmp/del$i.txt
\rm -rf `grep -v apk$ /tmp/cache_list$i.txt|awk -f: ''`
#echo $path/$i
sleep 60
done
\rm -rf /tmp/cache_list*
這個指令碼要結合具體場景才能弄明白，因為某些原因，這裡不再分析它；總之，這個指令碼的作用，就是在快取目錄查詢一些檔案是否存在，如果存在，就刪除它。
觀察流量圖，頻寬耗費逐步下降，10-20分鐘後，趨於正常了。打一通**後，繼續睡覺。
流量暴漲擒兇記
流量暴漲擒兇記 田逸 sery 163.com from 網路管理與運維 某天，月黑風高，寒風凌厲。迷糊中，一陣急促的 響起，來電告知，數個機房的頻寬暴漲，需要立即處理，否則idc服務商要拔網線了。一看時間，大概是凌晨2點了，真悲催啊！先登入監控系統檢視流量。平時流量最大的乙個伺服器的頻寬跑滿1g了...
XCode Debug 模式斷言擒 bug 記
認識到debug模式和斷言帶來的方便，我迫不及待地便將專案的schema重新設定回了debug模式 以前不懂，認為程式在發布的時候用的是release模式，為了降低發布時出現bug的機率，便很早前就將程式設定為debug模式。現在看來真是愚蠢之極。不知道有多少次，我在除錯bug的時候，判斷空指標用了...
XCode Debug 模式斷言擒 bug 記
認識到debug模式和斷言帶來的方便，我迫不及待地便將專案的schema重新設定回了debug模式 以前不懂，認為程式在發布的時候用的是release模式，為了降低發布時出現bug的機率，便很早前就將程式設定為debug模式。現在看來真是愚蠢之極。不知道有多少次，我在除錯bug的時候，判斷空指標用了...