文章大綱

一、日志系統(tǒng)概念介紹
二,、ELK日志系統(tǒng)介紹
三,、互聯(lián)網(wǎng)行業(yè)日志處理方案介紹
四、參考文章

一,、日志系統(tǒng)概念介紹

1. 簡介

日志主要包括系統(tǒng)日志,、應(yīng)用程序日志和安全日志。系統(tǒng)運(yùn)維和開發(fā)人員可以通過日志了解服務(wù)器軟硬件信息,、檢查配置過程中的錯(cuò)誤及錯(cuò)誤發(fā)生的原因。經(jīng)常分析日志可以了解服務(wù)器的負(fù)荷,，性能安全性,，從而及時(shí)采取措施糾正錯(cuò)誤。
通常,，日志被分散在儲(chǔ)存不同的設(shè)備上,。如果你管理數(shù)十上百臺(tái)服務(wù)器，你還在使用依次登錄每臺(tái)機(jī)器的傳統(tǒng)方法查閱日志,。這樣是不是感覺很繁瑣和效率低下,。當(dāng)務(wù)之急我們使用集中化的日志管理，例如：開源的syslog,，將所有服務(wù)器上的日志收集匯總,。
集中化管理日志后,，日志的統(tǒng)計(jì)和檢索又成為一件比較麻煩的事情，一般我們使用grep,、awk和wc等Linux命令能實(shí)現(xiàn)檢索和統(tǒng)計(jì),，但是對(duì)于要求更高的查詢、排序和統(tǒng)計(jì)等要求和龐大的機(jī)器數(shù)量依然使用這樣的方法難免有點(diǎn)力不從心,。
大數(shù)據(jù)時(shí)代,，隨著數(shù)據(jù)量不斷增長，存儲(chǔ)與計(jì)算集群的規(guī)模也逐漸擴(kuò)大,，幾百上千臺(tái)的云計(jì)算環(huán)境已不鮮見?，F(xiàn)在的集群所需要解決的問題不僅僅是高性能、高可靠性,、高可擴(kuò)展性,，還需要面對(duì)易維護(hù)性以及數(shù)據(jù)平臺(tái)內(nèi)部的數(shù)據(jù)共享性等諸多挑戰(zhàn)。優(yōu)秀的系統(tǒng)運(yùn)維平臺(tái)既能實(shí)現(xiàn)數(shù)據(jù)平臺(tái)各組件的集中式管理,、方便系統(tǒng)運(yùn)維人員日常監(jiān)測,、提升運(yùn)維效率，又能反饋系統(tǒng)運(yùn)行狀態(tài)給系統(tǒng)開發(fā)人員,。例如采集數(shù)據(jù)倉庫的日志可以按照時(shí)間序列查看各數(shù)據(jù)庫實(shí)例各種級(jí)別的日志數(shù)量與占比,，采集DB2表空間數(shù)據(jù)分析可得到數(shù)據(jù)庫集群健康狀態(tài)，分析應(yīng)用服務(wù)器的日志可以查看出錯(cuò)最多的模塊,、下載最多的文件,、使用最多的功能等。大數(shù)據(jù)時(shí)代的業(yè)務(wù)與運(yùn)維將緊密的結(jié)合在一起,。

2. 日志分類

日志是帶時(shí)間戳的基于時(shí)間序列的機(jī)器數(shù)據(jù),，包括IT系統(tǒng)信息（服務(wù)器、網(wǎng)絡(luò)設(shè)備,、操作系統(tǒng),、應(yīng)用軟件）、物聯(lián)網(wǎng)各種傳感器信息,。日志可以反映用戶行為,，是真實(shí)數(shù)據(jù)。
日志處理方案經(jīng)歷的版本迭代

日志處理v1.0
日志沒有集中式處理,；只做事后追查,，黑客入侵后刪除日志無法察覺；使用數(shù)據(jù)庫存儲(chǔ)日志,，無法勝任復(fù)雜事務(wù)處理,。

