面對動輒幾百上千個虛擬機(jī)、容器，數(shù)十種要監(jiān)控的對象，現(xiàn)有的監(jiān)控系統(tǒng)還能否支撐的??？來自于容器、虛擬機(jī)、物理機(jī)的應(yīng)用日志、系統(tǒng)服務(wù)日志如何采用同一套方案快速、完整的收集和檢索？怎樣的架構(gòu)、技術(shù)方案才更適合如此龐大繁雜的監(jiān)控需求呢？本文主要從以下幾個方面來分享在日志監(jiān)控方面的一些經(jīng)驗。

　　海量數(shù)據(jù)的分析處理挑戰(zhàn) ?設(shè)備越來越多，應(yīng)用越來越多，要監(jiān)控的數(shù)據(jù)自然也排山倒海般襲來，怎樣的監(jiān)控系統(tǒng)才能應(yīng)對大數(shù)據(jù)的采集、存儲和實時分析展現(xiàn)呢？

　　軟硬件數(shù)據(jù)資源的管理分析挑戰(zhàn) ?數(shù)據(jù)是采集到了，采集全了，那么如何對他們進(jìn)行分析呢？應(yīng)用、系統(tǒng)軟件和運行環(huán)境、網(wǎng)絡(luò)、存儲設(shè)備的關(guān)聯(lián)關(guān)系是否能準(zhǔn)確體現(xiàn)呢，某個點發(fā)生了故障、問題影響的鏈路是否能快速找到并進(jìn)行處理呢？監(jiān)控離不開和軟硬件資源管理的結(jié)合。

　　面對這些挑戰(zhàn)，是否感覺壓力山大呢？一個監(jiān)控平臺，擁有哪些能力才能滿足如此大的挑戰(zhàn)呢？

　　高度抽象模型，擴(kuò)展監(jiān)控指標(biāo)：正如之前所說，監(jiān)控源、指標(biāo)的多樣化，要求我們必須要進(jìn)行監(jiān)控模型的高度抽象，并且針對于指標(biāo)可以動態(tài)擴(kuò)展，這樣才能保證監(jiān)控平臺的健壯性和可擴(kuò)展性。

　　多種監(jiān)控視圖：監(jiān)控數(shù)據(jù)自然不能只是簡單的表格展現(xiàn)，餅圖、柱狀圖、折線圖、儀表盤等等，監(jiān)控的數(shù)據(jù)需要結(jié)合實際情況選擇優(yōu)質(zhì)的圖標(biāo)展現(xiàn)。

　　強大的數(shù)據(jù)加工能力：海量的數(shù)據(jù)必須要有足夠強大的數(shù)據(jù)加工、分析處理能力才能得到直觀的結(jié)果。

　　多種數(shù)據(jù)采集技術(shù)：數(shù)據(jù)源的不同決定了采集的技術(shù)也是有區(qū)別的。

　　多種報警機(jī)制：短信、郵件、企業(yè)內(nèi)部通訊工具等等，結(jié)合不同場景選擇不同的報警機(jī)制。

　　全路徑問題跟蹤：一個請求有可能牽扯到數(shù)個系統(tǒng)、數(shù)十個接口的調(diào)用，出了問題有可能是其中任何一個環(huán)節(jié)，也有可能是應(yīng)用所處運行環(huán)境、網(wǎng)絡(luò)、存儲的問題，所以問題的定位離不開全路徑的跟蹤。

　　數(shù)據(jù)采集 ?數(shù)據(jù)源如此多樣，數(shù)據(jù)采集的任務(wù)自然輕松不了。數(shù)據(jù)采集從指標(biāo)上劃分可以分為業(yè)務(wù)指標(biāo)、應(yīng)用指標(biāo)、系統(tǒng)軟件監(jiān)控指標(biāo)、系統(tǒng)指標(biāo)。

　　應(yīng)用監(jiān)控指標(biāo)如：可用性、異常、吞吐量、響應(yīng)時間、當(dāng)前等待筆數(shù)、資源占用率、請求量、日志大小、性能、隊列深度、線程數(shù)、服務(wù)調(diào)用次數(shù)、訪問量、服務(wù)可用性等，業(yè)務(wù)監(jiān)控指標(biāo)如大額流水、流水區(qū)域、流水明細(xì)、請求筆數(shù)、響應(yīng)時間、響應(yīng)筆數(shù)等，系統(tǒng)監(jiān)控指標(biāo)如：CPU負(fù)載、內(nèi)存負(fù)載、磁盤負(fù)載、網(wǎng)絡(luò)IO、磁盤IO、tcp連接數(shù)、進(jìn)程數(shù)等。

