摘要：基于算是云計(jì)算時(shí)代擁有劃時(shí)代意義的項(xiàng)目了，關(guān)于的介紹與資料非常多。

傳統(tǒng)的Web開發(fā)中，日志可能并不被重視，只有應(yīng)用出現(xiàn)問題后，才會(huì)適時(shí)性的去看一眼。而且日志的儲(chǔ)存方式也很簡(jiǎn)單，直接寫入一個(gè)文本文件或者扔到數(shù)據(jù)庫(kù)中就了事了。這樣對(duì)于單機(jī)應(yīng)用來說沒有什么不可以的，可是當(dāng)系統(tǒng)架構(gòu)分布式后，官網(wǎng)、論壇、社交、交易等各個(gè)大大小小的子系統(tǒng)越來越多，再加上操作系統(tǒng)、應(yīng)用服務(wù)、業(yè)務(wù)邏輯等等，日志的管理與查看就越發(fā)的麻煩，面對(duì)大量的日志數(shù)據(jù)而且又是分布在各個(gè)不同的機(jī)器甚至不同的機(jī)房，如果我們還是按照傳統(tǒng)的方式登錄到某一臺(tái)機(jī)器上去查看日志，然后再匯總起來，再做個(gè)跨機(jī)房的排序，那這樣感覺就太糟糕了。所以一套集中式的實(shí)時(shí)日志分析平臺(tái)就顯得非常重要了，而一套日志分析平臺(tái)至少要包括一下幾個(gè)特點(diǎn)：

收集, 可以收集不同來源的日志，包括Web日志，請(qǐng)求日志，本地機(jī)器，跨機(jī)房機(jī)器等

存儲(chǔ)，穩(wěn)定的存儲(chǔ)日志信息并索引起來

分析，支持各種層面的分析，而且可以以UI展示出來

警告，根據(jù)日志內(nèi)容進(jìn)行不同錯(cuò)誤級(jí)別的報(bào)警

其實(shí)市面上的日志分析產(chǎn)品很多，簡(jiǎn)單的Rsyslog，商業(yè)化的Splunk，開源的Scribe，Apache的Flume，Cloudera 的ELK。這里采用的是ELK這個(gè)體系架構(gòu)，ELK(Elasticsearch, Logstash, Kibana)經(jīng)過這么多年的發(fā)展，一直到現(xiàn)在的6.0.0版本。能夠發(fā)展這么快，其中肯定有他的原因所在。簡(jiǎn)單介紹一下這三個(gè)軟件的特點(diǎn)：

Elasticsearch 高可用性，實(shí)時(shí)索引，拓展簡(jiǎn)單，接口友好

Logstash 是一個(gè)具有實(shí)時(shí)的數(shù)據(jù)收集引擎，幾乎可以收集所有的數(shù)據(jù)

Kibana 提供分析和可視化的Web平臺(tái)，用來查詢分析以及生成各種報(bào)表

通過架構(gòu)圖可以看到，整體日志平臺(tái)的原理其實(shí)并不難，日志的生產(chǎn)者作為Shipper產(chǎn)生各種各樣的日志，然后傳輸?shù)?b>Kafka中，這里傳輸也是從生產(chǎn)者中讀取然后傳輸通過 Logstash 到 Kafka， 再者Logstash通過讀取Kafka中的日志數(shù)據(jù)，儲(chǔ)存到ElasticSearch。只在中間再增加了Kafka做為緩沖層，因?yàn)?b>Logstash會(huì)同步把日志傳輸?shù)?b>Elasticsearch，一旦ElasticSearch掛掉數(shù)據(jù)就有可能會(huì)丟失。于是，我們考慮利用Kafka作為緩沖區(qū)。

這里選擇Kafka的原因是因?yàn)榕c大多數(shù)消息系統(tǒng)比較，Kafka有更好的吞吐量，內(nèi)置分區(qū)，副本和故障轉(zhuǎn)移，這有利于處理大規(guī)模的消息，因?yàn)榛ヂ?lián)網(wǎng)應(yīng)用日志基本上都是海量的。

Docker算是云計(jì)算時(shí)代擁有劃時(shí)代意義的項(xiàng)目了，關(guān)于Docker的介紹與資料非常多。特別是docker-compose相當(dāng)于給Docker插上了翅膀。Docker相對(duì)于傳統(tǒng)的虛擬化技術(shù)，Docker應(yīng)用運(yùn)行于宿主內(nèi)核，無需啟動(dòng)完整的操作系統(tǒng)，可以做到秒級(jí)、甚至毫秒級(jí)的啟動(dòng)時(shí)間，大大的節(jié)約了開發(fā)、測(cè)試、部署的時(shí)間。并且確保了運(yùn)行環(huán)境的一致，「這段代碼在我機(jī)器上沒問題啊」這一些的問題再也不會(huì)出現(xiàn)。