基於Docker的日誌分析平臺(一) 介紹

1. 爲何要分析日誌

傳統的Web開發中，日誌可能並不被重視，只有應用出現問題後，纔會適時性的去看一眼。並且日誌的儲存方式也很簡單，直接寫入一個文本文件或者扔到數據庫中就了事了。這樣對於單機應用來講沒有什麼不能夠的，但是當系統架構分佈式後，官網、論壇、社交、交易等各個大大小小的子系統愈來愈多，再加上操做系統、應用服務、業務邏輯等等，日誌的管理與查看就愈加的麻煩，面對大量的日誌數據並且又是分佈在各個不一樣的機器甚至不一樣的機房，若是咱們仍是按照傳統的方式登陸到某一臺機器上去查看日誌，而後再彙總起來，再作個跨機房的排序，那這樣感受就太糟糕了。因此一套集中式的實時日誌分析平臺就顯得很是重要了，而一套日誌分析平臺至少要包括一下幾個特色：

• 收集, 能夠收集不一樣來源的日誌，包括Web日誌，請求日誌，本地機器，跨機房機器等
• 存儲，穩定的存儲日誌信息並索引發來
• 分析，支持各類層面的分析，並且能夠以UI展現出來
• 警告，根據日誌內容進行不一樣錯誤級別的報警

2. ELK協議棧

其實市面上的日誌分析產品不少，簡單的Rsyslog，商業化的Splunk，開源的Scribe，Apache的Flume，Cloudera 的ELK。這裏採用的是ELK這個體系架構，ELK(Elasticsearch, Logstash, Kibana)通過這麼多年的發展，一直到如今的6.0.0版本。可以發展這麼快，其中確定有他的緣由所在。簡單介紹一下這三個軟件的特色：

• Elasticsearch 高可用性，實時索引，拓展簡單，接口友好
• Logstash 是一個具備實時的數據收集引擎，幾乎能夠收集全部的數據
• Kibana 提供分析和可視化的Web平臺，用來查詢分析以及生成各類報表

經過架構圖能夠看到，總體日誌平臺的原理其實並不難，日誌的生產者做爲Shipper產生各類各樣的日誌，而後傳輸到Kafka中，這裏傳輸也是從生產者中讀取而後傳輸經過 Logstash 到 Kafka， 再者Logstash經過讀取Kafka中的日誌數據，儲存到ElasticSearch。只在中間再增長了Kafka作爲緩衝層，由於Logstash會同步把日誌傳輸到Elasticsearch，一旦ElasticSearch掛掉數據就有可能會丟失。因而，咱們考慮利用Kafka做爲緩衝區。

這裏選擇Kafka的緣由是由於與大多數消息系統比較，Kafka有更好的吞吐量，內置分區，副本和故障轉移，這有利於處理大規模的消息，由於互聯網應用日誌基本上都是海量的。

3.基於Docker

Docker算是雲計算時代擁有劃時代意義的項目了，關於Docker的介紹與資料很是多。特別是docker-compose至關於給Docker插上了翅膀。Docker相對於傳統的虛擬化技術，Docker應用運行於宿主內核，無需啓動完整的操做系統，能夠作到秒級、甚至毫秒級的啓動時間，大大的節約了開發、測試、部署的時間。而且確保了運行環境的一致，「這段代碼在我機器上沒問題啊」這一些的問題不再會出現。