　　從采集方式來說通?？梢苑譃榻涌诓杉⒖蛻舳薬gent采集、通過網(wǎng)絡(luò)協(xié)議主動抓?。╤ttp、snmp等）

　　數(shù)據(jù)存儲 ?采集到的數(shù)據(jù)一般都會存儲到文件系統(tǒng)（如HDFS）、索引系統(tǒng)（如elasticsearch）、指標(biāo)庫（如influxdb）、消息隊列（如kafka，做消息臨時存儲或者緩沖）、數(shù)據(jù)庫（如mysql）

　　數(shù)據(jù)分析 ?針對采集到的數(shù)據(jù)，進(jìn)行數(shù)據(jù)的處理。處理分兩類：實時處理和批處理。技術(shù)包括Map/Reduce計算、全日志檢索、流式計算、指標(biāo)計算等，重點是根據(jù)不同的場景需求選擇不同的計算方式。

　　數(shù)據(jù)展現(xiàn) ?將處理的結(jié)果進(jìn)行圖表展現(xiàn)，在多屏?xí)r代，跨設(shè)備的支持必不可少。

　　預(yù)警 ?如果在數(shù)據(jù)處理過程發(fā)現(xiàn)了問題，則需要進(jìn)行異常的分析、風(fēng)險的預(yù)估以及事件的觸發(fā)或告警。

　　CMDB(企業(yè)軟硬件資產(chǎn)管理) ?CMDB在統(tǒng)一監(jiān)控平臺中是很重要的一環(huán)，監(jiān)控源雖然種類繁多，但是他們大都有著關(guān)系，如應(yīng)用運行在運行環(huán)境中，應(yīng)用的正常運行又依賴網(wǎng)絡(luò)和存儲設(shè)備，一個應(yīng)用也會依賴于其他的應(yīng)用（業(yè)務(wù)依賴），一旦其中任何一個環(huán)節(jié)出了問題，都會導(dǎo)致應(yīng)用的不可用。CMDB除了存儲軟硬件資產(chǎn)外，還要存儲這樣一份資產(chǎn)間的關(guān)聯(lián)關(guān)系，一個資產(chǎn)發(fā)生了故障，要能根據(jù)這個關(guān)系迅速得知哪些其他的資產(chǎn)會被影響，然后逐一解決問題。

　　三、日志監(jiān)控的技術(shù)棧

　　既然前面講了整個監(jiān)控系統(tǒng)的架構(gòu)，下面就按照架構(gòu)中的角色來分類看看有哪些常用的開源技術(shù)。由于篇幅原因，這里無法詳細(xì)描述每一個技術(shù)的細(xì)節(jié)，大家感興趣的話，可以一一了解下。

　　日志源

　　syslog 守護(hù)進(jìn)程的任務(wù)是記錄系統(tǒng)日志。它從應(yīng)用程序和服務(wù)中獲取格式各異的日志消息并保存到磁盤上，消息的元數(shù)據(jù)是組件名、優(yōu)先級、時間戳、進(jìn)程標(biāo)簽和 PID，日志格式很是寬泛，沒有定義結(jié)構(gòu)化的格式，所以系統(tǒng)的分析和日志消息處理也就變得十分混亂，同時性能和其他的一些缺點隨著時間推移也慢慢被放大，后來慢慢被Rsyslog所取代。

　　Rsyslog可以說是Syslog的升級版，它涵蓋SysLog的常用功能，不過在功能和性能上更為出色。

　　Red Hat Enterprise Linux 7與SUSE Linux Enterprise Server 12這些新一代的Linux發(fā)行版本使用systemd管理服務(wù)。

　　journal是systemd的一個組件，由journald處理。Journald是為Linux服務(wù)器打造的新系統(tǒng)日志方式，它標(biāo)志著文本日志文件的終結(jié)，它不再存儲日志文件，而是將日志信息寫入到二進(jìn)制文件，使用journalctl閱讀。它捕獲系統(tǒng)日志信息、內(nèi)核日志信息，以及來自原始RAM磁盤的信息，早期啟動信息以及所有服務(wù)中寫入STDOUT和STDERR數(shù)據(jù)流的信息。Journald快速改變著服務(wù)器如何處理日志信息與管理員如何訪問的方式。

　　數(shù)據(jù)采集

　　日志的采集工作大都是通過客戶端進(jìn)行，客戶端除了一些直接可用的工具（如fluentd、flume、logstash）外，還可以通過log4j的appender、自行寫腳本實現(xiàn)等。

