施益峰 屠智瑋

中國移動通信集團江蘇有限公司

0 引言

設備日志的收集與分析一直都是運維中至關重要的一環(huán)。最初，運維人員在各臺設備上用傳統(tǒng)的Linux 等工具（如cat、tail、sed、awk、grep 等）對日志進行簡單的分析和處理，以命令級別的操作為主。隨著互聯(lián)網(wǎng)的興起與硬件的更新，日志的產(chǎn)生與體量成幾何倍的增長，分散管理的成本變得越來越高，高級運維人員通過編寫腳本，匯總?cè)罩具M行集中化管理，但查詢耗時長，排障時效性低。

CDN 可實現(xiàn)互聯(lián)網(wǎng)信息源的高速接入和就近訪問，從而改善用戶上網(wǎng)體驗，是運營商增強互聯(lián)網(wǎng)應用能力的重要手段，故CDN 產(chǎn)品競爭愈演愈烈，各個廠家推出的CDN產(chǎn)品群雄逐鹿。隨之帶來的問題也日益凸顯，各CDN 廠商針對自家的產(chǎn)品都推出了一套運維管理平臺，質(zhì)量參差不齊，存在分析優(yōu)化需求響應慢、開發(fā)周期長、對外互不兼容等問題，使得運營商在管理時過于繁瑣，運維效率低下。運營商如果能把各CDN 廠商的日志進行集中管理，并提供全文檢索功能，不僅可以提高診斷的效率，而且可以實現(xiàn)實時系統(tǒng)監(jiān)測、網(wǎng)絡安全、事件管理等功能，從而使運營商突破各CDN 廠家間的壁壘，擺脫各維護平臺彼此孤立的困境。依托統(tǒng)一分析平臺集中監(jiān)控各平臺的運行情況，由此開展集中調(diào)度與運營。基于此，本文向大家推薦一款開源利器——ELK 組件（Elastic Stack），提供分布式實時日志（數(shù)據(jù)）搜集和分析的監(jiān)控系統(tǒng)。

1 架構介紹

ELK 組 件 是 由Elasticsearch、Logstash、Kibana 三 個核心組件首字母組成的簡稱，在Logstash 前端增加了一個Beats 模塊，是輕量級采集程序的統(tǒng)稱，比較常見的有：Filebeat、MetricBeat、PacketBeat、HeartBeat 等。本 文 主 要針對CDN 業(yè)務日志進行采集，因此選擇專門用于收集日志數(shù)據(jù)的Filebeat，如圖1 所示。

圖1 ELK 架構

1.1 日志采集模塊——Filebeat

輕量級的日志采集器Filebeat，內(nèi)置有多種模塊（auditd、Apache、NGINX、System、MySQL 等），可針對常見格式的日志簡化收集過程。將其部署在CDN 系統(tǒng)的各類服務器（業(yè)務服務器、日志服務器、信安服務器等），轉(zhuǎn)發(fā)、匯總?cè)罩九c文件。此工具采用背壓敏感協(xié)議，實時監(jiān)測傳輸通道的擁堵情況，合理控制傳輸負載，減輕后端壓力。

1.2 日志解析模塊——Logstash

Logstash對接數(shù)據(jù)源，是負責搜集、分析、過濾日志的工具。它支持幾乎任何類型的日志，包括系統(tǒng)日志、錯誤日志和自定義應用程序日志。它可以從許多來源接收日志，這些來源包括 syslog、消息傳遞（例如RabbitMQ）和JMX，在日志匯總處理后，能以多種方式輸出數(shù)據(jù)，包括電子郵件、websockets 和Elasticsearch。

1.3 日志存儲模塊——Elasticsearch

Elasticsearch 是實時分析的分布式搜索引擎，是Elastic Stack 的核心，提供搜集、分析、存儲數(shù)據(jù)三大功能。使用倒排索引，并減少磁盤隨機讀取次數(shù)，采用內(nèi)存壓縮算法來提升查詢效率。

1.4 分析呈現(xiàn)模塊——Kibana

Kibana 是基于Web 形式的ELK 前端展示工具，可管理、搜索、查看存儲于Elasticsearch索引中的數(shù)據(jù)，并配合多種圖表，例如餅圖、折線圖、熱力圖等，進行高級的聚合分析，創(chuàng)建滿足各項需求的可視化報表。

