天津臺新聞云日志優(yōu)化方案探索

陳春銘

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

1 新聞云系統(tǒng)

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

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

2 日志管理

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

2.1 手動清理

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

2.2 修改日志輸出級別

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

2.3 自動清理

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

3 新聞云日志優(yōu)化實例

3.1 新聞云主要日志分類

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

3.2 系統(tǒng)日志

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

圖1 參數(shù)設(shè)置報錯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，確認(rèn)沒有報錯后，觸發(fā)配置使其生效logrotate /etc/logrotate.conf，最后重啟日志服務(wù)systemctl restart rsyslog。

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

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

3.3 應(yīng)用服務(wù)Kafka日志

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

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

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

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

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

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

圖3 清理策略參數(shù)Fig.3 Cleaning policy parameters

解決辦法如下：

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

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

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

4 結(jié) 語

日志是把“雙刃劍”，一方面它能夠為系統(tǒng)維護(hù)、優(yōu)化改造提供信息輔助，另一方面它也能夠成為系統(tǒng)運行的安全隱患。在實際工作中，要重點關(guān)注日志的變化，根據(jù)網(wǎng)絡(luò)的運行和實際需求，優(yōu)化日志參數(shù)配置，盡可能減少空間的占用。