天津臺新聞云日志優化方案探索

陳春銘

(天津廣播電視臺 天津300072)

1 新聞云系統

新聞云制作域使用的是Sobey 公司的MCH 1.2版本，該版本包含了前端客戶端編輯軟件和后臺核心服務hive。通過運行時期的積累摸索，已經基本掌握了其核心組織架構及各模塊功能原理，在日常工作中服務出現問題時能夠及時判斷和解決，并結合實際應用對節點和服務進行相應的改進和擴容。一方面解決了網內服務bug，另一方面提高了系統性能。目前Sobey 已經推出了MCH 2.0 版本，并建議1.2 升級到2.0 以提升系統穩定性，但是該版本在友臺實際運行中會產生新問題，比如核心服務和客戶端時間一旦有誤差可能會影響整個制作。綜合考量認為，天津廣播電視臺暫不升級，繼續使用原版本，在此基礎上深入排查網內潛在隱患，結合以往經驗，重點關注資源性能參數，最大程度提高系統穩定性，保障新聞安全播出。

系統的穩定運行，離不開日常對資源的維護，包括內存、CPU、磁盤使用率等。內存和CPU 可以通過定期重啟釋放資源，而磁盤空間的增長變化，除了系統軟件自身數據外，有一大部分是由日志記錄造成，當日志文件不斷增長，磁盤空間占用過多，寫日志的速度和性能也會隨之下降，嚴重的會導致系統或服務崩潰，因此深究新聞云相關日志是重中之重。

2 日志管理

日志也可稱為Log，是指系統所指定對象的某些操作和其操作結果按時間有序的集合，日志記錄構成了一個日志文件，它記錄了系統運行中的重要信息，方便出現問題快速分析判斷，同時需要對日志進行及時清理，來保證正常信息記錄和系統穩定運行。對于日志處理目前主要有3 種方式。

2.1 手動清理

由于日志種類較多，記錄信息不同，作用也不同，在手動刪除之前，需要確定哪些可刪除，哪些不能刪除，對于重要的日志應當進行備份。對于復雜系統而言，手動刪除工作量繁重，而且也會有誤刪除風險。例如新聞云MySQL 數據庫歸檔日志采用手動刪除，按月保留。

2.2 修改日志輸出級別

日志輸出分為多個級別，如DEBUG＜INFO＜WARN＜ERROR＜FATAL，每個級別輸出信息不同。新聞云核心服務多采用Log4j 日志記錄工具，程序會打印高于或等于所設置級別的日志，因而根據需求設置合適的級別，會減少日志打印，降低日志空間。但是并不是設置越高越好，新聞云中由于hive 各服務關聯性強，對于某些服務需要輸出全信息，方便分析問題。

2.3 自動清理

按照需要對服務配置自動刪除策略，一是按照時間刪除，保留N 天前的日志，二是按照大小刪除，也可以采用日志管理工具如logrotate 對日志進行定期切割。相比手動，自動清理更加有效和可靠。新聞云核心服務大多采用自動刪除方式，參數配置要根據運行情況進行改進，實現最優化。

3 新聞云日志優化實例

3.1 新聞云主要日志分類

新聞云后臺核心是hive，應用服務部署在8 臺Linux 虛擬機上，主要有兩種日志。一是虛擬機系統日志，該日志默認存放在/var/log/下，記錄系統有關事件和信息。系統日志采用logrotate 進行管理，它是一個強大的日志管理工具，基于cron 對日志進行輪循、壓縮以及刪除舊的日志文件，是系統自動完成的。二是應用服務日志，統一掛載存放到sobeyhive/log，記錄hive 各服務運行信息。同時sobeyhive 目錄下還存放著應用服務app 及數據文件data。Kafka 服務比較特殊，日志輸出到data 文件。由于日常工作通過df-h發現各節點系統空間及前5 個核心節點應用數據空間不足，具有很大安全隱患。使用du -h - -max-depth＝1查出是Linux 系統和應用服務Kafka 日志過大導致，故需要對二者及時進行處理。

3.2 系統日志