2 實驗部署

2.1 環(huán)境搭建

實驗環(huán)境由4 臺戴爾R720 服務器來搭建，采用CentOS 7 系統(tǒng)。用其中一臺服務器（以下簡稱Server1）來部署Logstash、Kibana，進行日志的收集與Web 服務器的搭建；剩余三臺服務器（以下簡稱Server2、3、4）搭建Elasticsearch 集群，采用主、備節(jié)點的方式，在每臺設備上創(chuàng)建2 個節(jié)點。

由于節(jié)點數(shù)已達到6 個，且Server1 在Logstash 和Kibana搭建后還留余足夠的硬件資源，為了更好的實現(xiàn)管理，在Server1 上搭建了負載均衡（SLB）節(jié)點，將所有的寫入、查詢操作均通過這個節(jié)點來分配任務，使整套Elastic Stack 變得完整、靈活。

至此，由4 臺服務器組成的集群如下：1 個Logstash 節(jié)點，1 個Kibana 節(jié)點，1 個集群負載均衡節(jié)點，8 個Elasticsearch 節(jié)點，共11 個節(jié)點。如圖2 所示。

圖2 Kibana 上可視化的節(jié)點信息監(jiān)控

2.2 日志接入

移動CDN 涉及多個廠家，先嘗試將某個CDN 廠商的日志進行接入適配，其他廠家后續(xù)只需針對日志格式和字段含義作相應改動即可快速移植。該CDN 廠商日志包含19 個主要字段，日志格式：%h %i %s %t %a %R %m %e %d %u %l %p %T %c %f %P %N %r %b，具體字段說明如表1 所示。

表1 日志格式

掌握CDN 日志格式及各字段含義后，將日志接入ELK系統(tǒng)需要三步：（1）Logstash 配置，實現(xiàn)對日志字段的映射適配；（2）Filebeat 配置，實現(xiàn)對CDN 服務器進行數(shù)據(jù)采集；（3）Kibana 配置索引，實現(xiàn)Web 界面展示。具體部署配置方法見下文詳細描述。

2.2.1 Logstash 適配

Logstash 配置文件中分為input、日志字段映射、output 三個部分。

（1）在Logstash 中新增該日志適配文件，配置input，此段設定日志通過Filebeat 上傳至Logstash 的接口通道。如圖3中紅框（1）所示。

（2）根據(jù)日志的格式進行映射描述。本次接入日志格式是用空格來隔開字段，所以在配置映射轉(zhuǎn)換前先進行配置，再根據(jù)表1 中的“日志說明”進行對應的字段排列，一一轉(zhuǎn)換為Logstash 能識別的格式。再根據(jù)部分字段性質(zhì)的不同，對取值結(jié)果進行“integer、float”二次加工，最后標記時間戳，在接收到日志時對其進行標注，方便管理。如圖3 中紅框（2）所示。

（3）設定output，此處配置決定了日志通過Logstash 過濾、處理后，上傳至Elasticsearch 的接口通道。在host 處填寫Elasticsearch 的負載均衡節(jié)點IP 與對應端口，將處理完成的日志按照“廠商+時間戳”的格式，形成一份索引，方便將同廠商日志在Kibana 上進行匯聚管理。如圖3 中紅框（3）所示。

圖3 Logstash 日志識別配置

2.2.2 Filebeat 采集

配置Filebeat.yml 文件，在input 打開日志收集功能，paths填入服務器收集日志的路徑，在output 處填上Logstash 的地址與接口。為了更方便的標記我們所接入的設備，建議在最下方加上一個“tag”，用于表示主機、歸屬、廠商、業(yè)務等信息。

2.2.3 Kibana 呈現(xiàn)

將配置完成的Filebeat 部署在需要收集日志的服務器，與Logstash 端網(wǎng)絡打通后，即可按配置好的路徑進行日志的抓取，并實時向Logstash 傳輸。

