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

哈嘍哈嘍你們猴，我是把代碼寫成bug的大頭菜。公衆號：大頭菜技術(bigheadit)。原創不易，但歡迎轉載。

今天不知道爲啥醒得特別早，可能就是緣分吧。醒來一看微信，就發現線上的服務器的磁盤使用率超過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順利解決了。就是查看容器的命令，到如今也沒找到。若是你有辦法，留言通知我！感謝！