日志處理v2.0
使用Hadoop平臺(tái)實(shí)現(xiàn)日志離線批處理，缺點(diǎn)是實(shí)時(shí)性差,；使用Storm流處理框架,、Spark內(nèi)存計(jì)算框架處理日志,，但Hadoop/Storm/Spark都是編程框架，并不是拿來即用的平臺(tái),。

日志處理v3.0
使用日志實(shí)時(shí)搜索引擎分析日志,，特點(diǎn)：第一是快，日志從產(chǎn)生到搜索分析出結(jié)果只有數(shù)秒延時(shí),；第二是大,，每天處理TB日志量；第三是靈活,，可搜索分析任何日志,。作為代表的解決方案有Splunk、ELK,、SILK,。

3. 日志實(shí)時(shí)性分析

實(shí)時(shí)
一般適用于我們常說的一級(jí)應(yīng)用，如：直接面向用戶的應(yīng)用,。我們可以自定義各類關(guān)鍵字,，以方便在出現(xiàn)各種 error 或 exception 時(shí)，相關(guān)業(yè)務(wù)人員能夠在第一時(shí)間被通知到,。

準(zhǔn)實(shí)時(shí)
一般適用于一些項(xiàng)目管理的平臺(tái),，如：在需要填寫工時(shí)的時(shí)候出現(xiàn)了宕機(jī)，但這并不影響工資的發(fā)放,。

平臺(tái)在幾分鐘后完成重啟,，我們可以再登錄填寫，該情況并不造成原則性的影響,。因此,，我們可以將其列為準(zhǔn)實(shí)時(shí)的級(jí)別。

除了直接采集錯(cuò)誤與異常,，我們還需要進(jìn)行分析,。例如：僅知道某人的體重是沒什么意義的，但是如果增加了性別和身高兩個(gè)指標(biāo),，那么我們就可以判斷出此人的體重是否為標(biāo)準(zhǔn)體重,。

也就是說：如果能給出多個(gè)指標(biāo)，就可以對(duì)龐大的數(shù)據(jù)進(jìn)行去噪,，然后通過回歸分析，讓采集到的數(shù)據(jù)更有意義,。

此外,，我們還要不斷地去還原數(shù)字的真實(shí)性。特別是對(duì)于實(shí)時(shí)的一級(jí)應(yīng)用,，我們要能快速地讓用戶明白他們所碰到現(xiàn)象的真實(shí)含義,。

例如：商家在上架時(shí)錯(cuò)把商品的價(jià)格標(biāo)簽 100 元標(biāo)成了 10 元,。這會(huì)導(dǎo)致商品馬上被搶購一空。

但是這種現(xiàn)象并非是業(yè)務(wù)的問題,，很難被發(fā)現(xiàn),，因此我們只能通過日志數(shù)據(jù)進(jìn)行邏輯分析，及時(shí)反饋以保證在幾十秒之后將庫存修改為零,，從而有效地解決此問題,。可見,，在此應(yīng)用場景中,，實(shí)時(shí)分析就顯得非常有用。

最后是追溯,，我們需要在獲取歷史信息的同時(shí),，實(shí)現(xiàn)跨時(shí)間維度的對(duì)比與總結(jié)，那么追溯就能夠在各種應(yīng)用中發(fā)揮其關(guān)聯(lián)性作用了,。

4. 完整的日志系統(tǒng)包含內(nèi)容

（1）收集－能夠采集多種來源的日志數(shù)據(jù)
（2）傳輸－能夠穩(wěn)定的把日志數(shù)據(jù)傳輸?shù)街醒胂到y(tǒng)
（3）存儲(chǔ)－如何存儲(chǔ)日志數(shù)據(jù)
（4）分析－可以支持 UI 分析
（5）警告－能夠提供錯(cuò)誤報(bào)告,，監(jiān)控機(jī)制

ELK提供了一整套解決方案，并且都是開源軟件,，之間互相配合使用,，完美銜接，高效的滿足了很多場合的應(yīng)用,。目前主流的一種日志系統(tǒng),。

5. 完整的日志系統(tǒng)作用

