文章大綱
一、日志系統(tǒng)概念介紹
二、ELK日志系統(tǒng)介紹
三、互聯(lián)網(wǎng)行業(yè)日志處理方案介紹
四、參考文章
一、日志系統(tǒng)概念介紹
1. 簡介
日志主要包括系統(tǒng)日志、應(yīng)用程序日志和安全日志。系統(tǒng)運維和開發(fā)人員可以通過日志了解服務(wù)器軟硬件信息、檢查配置過程中的錯誤及錯誤發(fā)生的原因。經(jīng)常分析日志可以了解服務(wù)器的負(fù)荷，性能安全性，從而及時采取措施糾正錯誤。
通常，日志被分散在儲存不同的設(shè)備上。如果你管理數(shù)十上百臺服務(wù)器，你還在使用依次登錄每臺機(jī)器的傳統(tǒng)方法查閱日志。這樣是不是感覺很繁瑣和效率低下。當(dāng)務(wù)之急我們使用集中化的日志管理，例如：開源的syslog，將所有服務(wù)器上的日志收集匯總。
集中化管理日志后，日志的統(tǒng)計和檢索又成為一件比較麻煩的事情，一般我們使用grep、awk和wc等Linux命令能實現(xiàn)檢索和統(tǒng)計，但是對于要求更高的查詢、排序和統(tǒng)計等要求和龐大的機(jī)器數(shù)量依然使用這樣的方法難免有點力不從心。
大數(shù)據(jù)時代，隨著數(shù)據(jù)量不斷增長，存儲與計算集群的規(guī)模也逐漸擴(kuò)大，幾百上千臺的云計算環(huán)境已不鮮見。現(xiàn)在的集群所需要解決的問題不僅僅是高性能、高可靠性、高可擴(kuò)展性，還需要面對易維護(hù)性以及數(shù)據(jù)平臺內(nèi)部的數(shù)據(jù)共享性等諸多挑戰(zhàn)。優(yōu)秀的系統(tǒng)運維平臺既能實現(xiàn)數(shù)據(jù)平臺各組件的集中式管理、方便系統(tǒng)運維人員日常監(jiān)測、提升運維效率，又能反饋系統(tǒng)運行狀態(tài)給系統(tǒng)開發(fā)人員。例如采集數(shù)據(jù)倉庫的日志可以按照時間序列查看各數(shù)據(jù)庫實例各種級別的日志數(shù)量與占比，采集DB2表空間數(shù)據(jù)分析可得到數(shù)據(jù)庫集群健康狀態(tài)，分析應(yīng)用服務(wù)器的日志可以查看出錯最多的模塊、下載最多的文件、使用最多的功能等。大數(shù)據(jù)時代的業(yè)務(wù)與運維將緊密的結(jié)合在一起。
2. 日志分類
日志是帶時間戳的基于時間序列的機(jī)器數(shù)據(jù)，包括IT系統(tǒng)信息（服務(wù)器、網(wǎng)絡(luò)設(shè)備、操作系統(tǒng)、應(yīng)用軟件）、物聯(lián)網(wǎng)各種傳感器信息。日志可以反映用戶行為，是真實數(shù)據(jù)。
日志處理方案經(jīng)歷的版本迭代
日志處理v1.0
日志沒有集中式處理；只做事后追查，黑客入侵后刪除日志無法察覺；使用數(shù)據(jù)庫存儲日志，無法勝任復(fù)雜事務(wù)處理。
日志處理v2.0
使用Hadoop平臺實現(xiàn)日志離線批處理，缺點是實時性差；使用Storm流處理框架、Spark內(nèi)存計算框架處理日志，但Hadoop/Storm/Spark都是編程框架，并不是拿來即用的平臺。
日志處理v3.0
使用日志實時搜索引擎分析日志，特點：第一是快，日志從產(chǎn)生到搜索分析出結(jié)果只有數(shù)秒延時；第二是大，每天處理TB日志量；第三是靈活，可搜索分析任何日志。作為代表的解決方案有Splunk、ELK、SILK。
3. 日志實時性分析
實時
一般適用于我們常說的一級應(yīng)用，如：直接面向用戶的應(yīng)用。我們可以自定義各類關(guān)鍵字，以方便在出現(xiàn)各種 error 或 exception 時，相關(guān)業(yè)務(wù)人員能夠在第一時間被通知到。
準(zhǔn)實時
一般適用于一些項目管理的平臺，如：在需要填寫工時的時候出現(xiàn)了宕機(jī)，但這并不影響工資的發(fā)放。
平臺在幾分鐘后完成重啟，我們可以再登錄填寫，該情況并不造成原則性的影響。因此，我們可以將其列為準(zhǔn)實時的級別。
除了直接采集錯誤與異常，我們還需要進(jìn)行分析。例如：僅知道某人的體重是沒什么意義的，但是如果增加了性別和身高兩個指標(biāo)，那么我們就可以判斷出此人的體重是否為標(biāo)準(zhǔn)體重。
也就是說：如果能給出多個指標(biāo)，就可以對龐大的數(shù)據(jù)進(jìn)行去噪，然后通過回歸分析，讓采集到的數(shù)據(jù)更有意義。
此外，我們還要不斷地去還原數(shù)字的真實性。特別是對于實時的一級應(yīng)用，我們要能快速地讓用戶明白他們所碰到現(xiàn)象的真實含義。
例如：商家在上架時錯把商品的價格標(biāo)簽 100 元標(biāo)成了 10 元。這會導(dǎo)致商品馬上被搶購一空。
但是這種現(xiàn)象并非是業(yè)務(wù)的問題，很難被發(fā)現(xiàn)，因此我們只能通過日志數(shù)據(jù)進(jìn)行邏輯分析，及時反饋以保證在幾十秒之后將庫存修改為零，從而有效地解決此問題?？梢姡诖藨?yīng)用場景中，實時分析就顯得非常有用。
最后是追溯，我們需要在獲取歷史信息的同時，實現(xiàn)跨時間維度的對比與總結(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）存儲－如何存儲日志數(shù)據(jù)
（4）分析－可以支持 UI 分析
（5）警告－能夠提供錯誤報告，監(jiān)控機(jī)制
ELK提供了一整套解決方案，并且都是開源軟件，之間互相配合使用，完美銜接，高效的滿足了很多場合的應(yīng)用。目前主流的一種日志系統(tǒng)。
5. 完整的日志系統(tǒng)作用
（1）信息查找。通過檢索日志信息，定位相應(yīng)的bug，找出解決方案。
（2）服務(wù)診斷。通過對日志信息進(jìn)行統(tǒng)計、分析，了解服務(wù)器的負(fù)荷和服務(wù)運行狀態(tài)，找出耗時請求進(jìn)行優(yōu)化等等。
（3）數(shù)據(jù)分析。如果是格式化的log，可以做進(jìn)一步的數(shù)據(jù)分析，統(tǒng)計、聚合出有意義的信息，比如根據(jù)請求中的商品id，找出TOP10用戶感興趣商品。
二、ELK日志系統(tǒng)介紹
1. ELK組成成分
ELK Stack是開源日志處理平臺解決方案，背后的商業(yè)公司是elastic(https://www.elastic.co/)。它由日志采集解析工具Logstash、基于Lucene的全文搜索引擎Elasticsearch、分析可視化平臺Kibana組成。目前ELK的用戶有Adobe、Microsoft、Mozilla、Facebook、Stackoverflow、Cisco、ebay、Uber等諸多廠商。
2. ELK工作原理展示圖
3. Elasticsearch介紹
Elasticsearch是基于Lucene的近實時搜索平臺，它能在一秒內(nèi)返回你要查找的且已經(jīng)在Elasticsearch做了索引的文檔。它默認(rèn)基于Gossip路由算法的自動發(fā)現(xiàn)機(jī)制構(gòu)建配置有相同cluster name的集群，但是有的時候這種機(jī)制并不可靠，會發(fā)生腦裂現(xiàn)象。鑒于主動發(fā)現(xiàn)機(jī)制的不穩(wěn)定性，用戶可以選擇在每一個節(jié)點上配置集群其他節(jié)點的主機(jī)名，在啟動集群時進(jìn)行被動發(fā)現(xiàn)。
Elasticsearch中的Index是一組具有相似特征的文檔集合，類似于關(guān)系數(shù)據(jù)庫模型中的數(shù)據(jù)庫實例，Index中可以指定Type區(qū)分不同的文檔，類似于數(shù)據(jù)庫實例中的關(guān)系表，Document是存儲的基本單位，都是JSON格式，類似于關(guān)系表中行級對象。我們處理后的JSON文檔格式的日志都要在Elasticsearch中做索引，相應(yīng)的Logstash有Elasticsearch output插件，對于用戶是透明的。
4. Logstash介紹
Logstash事件處理有三個階段：inputs → filters → outputs。是一個接收，處理，轉(zhuǎn)發(fā)日志的工具。支持系統(tǒng)日志，webserver日志，錯誤日志，應(yīng)用日志，總之包括所有可以拋出來的日志類型。
Logstash工作原理：
5. Kibana介紹
Kibana是專門設(shè)計用來與Elasticsearch協(xié)作的，可以自定義多種表格、柱狀圖、餅狀圖、折線圖對存儲在Elasticsearch中的數(shù)據(jù)進(jìn)行深入挖掘分析與可視化。下圖定制的儀表盤可以動態(tài)監(jiān)測數(shù)據(jù)庫集群中每個數(shù)據(jù)庫實例產(chǎn)生的各種級別的日志。
實時監(jiān)測DB2實例運行狀態(tài)的動態(tài)儀表盤：
6. ELK整體方案
ELK中的三個系統(tǒng)分別扮演不同的角色，組成了一個整體的解決方案。Logstash是一個ETL工具，負(fù)責(zé)從每臺機(jī)器抓取日志數(shù)據(jù)，對數(shù)據(jù)進(jìn)行格式轉(zhuǎn)換和處理后，輸出到Elasticsearch中存儲。Elasticsearch是一個分布式搜索引擎和分析引擎，用于數(shù)據(jù)存儲，可提供實時的數(shù)據(jù)查詢。Kibana是一個數(shù)據(jù)可視化服務(wù)，根據(jù)用戶的操作從Elasticsearch中查詢數(shù)據(jù)，形成相應(yīng)的分析結(jié)果，以圖表的形式展現(xiàn)給用戶。
ELK的安裝很簡單，可以按照"下載->修改配置文件->啟動"方法分別部署三個系統(tǒng)，也可以使用docker來快速部署。具體的安裝方法這里不詳細(xì)介紹，下面來看一個常見的部署方案，如下圖所示，部署思路是：
（1）在每臺生成日志文件的機(jī)器上，部署Logstash，作為Shipper的角色，負(fù)責(zé)從日志文件中提取數(shù)據(jù)，但是不做任何處理，直接將數(shù)據(jù)輸出到Redis隊列(list)中；
（2）需要一臺機(jī)器部署Logstash，作為Indexer的角色，負(fù)責(zé)從Redis中取出數(shù)據(jù)，對數(shù)據(jù)進(jìn)行格式化和相關(guān)處理后，輸出到Elasticsearch中存儲；
（3）部署Elasticsearch集群，當(dāng)然取決于你的數(shù)據(jù)量了，數(shù)據(jù)量小的話可以使用單臺服務(wù)，如果做集群的話，最好是有3個以上節(jié)點，同時還需要部署相關(guān)的監(jiān)控插件；
（4）部署Kibana服務(wù)，提供Web服務(wù)。
在前期部署階段，主要工作是Logstash節(jié)點和Elasticsearch集群的部署，而在后期使用階段，主要工作就是Elasticsearch集群的監(jiān)控和使用Kibana來檢索、分析日志數(shù)據(jù)了，當(dāng)然也可以直接編寫程序來消費Elasticsearch中的數(shù)據(jù)。
在上面的部署方案中，我們將Logstash分為Shipper和Indexer兩種角色來完成不同的工作，中間通過Redis做數(shù)據(jù)管道，為什么要這樣做？為什么不是直接在每臺機(jī)器上使用Logstash提取數(shù)據(jù)、處理、存入Elasticsearch？
首先，采用這樣的架構(gòu)部署，有三點優(yōu)勢：第一，降低對日志所在機(jī)器的影響，這些機(jī)器上一般都部署著反向代理或應(yīng)用服務(wù)，本身負(fù)載就很重了，所以盡可能的在這些機(jī)器上少做事；第二，如果有很多臺機(jī)器需要做日志收集，那么讓每臺機(jī)器都向Elasticsearch持續(xù)寫入數(shù)據(jù)，必然會對Elasticsearch造成壓力，因此需要對數(shù)據(jù)進(jìn)行緩沖，同時，這樣的緩沖也可以一定程度的保護(hù)數(shù)據(jù)不丟失；第三，將日志數(shù)據(jù)的格式化與處理放到Indexer中統(tǒng)一做，可以在一處修改代碼、部署，避免需要到多臺機(jī)器上去修改配置。
其次，我們需要做的是將數(shù)據(jù)放入一個消息隊列中進(jìn)行緩沖，所以Redis只是其中一個選擇，也可以是RabbitMQ、Kafka等等，在實際生產(chǎn)中，Redis與Kafka用的比較多。由于Redis集群一般都是通過key來做分片，無法對list類型做集群，在數(shù)據(jù)量大的時候必然不合適了，而Kafka天生就是分布式的消息隊列系統(tǒng)。
三、互聯(lián)網(wǎng)行業(yè)日志處理方案介紹
1. 新浪
新浪采用的技術(shù)架構(gòu)是常見的Kafka整合ELK Stack方案。Kafka作為消息隊列用來緩存用戶日志；使用Logstash做日志解析，統(tǒng)一成JSON格式輸出給Elasticsearch；使用Elasticsearch提供實時日志分析與強(qiáng)大的搜索和統(tǒng)計服務(wù)；Kibana用作數(shù)據(jù)可視化組件。該技術(shù)架構(gòu)目前服務(wù)的用戶包括微博、微盤、云存儲、彈性計算平臺等十多個部門的多個產(chǎn)品的日志搜索分析業(yè)務(wù)，每天處理約32億條（2TB）日志。
新浪的日志處理平臺團(tuán)隊對Elasticsearch做了大量優(yōu)化（比如調(diào)整max open files等），并且開發(fā)了一個獨立的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，滿足微盤搜索對中文分詞的需求。
2. 騰訊
騰訊藍(lán)鯨數(shù)據(jù)平臺告警系統(tǒng)的技術(shù)架構(gòu)同樣基于分布式消息隊列和全文搜索引擎。但騰訊的告警平臺不僅限于此，它的復(fù)雜的指標(biāo)數(shù)據(jù)統(tǒng)計任務(wù)通過使用Storm自定義流式計算任務(wù)的方法實現(xiàn)，異常檢測的實現(xiàn)利用了曲線的時間周期性和相關(guān)曲線之間的相關(guān)性去定義動態(tài)的閾值，并且基于機(jī)器學(xué)習(xí)算法實現(xiàn)了復(fù)雜的日志自動分類（比如summo logic）。
告警平臺把撥測（定時curl一下某個url，有問題就告警）、日志集中檢索、日志告警（5分鐘Error大于X次告警）、指標(biāo)告警（cpu使用率大于X告警）整合進(jìn)同一個數(shù)據(jù)管線，簡化了整體的架構(gòu)。
3. 七牛
七牛采用的技術(shù)架構(gòu)為Flume＋Kafka＋Spark，混部在8臺高配機(jī)器。根據(jù)七牛技術(shù)博客提供的數(shù)據(jù)，該日志處理平臺每天處理500億條數(shù)據(jù)，峰值80萬TPS。
Flume相較于Logstash有更大的吞吐量，而且與HDFS整合的性能比Logstash強(qiáng)很多。七牛技術(shù)架構(gòu)選型顯然考慮了這一點，七牛云平臺的日志數(shù)據(jù)到Kafka后，一路同步到HDFS，用于離線統(tǒng)計，另一路用于使用Spark Streaming進(jìn)行實時計算，計算結(jié)果保存在Mongodb集群中。
任何解決方案都不是十全十美的，具體采用哪些技術(shù)要深入了解自己的應(yīng)用場景。就目前日志處理領(lǐng)域的開源組件來說，在以下幾個方面還比較欠缺：