在Logstash 接收到日志后，執(zhí)行已生效的配置，歸檔為索引后傳輸給Elasticsearch。至此，我們就可以登錄Kibana，在側(cè)邊菜單欄中的Management 下進入/Elasticsearch/Index Management 路徑，看到已經(jīng)上傳成功的“test_2019.xx.xx”索引，附帶上該索引的健康狀態(tài)、副本數(shù)、已錄入的日志條數(shù)、已使用的存儲大小等信息。代表著從服務器Filebeat（日志上傳）→Logstash（日志收集）→ElasticSearch（分析處理）→Kibana（Web展現(xiàn)管理）全流程的打通。

在Kibana 菜單欄的首位——Discover 下，可以看到接入的日志已按照Logstash 中配置的字段映射，被拆分成易于檢索的單個字段。在日志詳單的左邊，還能看到單個字段在當前的時間段內(nèi)將每條日志對應的信息進行匯總處理后，計算出單位時間內(nèi)的字段類型占比，如圖4 所示。

圖4 Kibana Discover 菜單中的日志索引展示

3 現(xiàn)網(wǎng)應用

經(jīng)過上述實驗，已成功實現(xiàn)CDN 日志采集、分析、Web呈現(xiàn)的全流程，對接入日志的字段進行適配，并添加索引后，便可以在Kibana 的核心組件Visualization 中創(chuàng)建熱力圖、直方圖、餅圖、時間軸等各類數(shù)據(jù)可視化視圖。如法炮制實現(xiàn)其他CDN 廠家日志接入ELK 系統(tǒng)，并逐步批量覆蓋全省所有CDN 廠家的所有CDN 服務器。

圖5 Kibana Visualization 菜單

在內(nèi)容網(wǎng)絡CDN 業(yè)務中，通過HTTP 狀態(tài)碼來判斷業(yè)務質(zhì)量是最直觀、基礎的；以狀態(tài)碼數(shù)量統(tǒng)計出的“服務成功率”也是CDN 業(yè)務中常見指標之一。以此指標為例，進行指標隨時間變化的視圖創(chuàng)建。

通過篩選，采用Visualization 中的Visual Builder 來自定義實現(xiàn)：選擇日志對應的建立好的索引，進入配置視圖：“Aggregation”選項中提供了將索引中的字段進行平均、基數(shù)、百分比、過濾比率、方差、熱門點擊等豐富的匯聚選項。由于服務成功率指標是由HTTP 狀態(tài)碼的錯誤/正常的數(shù)量比率來計算的，因此選擇Filter Ratio（過濾比率）來將字段“httpstatus”中全量計數(shù)作為Denominator 分母，將其中的5xx 計數(shù)作為Numerator 分子，以實現(xiàn)根據(jù)時間軸來計算HTTP 錯誤碼數(shù)占服務總數(shù)的比值曲線。

圖6 Kibana 請求失敗率視圖展示

單純觀察所有日志匯總后的HTTP 錯誤碼曲線，依舊無法具體定位故障點，且匯總后數(shù)據(jù)量過大，當部分業(yè)務錯誤率突增，不足以影響全量數(shù)據(jù)時，無法體現(xiàn)。因此，在接入的業(yè)務、節(jié)點越來越多的情況下，需要在現(xiàn)有視圖的基礎上進行衍生：

（1）分組維度

某些廠商的CDN 業(yè)務分組數(shù)量眾多，不同的分組代表不同的節(jié)點，也對應了不同的業(yè)務，匯聚后定位識別困難。

通過對服務器節(jié)點信息字段的關聯(lián)，可將原視圖上某廠商CDN 日志全量匯總的單一曲線，轉(zhuǎn)由該廠商CDN 分組為單位的多條曲線，實現(xiàn)多分組多業(yè)務的服務狀態(tài)監(jiān)控，方便運維人員進行定位和排查，實際效果如圖6 所示。

（2）業(yè)務域名維度

某些廠商的CDN 業(yè)務架構不同，分組數(shù)量少，同分組內(nèi)同時服務多個業(yè)務，日志匯聚后需要進行區(qū)分識別。

由于日志字段中沒有域名字段，無法直接選擇進行字段關聯(lián)，因此，對攜帶域名信息的“URL 字段”進行識別、提取。URL的格式是規(guī)范統(tǒng)一的，所以可在Logstash中對“URL字段”進行過濾，根據(jù)“/”的分割，取得對應域名字符，并映射為新字段，完成“域名字段”的創(chuàng)建。