系統日志文件偏大，有些節點的message 日志文件已經超過10 G。由于該日志占用系統空間，若不及時清理，會造成系統空間不足進而導致該節點應用服務響應緩慢，或無法對外提供服務，嚴重時會引起系統崩潰或重啟，如果集群中超過半數服務器發生該故障，那么整個集群就會癱瘓。按照logrotate 配置，正常情況下每周自動對日志進行切割，并保留4 個備份，但是多個文件例如message、secure 超過一周沒轉儲，日志輪循沒有生效。后經排查發現系統日志配置文件syslog 中參數設置錯誤如圖1，在獲取root 權限時，只設置了root 用戶，沒有設置組，該值缺省配置時會出現如下報錯，從而造成了日志轉儲失敗。解決方法：使用sed 行編輯器對節點配置文件進行統一更改。

圖1 參數設置報錯Fig.1 Parameter setting error

①sed -i '/^su/d' /etc/logrotate.d/syslog 將開頭是su 的行刪除。

②sed -i '1isu root root' /etc/logrotate.d/syslog 在第1 行插入su root root，添加組配置，使用root 用戶root 組收集514 端口的syslog 日志。

③重新檢查配置文件 logrotate/etc/logrotate.d/sys-log，確認沒有報錯后，觸發配置使其生效logrotate /etc/logrotate.conf，最后重啟日志服務systemctl restart rsyslog。

查看/var/log 下日志文件大小，恢復正常。相比維護前，清理了大約14 G 日志，如圖2。系統空間得到了釋放。

圖2 轉存前、后的空間比較Fig.2 Comparison of space before and after storage

3.3 應用服務Kafka日志

Kafka 日志過大，使得核心服務節點的應用數據盤空間使用率達到75%，隨著時間的推移，數據還在不斷增長中，由于hive 核心服務及數據都保存在此盤，若空間不足，雖然不會影響操作系統，但是單個節點應用服務會出現響應緩慢或者無法對外提供服務，一旦有3 個及以上核心節點出現此問題，那么整個集群就會崩潰。另外底層數據庫文件都在此盤上，可能會造成數據庫無法寫入新數據，整個業務系統完全不能服務。

Kafka 是基于zookeeper 協調的分布式消息服務，也稱為消息隊列，能夠實時處理大量數據，為整個平臺提供消息訂閱功能，具有高吞吐、低延遲、高并發特點。它的日志刪除策略有兩種：一是按照一定策略刪除不符合條件的日志分段(包括時間和大小)；二是對日志進行壓縮，對每個消息的key 進行整合。Kafka 包含多個topic，把topic 中一個partion 大文件分成多個小文件段，然后通過多個小文件段，定期從系統刪除。新聞云中每個topic 只有一個partion。但是發現有的分段日志文件無法自動刪除，導致占用空間越來越大。查看配置文件，沒有異常。

log.cleanup.policy＝delete //日志清理策略

log.retention.hours＝168 //日志保存時間為7 天

log.cleaner.enable＝true // 開啟日志刪除功能

通過腳本get_kafka_topics_info.sh 查看topic 信息，發現個別隊列清理策略為compact 壓縮模式，如圖3，這表明該隊列日志會一直保留，7 天刪除策略不會對其生效。但若一直保留就會造成空間不斷增加，因而需要對配置參數進行優化，將刪除策略是compact 的topic 隊列設置為delete 模式。

圖3 清理策略參數Fig.3 Cleaning policy parameters

解決辦法如下：

在每個節點執行delete_kafka_topics_config.sh，該腳本會刪除compact 配置，使topic 隊列清理策略都成為delete 模式，然后重啟kafka 集群，執行完成后，系統開始清理過期的kafka 日志文件，應用數據空間得到了釋放。

相比維護前，每個節點大約刪除了100 G 的日志，sobeyhive 磁盤空間使用率降低了25%左右，如圖4。

圖4 清理前、后的空間比較Fig.4 Comparison of space before and after cleaning

4 結 語

日志是把“雙刃劍”，一方面它能夠為系統維護、優化改造提供信息輔助，另一方面它也能夠成為系統運行的安全隱患。在實際工作中，要重點關注日志的變化，根據網絡的運行和實際需求，優化日志參數配置，盡可能減少空間的占用。