（1）信息查找。通過檢索日志信息,，定位相應(yīng)的bug,，找出解決方案。
（2）服務(wù)診斷,。通過對(duì)日志信息進(jìn)行統(tǒng)計(jì),、分析，了解服務(wù)器的負(fù)荷和服務(wù)運(yùn)行狀態(tài),，找出耗時(shí)請(qǐng)求進(jìn)行優(yōu)化等等,。
（3）數(shù)據(jù)分析。如果是格式化的log,，可以做進(jìn)一步的數(shù)據(jù)分析,，統(tǒng)計(jì)、聚合出有意義的信息,，比如根據(jù)請(qǐng)求中的商品id,，找出TOP10用戶感興趣商品。

二、ELK日志系統(tǒng)介紹

1. ELK組成成分

ELK Stack是開源日志處理平臺(tái)解決方案,，背后的商業(yè)公司是elastic(https://www./),。它由日志采集解析工具Logstash、基于Lucene的全文搜索引擎Elasticsearch,、分析可視化平臺(tái)Kibana組成,。目前ELK的用戶有Adobe、Microsoft,、Mozilla,、Facebook、Stackoverflow,、Cisco,、ebay、Uber等諸多廠商,。

2. ELK工作原理展示圖

3. Elasticsearch介紹

Elasticsearch是基于Lucene的近實(shí)時(shí)搜索平臺(tái),，它能在一秒內(nèi)返回你要查找的且已經(jīng)在Elasticsearch做了索引的文檔。它默認(rèn)基于Gossip路由算法的自動(dòng)發(fā)現(xiàn)機(jī)制構(gòu)建配置有相同cluster name的集群,，但是有的時(shí)候這種機(jī)制并不可靠,，會(huì)發(fā)生腦裂現(xiàn)象。鑒于主動(dòng)發(fā)現(xiàn)機(jī)制的不穩(wěn)定性,，用戶可以選擇在每一個(gè)節(jié)點(diǎn)上配置集群其他節(jié)點(diǎn)的主機(jī)名,，在啟動(dòng)集群時(shí)進(jìn)行被動(dòng)發(fā)現(xiàn)。
Elasticsearch中的Index是一組具有相似特征的文檔集合,，類似于關(guān)系數(shù)據(jù)庫模型中的數(shù)據(jù)庫實(shí)例,，Index中可以指定Type區(qū)分不同的文檔，類似于數(shù)據(jù)庫實(shí)例中的關(guān)系表,，Document是存儲(chǔ)的基本單位,，都是JSON格式，類似于關(guān)系表中行級(jí)對(duì)象,。我們處理后的JSON文檔格式的日志都要在Elasticsearch中做索引,，相應(yīng)的Logstash有Elasticsearch output插件，對(duì)于用戶是透明的,。

4. Logstash介紹

Logstash事件處理有三個(gè)階段：inputs → filters → outputs,。是一個(gè)接收，處理,，轉(zhuǎn)發(fā)日志的工具,。支持系統(tǒng)日志，webserver日志,，錯(cuò)誤日志,，應(yīng)用日志，總之包括所有可以拋出來的日志類型,。
Logstash工作原理：

5. Kibana介紹

Kibana是專門設(shè)計(jì)用來與Elasticsearch協(xié)作的,，可以自定義多種表格、柱狀圖,、餅狀圖,、折線圖對(duì)存儲(chǔ)在Elasticsearch中的數(shù)據(jù)進(jìn)行深入挖掘分析與可視化。下圖定制的儀表盤可以動(dòng)態(tài)監(jiān)測數(shù)據(jù)庫集群中每個(gè)數(shù)據(jù)庫實(shí)例產(chǎn)生的各種級(jí)別的日志,。
實(shí)時(shí)監(jiān)測DB2實(shí)例運(yùn)行狀態(tài)的動(dòng)態(tài)儀表盤：

6. ELK整體方案

ELK中的三個(gè)系統(tǒng)分別扮演不同的角色,，組成了一個(gè)整體的解決方案。Logstash是一個(gè)ETL工具,，負(fù)責(zé)從每臺(tái)機(jī)器抓取日志數(shù)據(jù),，對(duì)數(shù)據(jù)進(jìn)行格式轉(zhuǎn)換和處理后，輸出到Elasticsearch中存儲(chǔ),。Elasticsearch是一個(gè)分布式搜索引擎和分析引擎,，用于數(shù)據(jù)存儲(chǔ)，可提供實(shí)時(shí)的數(shù)據(jù)查詢,。Kibana是一個(gè)數(shù)據(jù)可視化服務(wù),，根據(jù)用戶的操作從Elasticsearch中查詢數(shù)據(jù)，形成相應(yīng)的分析結(jié)果,，以圖表的形式展現(xiàn)給用戶,。
ELK的安裝很簡單，可以按照'下載->修改配置文件->啟動(dòng)'方法分別部署三個(gè)系統(tǒng),，也可以使用docker來快速部署,。具體的安裝方法這里不詳細(xì)介紹，下面來看一個(gè)常見的部署方案,，如下圖所示,，部署思路是：
（1）在每臺(tái)生成日志文件的機(jī)器上，部署Logstash,，作為Shipper的角色,，負(fù)責(zé)從日志文件中提取數(shù)據(jù)，但是不做任何處理,，直接將數(shù)據(jù)輸出到Redis隊(duì)列(list)中,；
（2）需要一臺(tái)機(jī)器部署Logstash，作為Indexer的角色,，負(fù)責(zé)從Redis中取出數(shù)據(jù),，對(duì)數(shù)據(jù)進(jìn)行格式化和相關(guān)處理后，輸出到Elasticsearch中存儲(chǔ),；
（3）部署Elasticsearch集群,，當(dāng)然取決于你的數(shù)據(jù)量了，數(shù)據(jù)量小的話可以使用單臺(tái)服務(wù)，如果做集群的話,，最好是有3個(gè)以上節(jié)點(diǎn),，同時(shí)還需要部署相關(guān)的監(jiān)控插件；
（4）部署Kibana服務(wù),，提供Web服務(wù),。

在前期部署階段，主要工作是Logstash節(jié)點(diǎn)和Elasticsearch集群的部署,，而在后期使用階段,，主要工作就是Elasticsearch集群的監(jiān)控和使用Kibana來檢索、分析日志數(shù)據(jù)了,，當(dāng)然也可以直接編寫程序來消費(fèi)Elasticsearch中的數(shù)據(jù),。

在上面的部署方案中，我們將Logstash分為Shipper和Indexer兩種角色來完成不同的工作,，中間通過Redis做數(shù)據(jù)管道,，為什么要這樣做？為什么不是直接在每臺(tái)機(jī)器上使用Logstash提取數(shù)據(jù),、處理,、存入Elasticsearch？

首先,，采用這樣的架構(gòu)部署,，有三點(diǎn)優(yōu)勢：第一，降低對(duì)日志所在機(jī)器的影響,，這些機(jī)器上一般都部署著反向代理或應(yīng)用服務(wù),，本身負(fù)載就很重了，所以盡可能的在這些機(jī)器上少做事,；第二,，如果有很多臺(tái)機(jī)器需要做日志收集，那么讓每臺(tái)機(jī)器都向Elasticsearch持續(xù)寫入數(shù)據(jù),，必然會(huì)對(duì)Elasticsearch造成壓力,，因此需要對(duì)數(shù)據(jù)進(jìn)行緩沖，同時(shí),，這樣的緩沖也可以一定程度的保護(hù)數(shù)據(jù)不丟失,；第三，將日志數(shù)據(jù)的格式化與處理放到Indexer中統(tǒng)一做,，可以在一處修改代碼,、部署，避免需要到多臺(tái)機(jī)器上去修改配置,。

其次,，我們需要做的是將數(shù)據(jù)放入一個(gè)消息隊(duì)列中進(jìn)行緩沖,，所以Redis只是其中一個(gè)選擇，也可以是RabbitMQ,、Kafka等等,，在實(shí)際生產(chǎn)中，Redis與Kafka用的比較多,。由于Redis集群一般都是通過key來做分片,，無法對(duì)list類型做集群，在數(shù)據(jù)量大的時(shí)候必然不合適了,，而Kafka天生就是分布式的消息隊(duì)列系統(tǒng)。

三,、互聯(lián)網(wǎng)行業(yè)日志處理方案介紹

1. 新浪

新浪采用的技術(shù)架構(gòu)是常見的Kafka整合ELK Stack方案,。Kafka作為消息隊(duì)列用來緩存用戶日志；使用Logstash做日志解析,，統(tǒng)一成JSON格式輸出給Elasticsearch,；使用Elasticsearch提供實(shí)時(shí)日志分析與強(qiáng)大的搜索和統(tǒng)計(jì)服務(wù)；Kibana用作數(shù)據(jù)可視化組件,。該技術(shù)架構(gòu)目前服務(wù)的用戶包括微博,、微盤、云存儲(chǔ),、彈性計(jì)算平臺(tái)等十多個(gè)部門的多個(gè)產(chǎn)品的日志搜索分析業(yè)務(wù),，每天處理約32億條（2TB）日志。
新浪的日志處理平臺(tái)團(tuán)隊(duì)對(duì)Elasticsearch做了大量優(yōu)化（比如調(diào)整max open files等）,，并且開發(fā)了一個(gè)獨(dú)立的Elasticsearch Index管理系統(tǒng),，負(fù)責(zé)索引日常維護(hù)任務(wù)（比如索引的創(chuàng)建、優(yōu)化,、刪除,、與分布式文件系統(tǒng)的數(shù)據(jù)交換等）的調(diào)度及執(zhí)行。為Elasticsearch安裝了國內(nèi)中文分詞插件elasticsearch-analysis-ik,，滿足微盤搜索對(duì)中文分詞的需求,。

2. 騰訊

騰訊藍(lán)鯨數(shù)據(jù)平臺(tái)告警系統(tǒng)的技術(shù)架構(gòu)同樣基于分布式消息隊(duì)列和全文搜索引擎。但騰訊的告警平臺(tái)不僅限于此,，它的復(fù)雜的指標(biāo)數(shù)據(jù)統(tǒng)計(jì)任務(wù)通過使用Storm自定義流式計(jì)算任務(wù)的方法實(shí)現(xiàn),，異常檢測的實(shí)現(xiàn)利用了曲線的時(shí)間周期性和相關(guān)曲線之間的相關(guān)性去定義動(dòng)態(tài)的閾值，并且基于機(jī)器學(xué)習(xí)算法實(shí)現(xiàn)了復(fù)雜的日志自動(dòng)分類（比如summo logic）,。
告警平臺(tái)把撥測（定時(shí)curl一下某個(gè)url,，有問題就告警）、日志集中檢索,、日志告警（5分鐘Error大于X次告警）,、指標(biāo)告警（cpu使用率大于X告警）整合進(jìn)同一個(gè)數(shù)據(jù)管線,，簡化了整體的架構(gòu)。

3. 七牛

七牛采用的技術(shù)架構(gòu)為Flume＋Kafka＋Spark,，混部在8臺(tái)高配機(jī)器,。根據(jù)七牛技術(shù)博客提供的數(shù)據(jù)，該日志處理平臺(tái)每天處理500億條數(shù)據(jù),，峰值80萬TPS,。
Flume相較于Logstash有更大的吞吐量，而且與HDFS整合的性能比Logstash強(qiáng)很多,。七牛技術(shù)架構(gòu)選型顯然考慮了這一點(diǎn),，七牛云平臺(tái)的日志數(shù)據(jù)到Kafka后，一路同步到HDFS,，用于離線統(tǒng)計(jì),，另一路用于使用Spark Streaming進(jìn)行實(shí)時(shí)計(jì)算，計(jì)算結(jié)果保存在Mongodb集群中,。
任何解決方案都不是十全十美的,，具體采用哪些技術(shù)要深入了解自己的應(yīng)用場景。就目前日志處理領(lǐng)域的開源組件來說,，在以下幾個(gè)方面還比較欠缺：

四,、參考文章

1. https://blog.csdn.net/yunzhaji3762/article/details/82962291
2. https://blog.csdn.net/bigstar863/article/details/49099531
3. https://www.cnblogs.com/kevingrace/p/5919021.html