通過對域名字段的關聯(lián)，可將該CDN 分組內(nèi)的混合業(yè)務日志，清楚地由域名維度區(qū)分識別，實現(xiàn)單分組內(nèi)多個業(yè)務的服務狀態(tài)監(jiān)控。

（3）物理設備維度

某些CDN 節(jié)點承載重要業(yè)務，或承擔負載均衡、調(diào)度管理等重要職責，需要對此類節(jié)點設備進行重點監(jiān)控。因此，需要詳細至單臺設備IP 維度進行監(jiān)控。但是，部分設備上報日志、特殊設備收集信息中不包含設備IP 信息，只能選擇在設備上傳數(shù)據(jù)至Logstash 前，通過Filebeat 在output 配置對應設備IP、歸屬等信息進行標識，再由Logstash 中映射新字段后完成創(chuàng)建。

通過對設備IP 字段的關聯(lián)，可對重點關注設備進行詳細監(jiān)控，實現(xiàn)單分組內(nèi)多設備點對點監(jiān)控，第一時間發(fā)現(xiàn)異常設備，進行應急處理，及時止損對業(yè)務的影響。

通過上述三種維度衍生配置出的報表可以直觀、實時地展現(xiàn)業(yè)務服務情況隨時間趨勢的變化，發(fā)現(xiàn)其中某個分組、某個業(yè)務的服務狀態(tài)異常。但是，對于業(yè)務分組內(nèi)服務的數(shù)個網(wǎng)站、域名、報錯信息等進一步詳細信息，還是無法知曉并具體定位是哪些服務受到了影響。

Kibana 上豐富靈活的視圖，可以通過自由組合來進一步多維度地展現(xiàn)數(shù)據(jù)分析的信息。通過Pie 視圖，以配置服務域名字段/報錯信息為基準，同時篩選并關聯(lián)業(yè)務分組與HTTP錯誤碼兩個字段，并配置需要查詢的時間段，即可將此Pie 視圖聯(lián)合Visual Builder 視圖共同定位至服務異常的具體業(yè)務，實現(xiàn)多分組多業(yè)務中，將Top 錯誤域名、Top 報錯信息，同步實時呈現(xiàn)。如圖7 所示。

圖7 多維監(jiān)控報表展示

至截稿前，筆者通過不斷對該分析系統(tǒng)的更新與迭代，已可按地市節(jié)點、服務分組、業(yè)務域名、物理設備等維度可視化呈現(xiàn)，并可通過將狀態(tài)碼、命中率、時延、下載速率、流量、碼率等指標關聯(lián)下鉆分析定位質(zhì)差，成功發(fā)現(xiàn)數(shù)十起CDN 業(yè)務因設備硬件故障、上游回源異常、本地軟件錯誤等情況導致的業(yè)務波動影響。與此同時，利用靈活的自定義特性與合理高效的檢索架構，實現(xiàn)了多廠家平面日志的匯聚展現(xiàn)，突破運營商在現(xiàn)網(wǎng)運維中面臨的困境，極大提高CDN 運營能力與排障效率。

4 結(jié)束語

本文主要是從“基于Elastic Stack 對CDN 業(yè)務多平面日志分析系統(tǒng)的架構、搭建與實現(xiàn)”入手，對每一部分展開說明。本系統(tǒng)降低了日志管理分析的成本，在日志的收集處理、檢索分析和展示方面，凸顯出良好的靈活性與包容性，能有效協(xié)助運營商解決單業(yè)務系統(tǒng)內(nèi)多個廠家各自獨立、互不兼容的“老大難”問題，提升運維效率。目前該系統(tǒng)已推廣至互聯(lián)網(wǎng)電視等業(yè)務領域，其他需進行日志分析的專業(yè)領域均可參照此文介紹的部署方法平滑便捷地移植。

本文只是對ELK 系統(tǒng)的初步探索，此系統(tǒng)各個組件都擁有豐富友好的開源接口，下一步將繼續(xù)研究，加入Python 等其他優(yōu)秀的開源技術，深挖優(yōu)化日志分析平臺，依托此平臺實現(xiàn)多業(yè)務多平面日志的統(tǒng)一采集、匯聚呈現(xiàn)與分析預警。