背景
在端午期間，突然收到訊息說，sentry 服務無法訪問了，請求總是出現 502 頁面響應。揣著忐忑不安的心情 ♥ 開始了排查之旅。
查因
- 從哪下手？
伺服器的記憶體滿了嗎？
a. 如果沒有記憶體了，那麼伺服器也登入不上。
b. 如果沒有記憶體，那麼訪問也將不會出現 502 響應，而是打不開服務了。
c. 登入伺服器後執行free -h檢視，伺服器的記憶體還有一定的剩餘，好的?，這個確認安全。為啥會突然停止執行呢？
sentry 服務是採用官方提供的搭建方案中的 docker 方式作為服務執行於伺服器上，前幾天都還好好的。
- 先檢查一下伺服器的相關 sentry 服務是否正常執行。
docker ps -a 得到如下結果，sentry 相關的服務中，有 3 個相關容器處於 Restaring 狀態。
- 服務為啥無法啟動，為啥一直處於 Restaring 狀態？
通過對容器的進行日誌的逐個檢視，初探端倪
docker-compose logs -tail 200 postgres: No space left on device，重啟服務時，因無可用剩餘空間，所以無法啟動了。
- 伺服器真的沒有可用剩餘空間了嗎？
通過執行命令 df -h /，得知伺服器的磁碟空間使用接近 100%，真的沒有空間了。
知果
通過一番排查，我們知道了 sentry 服務無法執行的原因了。那接下來該對伺服器磁碟進行清理了。
- docker 服務是否有限制日誌輸出選項？
通過 cat /etc/docker/daemon.json 檢視伺服器啟動配置得知，日誌驅動使用的是 json-file，日誌配置選項為每個容器保留 3份日誌檔案，每份檔案最大大小為 100M。
- sentry 服務是否有配置日誌輸出選項？
通過 cat /path/to/onpremise/docker-compose.yml 檢視 sentry 服務的 docker-compose 編排檔案，可以得知與 docker 服務一致，日誌驅動使用的是 json-file，日誌配置選項為每個容器保留 3份日誌檔案，每份檔案最大大小為 100M。
- 是 docker 相關的服務輸出的日誌太多嗎？
a. 是 sentry 執行時間過長，報錯太多導致資料庫中的資料過多嗎？
通過一番搜尋，找到了文章 Sentry 服務磁碟佔滿 清除postgresql方法
對文章的閱讀後發現，sentry 已無法執行，不能通過手動清理日誌來減少磁碟空間，不過關於自動清理超過七天的記錄還是有點用處，遂參考文章加上了相關配置。
b. 配置 docker 伺服器日誌輪轉
又一番搜尋後，似乎看到了希望，Kubernetes之容器資料寫滿磁碟解決方法
參考文章中的具體優化方法，檢查 docker 服務，已有相關配置。
- 到底是什麼佔用了伺服器 40G 的磁碟空間?
a. 檔案系統磁碟被誰使用了？
通過 df -lh | sort -h 檢視磁碟當前佔用情況排序
得知 /var/lib/docker/aufs/mnt/ 佔用了大多數的空間。
b. 磁碟中哪些目錄佔用了較大的空間？
通過 du -hd 1 / | sort -hr 檢視磁碟使用情況
得知 /var 目錄佔用了 23G 的磁碟空間。
c. 對每個空間佔用大於 1G 的目錄進行子一級目錄的目錄使用情況統計
得知 /var/log 目錄日誌使用了 17G 的空間，單單事件記錄監控程式日誌就達到了 16G 的空間。
- 開始清理日誌吧
因 log 目錄下部分日誌有點特殊，不是存文字檔案，故參考 linux log 及如何清除log，對日誌做了一些清理：
a. 刪除 /var/log 下的日誌壓縮包rm -rf /var/log/*.gz
b. 刪除 /var/log 輪轉日誌rm -rf /var/log/*.1
c. 清空核心日誌cat /dev/null > /var/log/dmesg
d. 清空 Linux 作業系統常見的系統和服務錯誤資訊cat /dev/null > /var/log/messages
e. 清空事件記錄監控程式日誌cat /dev/null > /var/log/syslog
末：單伺服器釋放了 17G 的磁碟空間
最後，一番操作後，單伺服器釋放了 17G 的磁碟空間。
總結
- 操作需謹慎
- 多多利用排序，能便於排查問題。
- 提早做好相應工作，能減少臨時處理問題的可能性
給大家幾個方便使用的小命令：
檢視伺服器記憶體使用情況free -h
檢視磁碟當前佔用情況df -h /
檢視磁碟當前佔用情況排序df -lh | sort -h
檢視磁碟使用統計du -hd 1 / | sort -hr
尾聲
文章首發於個人部落格
如有疑問或建議，歡迎留言交流
本作品採用《CC 協議》，轉載必須註明作者和本文連結