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

　　海量數據的分析處理挑戰 ?設備越來(lái)越多，應用越來(lái)越多，要監控的數據自然也排山倒海般襲來(lái)，怎樣的監控系統才能應對大數據的采集、存儲和實(shí)時(shí)分析展現呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　日志源

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

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

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

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

　　數據采集

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

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

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

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

　　數據緩沖

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

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

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

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

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

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

　?。ū疚霓D自微信號EAWorld）