　　fluentd是開源社區(qū)中流行的日志收集工具，fluentd基于CRuby實現(xiàn)，并對性能表現(xiàn)關(guān)鍵的一些組件用C語言重新實現(xiàn)，整體性能相當(dāng)不錯。優(yōu)點是設(shè)計簡潔，pipeline內(nèi)數(shù)據(jù)傳遞可靠性高。缺點是相較于logstash和flume，其插件支持相對少一些。

　　flume是由JAVA實現(xiàn)的一個分布式的、可靠的、高性能、可擴(kuò)展的的日志收集框架，F(xiàn)lume比較看重數(shù)據(jù)的傳輸，使用基于事務(wù)的數(shù)據(jù)傳遞方式來保證事件傳遞的可靠性，幾乎沒有數(shù)據(jù)的解析預(yù)處理。僅僅是數(shù)據(jù)的產(chǎn)生，封裝成event然后傳輸。同時使用zookeeper進(jìn)行負(fù)載均衡，不過JVM帶來的問題自然是內(nèi)存占用相對較高。

　　Logstash相比大家都比較熟悉了，是ELK中的L，logstash基于JRuby實現(xiàn)，可以跨平臺運行在JVM上。logstash安裝簡單，使用簡單，結(jié)構(gòu)也簡單，所有操作全在配置文件設(shè)定，運行調(diào)用配置文件即可。同時社區(qū)活躍，生態(tài)圈提供了大量的插件。早期Logstash并不支持?jǐn)?shù)據(jù)的高可靠傳遞，所以在一些關(guān)鍵業(yè)務(wù)數(shù)據(jù)的采集上，使用logstash就不如flume更加可靠。不過在5.1.1版本發(fā)布了持久化隊列的beta版，顯然logstash也在快速改進(jìn)自己的缺陷。

　　數(shù)據(jù)緩沖

　　在大批量的監(jiān)控數(shù)據(jù)涌過來后，考慮到網(wǎng)絡(luò)的壓力和數(shù)據(jù)處理的瓶頸，一般會在存儲前先經(jīng)過一層數(shù)據(jù)緩沖，將采集到的數(shù)據(jù)先放置到消息隊列中，然后再從分布式隊列中讀取數(shù)據(jù)并存儲。這張圖是新浪的日志檢索系統(tǒng)的架構(gòu)圖，可以看到數(shù)據(jù)采集后，經(jīng)過kafka緩沖，然后再使用logstash去讀取kafka中的數(shù)據(jù)并存儲到es中：

　　關(guān)于分布式隊列這里就不詳細(xì)講解了，常用有kafka，rabbitmq，zeromq等。

　　數(shù)據(jù)存儲&分析 ?存儲和分析息息相關(guān)，監(jiān)控數(shù)據(jù)的處理通常分為實時處理和非實時處理（如大數(shù)據(jù)的批處理框架hadoop等），如Elasticsearch就是一個實時的分布式搜索和分析引擎，它可以用于全文搜索，結(jié)構(gòu)化搜索以及分析。

　　除了ES外，還有一些流式大數(shù)據(jù)處理框架可以做到實時或者準(zhǔn)實時的處理大數(shù)據(jù)流。如Spark和Storm。關(guān)于大數(shù)據(jù)處理的內(nèi)容因為本人也沒有多少實踐經(jīng)驗，就不在此多做分享了。后面主要還是針對于Elasticsearch這一框架進(jìn)行介紹。

　　數(shù)據(jù)展現(xiàn) ?Kibana和Elasticsearch可以說是無縫銜接，再加上Logstash，組成的ELK赫赫有名，很多企業(yè)都會直接采用這一種框架。

　　Kibana確實也能滿足大部分的監(jiān)控需求，但是其畢竟只能依靠現(xiàn)有的數(shù)據(jù)進(jìn)行展現(xiàn)，如果需要和外部數(shù)據(jù)結(jié)合處理，就會無法滿足了，并且在自己構(gòu)建一個統(tǒng)一監(jiān)控平臺時，需要將日志和性能等監(jiān)控數(shù)據(jù)結(jié)合CMDB、預(yù)警中心、等統(tǒng)一展現(xiàn)，所以對于kibana的替換就無法避免了。我們是通過使用JAVA去查詢Elasticsearch的數(shù)據(jù)，結(jié)合其他數(shù)據(jù)統(tǒng)一分析，將展現(xiàn)的結(jié)果進(jìn)行滾動展現(xiàn)或者用圖表顯示。

　?。ū疚霓D(zhuǎn)自微信號EAWorld）