生產事故——磁碟使用率爆倉

今天不知道為啥醒得特別早，可能就是緣分吧。醒來一看微信，就發現線上的伺服器的磁碟使用率超過70%，真是早起的鳥兒有bug修。。。。。

當時我就立馬跑去看看監控，看看cpu，記憶體，io這些是否都正常。看了一圈，發現除了磁碟異常外，其他一切都正常。

我當時是7點左右看到的訊息，看到後，磁碟的使用率達到72%，超過了設定閾值70%。就如上圖的紅色箭頭所示。

當時我是直接進入伺服器，用df -h檢視伺服器的磁碟使用空間。

看到上圖，當時我人都傻了。2.7T空間，然後使用才5%，哪來的70%磁碟使用率。

後來深呼吸，喝口冰水冷靜一下，發現，公司用的是容器，而df -h查的是物理伺服器的磁碟空間。當時我情況比較緊急，我也忘了什麼命令可以查容器的硬碟空間。只好去谷歌輸入框輸入：“如何檢視容器的磁碟空間”

很快，我就搜到相關命令：docker system df -v

然而，等待我的卻是

docker system df -v

-bash： docker： command not found

牛逼！！！牛逼！！！

好吧，看來是沒辦法透過命令檢視哪個地方用的磁碟空間比較大了。不過又比較緊急，只能用最笨的方法：

遍歷查詢。但是這個遍歷，我優先遍歷檢視日誌檔案。沒想到一擊即中，立馬就找到了磁碟爆滿的根本原因。

你看，從2月25號日誌到現在3。21號的日誌都在，總共佔用了20G。我問了運維每臺容器分配30G。20G/30G=66。7%。單純日誌已經佔用磁碟空間的66。7%，再加上其他的應用，佔用70+%。實錘了，找到真兇了。我也沒想到這麼快找到。

至於為什麼我一開始就找日誌檔案呢？

主要是因為經驗吧，因為之前別的伺服器也出現過磁碟使用率問題，當時也是因為日誌檔案問題。簡單總結一下，雖然經驗不總是可靠，但排查線上問題時，經驗又總是那麼有用。

因此，排查問題時，一開始要根據監控資料，進行排查，不要先入為主，用想當然去排查，就是不用經驗去想問題。先跳出固有圈子，根據實實在在的監控指標資料排查。實在沒辦法時，再用經驗去排查也不遲。

那麼現在我們已經定位到磁碟空間問題的根本原因：日誌檔案佔用空間過多。

那接下來應該怎麼做呢？

只能刪檔案，騰出空間。遇到磁碟使用率問題，除了刪檔案，還有其他辦法嗎？有，擴大磁碟空間，但多大才夠，這方案顯然不是最高效的解決方案

這時候終於可以搬出好久沒使用的：rm -rf命令了。

我當時就直接把2月份的日誌都刪除了。

立馬看一下監控圖

磁碟使用率立馬斷崖式下降到70%以下，首要任務讓伺服器正常執行再說。

到這裡後，你以為就結束了嗎？……。並沒有

交代一下伺服器的背景：四臺伺服器，每臺伺服器2核8G。

刪檔案前：

刪檔案後：

我們可以看到，刪檔案的操作，的確暫時讓磁碟的使用率從71%降到63%。但是，你發現沒發現另一個問題。

另外2臺伺服器的磁碟使用率只有1%。但是另外2臺的伺服器的日誌檔案都佔了大約20G（容器的硬碟空間30G）

這讓我再一次傻眼兒了！！！！

明明大家都佔用了20G，2臺伺服器70%的使用率，另外2臺伺服器的使用率卻高達1%。

amazing！！！！！

害，母雞道點算（粵語）！！！

當時心想，先不管了。伺服器現在也正常服務了，等上班後，再和運維聊聊，找找原因。畢竟現在才7點，離上班還有3個小時。沒法找運維的！！！

帶著滿懷激動的心情，終於等到10點上班了。

經過和運維的一番描述（battle）後，終於找到了答案，解開了疑惑。

其實，就是監控資料的獲取有bug，從而導致資料不準確。

最後我還抓著運維，問了一下如何檢視容器的硬碟使用空間？

然而。。。。他好像也不太會。。。。

好了，今天的bug順利解決了。就是檢視容器的命令，到現在也沒找到。如果你有辦法，留言通知我！感謝！

推薦閱讀

大頭菜：《技術週報》20210322-20210326大頭菜：用泊松分佈來解釋為什麼HashMap的連結串列變樹的閾值是8大頭菜：面試——雙親委派模型