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

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

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

　　面對(duì)這些挑戰(zhàn)，是否感覺(jué)壓力山大呢？一個(gè)監(jiān)控平臺(tái)，擁有哪些能力才能滿(mǎn)足如此大的挑戰(zhàn)呢？

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

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

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

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

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

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

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

　　從采集方式來(lái)說(shuō)通?？梢苑譃榻涌诓杉?、客戶(hù)端agent采集、通過(guò)網(wǎng)絡(luò)協(xié)議主動(dòng)抓?。╤ttp、snmp等）

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

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

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

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

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

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

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

　　日志源

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

　　Rsyslog可以說(shuō)是Syslog的升級(jí)版，它涵蓋SysLog的常用功能，不過(guò)在功能和性能上更為出色。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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