事發
某日下午，部門使用的測試環境出現問題，所有集成測試case都執行失敗。查詢測試用服務器發現是磁盤已滿，造成請求失敗。
應急處理
發現磁盤空間問題後，首先想到的是程序日誌過大，因爲這臺機器上部署了部門的幾十個應用,以前也出現過日誌造成磁盤空間不足的問題。所以，迅速執行日誌刪除，發現集成測試case都可以正確執行了。
但是過了不一會，發現某些應用報服務已宕機。再去服務器看，磁盤空間又滿了，而且刪除之後，幾分鐘磁盤就會再次填滿，速度十分之快。應急之下首先增加了一個2分鐘清理一次的定時腳本，但是磁盤空間告急。
尋找問題原因
這時候，只能看增長最快的日誌文件，然後去看具體是什麼東西打印了這麼多的日誌。查詢發現是網關的請求量達到了4k的qps，因爲是內網所以懷疑是有人在進行壓測，分析請求之後發現基本都是同事負責的一個接口的流量。詢問發現，下午執行了壓力測試，但是壓測平臺出了問題，不能正常停止壓測。估計問題就找到了。
封鎖請求進入
但是，和壓測平臺負責的同事溝通，他們說已經殺死了壓測程序，而且壓測機沒有root權限，不能進行tcpdump。很無奈，壓測平臺的同事也是信誓旦旦，覺得不是自己平臺的問題。
無奈之下，我們進行了對流量的分析和封鎖，進行請求參數、來源ip的封鎖。但是封鎖之後發現來源ip是公司的一個出口ip，導致其他業務的測試環境調我們調不通了。這種情況下，暫時讓其他業務方使用ip地址直連我們的測試環境。
定位請求的內網ip
最終的最終，我們找到了一種可以定位到來源內網ip的方法，用鐵一般的證據證明就是壓測平臺的幾臺機器在向我們發請求，才推動壓測平臺的同事重啓服務器，從而徹底關閉了發送請求的進程。
我們採用的方案是：在請求接入層針對來源流量執行一個301跳轉，跳轉到一個內網ip地址，這樣就可以抓取到來源的內網ip了。
~~~~~~~~~~~~~~~~~~~~~~~~~ 福利分割線~~~~~~~~~~~~~~~~~~~~~~~~~~~
-長期內推-：頭條、快手、美團、阿里、陌陌、噹噹。有需要的朋友可以發郵件到我的郵箱[email protected]。