陳春銘

(天津廣播電視臺(tái) 天津300072)

1 新聞云系統(tǒng)

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

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

2 日志管理

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

2.1 手動(dòng)清理

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

2.2 修改日志輸出級(jí)別

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

2.3 自動(dòng)清理

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

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

3.1 新聞云主要日志分類

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

3.2 系統(tǒng)日志

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

圖1 參數(shù)設(shè)置報(bào)錯(cuò)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)沒有報(bào)錯(cuò)后，觸發(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é)點(diǎn)的應(yīng)用數(shù)據(jù)盤空間使用率達(dá)到75%，隨著時(shí)間的推移，數(shù)據(jù)還在不斷增長(zhǎng)中，由于hive 核心服務(wù)及數(shù)據(jù)都保存在此盤，若空間不足，雖然不會(huì)影響操作系統(tǒng)，但是單個(gè)節(jié)點(diǎn)應(yīng)用服務(wù)會(huì)出現(xiàn)響應(yīng)緩慢或者無法對(duì)外提供服務(wù)，一旦有3 個(gè)及以上核心節(jié)點(diǎn)出現(xiàn)此問題，那么整個(gè)集群就會(huì)崩潰。另外底層數(shù)據(jù)庫(kù)文件都在此盤上，可能會(huì)造成數(shù)據(jù)庫(kù)無法寫入新數(shù)據(jù)，整個(gè)業(yè)務(wù)系統(tǒng)完全不能服務(wù)。

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

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

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

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

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

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

解決辦法如下：

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

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

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

4 結(jié) 語(yǔ)

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