是誰把我的伺服器硬碟撐爆了！是誰！

大家好，我是程式設計師魚皮。之前有同學問：為什麽反復強調學編程時一定要把計畫上線？而不是跟著教程敲完、能本地執行就結束了？

答案很簡單，企業中的計畫都是上線的，你進入工作後要處理很多線上的問題。很多 Bug 是只有計畫上線後才會經歷的，也只有處理過這些 Bug，你的經驗值才會持續上漲。

今天給大家分享的就是我自己處理一個線上問題的故事。

故事 事故

我估計不少同學都經歷過自己電腦硬碟空間不足的煩惱吧，但想必大多數程式設計師朋友沒有經歷過伺服器硬碟空間不足的問題。

我還真經歷過，記得那是我在騰訊做開發的第二年，有一天突然收到了一個告警，說是我的伺服器硬碟空間即將被占滿，讓我及時處理。

收到這個告警時，我是懵逼的，因為我部署到這個伺服器上的計畫並沒有涉及什麽檔寫入，公司伺服器硬碟還挺大的，怎麽突然空間就滿了呢？

於是我使用 Linux 命令進一步排查，比如下面這個命令：

du -h --max-depth=1 | sort -hr | head -n 10


這行命令的作用是：列舉磁盤上占用空間前 10 的目錄和占用空間大小。

一下就查到了元兇，竟然是某個計畫的日誌檔，占了 70% 的空間！

我相信大家平時自己做計畫的時候，很少會關註日誌檔占用的大小，一般計畫量級不大也沒什麽影響。但如果計畫長期執行，哪怕每天 100 mb 的日誌，一年也會占用幾十個 G 了，不容小覷。

有意思的是，產生這些日誌檔的計畫，還不是我自己的，是其他用這個伺服器的同事的計畫！所以為啥說計畫要盡量獨立部署、可以用容器去做隔離呢，共用伺服器一旦出事，所有計畫就 「連坐」 了。

解決方案

硬碟不足可能會給程式帶來很多問題，比如計畫無法啟動、臨時檔無法建立、日誌檔無法寫入等等。輕則影響業務功能，重則服務宕機，所以不得不引起重視。

正好昨天編程導航的魚友問我：「自己公司的計畫每天幾十 G 的日誌，硬碟不足，怎麽處理？」

那下面我就分享下自己關於日誌處理的經驗。

1、日誌控制

這是最簡單方法，比如精簡日誌的內容：盡量使用簡短的英文提示語代替中文，能查詢出關鍵資訊即可，能省則省。

還有對日誌級別的控制。日誌一般分為DEBUG、INFO、WARN、ERROR 等級別，可以根據不同的環境動態調整輸出級別，比如在生產環境通常設定只輸出 INFO 或 WARN 及以上等級的日誌，在開發環境或診斷問題時才臨時輸出 DEBUG 級別的日誌。

2、日誌輪轉

使用日誌輪轉機制（logrotate），可以根據時間或檔大小自動講日誌進行切分和壓縮、甚至是清理，防止日誌無限增長。

比如按照日維度和日誌級別對日誌進行切分和壓縮，可能看到下面的檔列表：

很多日誌框架都內建了日誌輪轉功能，去網上找一段配置就可以了，不多說。

3、日誌清理和轉儲

可以定期將部份歷史日誌進行清理，或者壓縮後移動到更便宜的儲存上（比如物件儲存的冷儲存），用程式寫個定時任務或者指令碼就能實作。

也可以自己設定一些策略，比如 7 天清理一次 INFO 級別的日誌、14 天轉儲一次 ERROR 日誌。

4、日誌管理系統

自己做計畫時，為了方便，日誌一般寫入並儲存到伺服器上即可。但如果日誌量級大了，可能就要考慮使用集中化的日誌管理系統，比如典型的分布式日誌 ELK（Elasticsearch + Logstash + Kibana），可以將日誌統一采集、儲存到多台伺服器上並支持線上分析。這樣不僅能夠減輕單台伺服器的磁盤壓力、便於擴容硬碟、還可以更方便地進行日誌搜尋和分析，不用自己寫 Linux 命令從日誌檔中提取文本了。

但搭建和維護 ELK 的成本是比較大的，小公司未必要使用。大廠一般會有統一的分布式日誌收集系統，而且由專門的技術團隊維護，我們各個業務側的開發同學直接透過 SDK 或日誌采集 agent 來將自己的日誌接入到系統即可。這樣不用擔心因為日誌占用磁盤問題導致計畫故障。但是使用日誌收集系統不意味著我們就能放肆地浪費空間了，維護團隊也會設定一個規則，比如日誌只能保留一段時間，如果要長期保留，可能要消耗自己部門的預算之類的。

5、選擇合適的日誌框架

有些日誌框架可能硬碟空間不足後就會報錯、甚至阻塞程式執行、讓 CPU 負載超標等。建議選擇像 Logback 這種日誌框架，在硬碟不足時，不會寫入日誌，也不會影響程式；等有硬碟空間了，又會繼續寫入。

當然，如果經過認真的分析和方案設計，一定要同時記錄和儲存那麽多日誌，又沒有足夠的硬碟空間（典型的 「我全都要」），那就找領導加硬碟、加預算，別什麽都自己默默承受~

不過無論如何，建議給伺服器的硬碟配置監控，一般用大廠的雲伺服器時，用控制台配置一下就好。

👇🏻 點選下方閱讀原文，獲取魚皮往期編程幹貨。

往期推薦