ELK架構的演變

ELK的名稱是由最原始架構的三個組件的首字母組合而來，即E（lasticsearch）L（ogstash）K（ibana），

固然ELK演變至今天已經再也不只用三個組件了。最原初的三個組件都是基於java語言研發的，相對來講比較

重量級，正常運行所需服務器配置要求較高。想在生產中使用ELK作日誌分析的朋友須要作好資源準備。

要想上手ELK，必須對ELK的架構及運行原理作透徹的理解，廢話很少說，先來看ELK架構的演變之路。

ELK原始架構（三層架構）：

第一層：logstash：收集日誌+解析日誌+發送給elasticsearch

第二層：elasticsearch：索引日誌+存儲日誌+提供檢索API

第三層：kibana：從elasticsearch中抽取數據進行展現+生成圖表

logstash主要有三大功能模塊：input+filter+output（也即：收集日誌+解析日誌+發送日誌）

input：能夠直接從文件中抓取，也能夠從隊列中抓取，也能接收日誌生產工具的輸出（好比java的log4j輸出）

filter：對無結構化的數據進行解析處理，生成半結構化數據，filter支持較多插件，比較典型的有grok、date、

goeip、kv、json、mutate

output：能夠輸出到elasticsearch，也能夠輸出到消息隊列（如redis、kafka），也能輸出給監控系統（如zabbix）

elasticsearch：主要有三大功能，索引數據+存儲數據+提供檢索API

基於Lucene的二次封裝，提供了REST API的操做接口

引用wiki原話對Lucene的描述以下：

Lucene是一套用於全文檢索和搜索的開放源代碼程序庫，由Apache軟件基金會支持和提供。

Lucene提供了一個簡單卻強大的應用程序接口，可以作全文索引和搜索，在Java開發環境裏

Lucene是一個成熟的免費開放源代碼工具；就其自己而論，

Lucene是如今而且是這幾年，最受歡迎的免費Java信息檢索程序庫。

Solr是使用Lucene的企業搜索服務器，亦由Apache軟件基金會所研發。

kibana：從elasticsearch中抽取數據進行展現+生成圖表

Kibana自帶Node.js Web服務器，無需額外代碼或額外基礎設施。

若是想安全套件的話，能夠購買官方的企業版本，若是以爲基礎功可以用

也可使用nginx反代並啓用basic authentication也不錯

引用aws對kibana的描述：

開源數據可視化和挖掘工具

能夠用於日誌和時間序列分析、應用程序監控和運營智能使用案例。

Kibana與Elasticsearch這種常見的分析和搜索引擎緊密集成，

成爲了將Elasticsearch中存儲的數據可視化時的默認選擇。

Kibana之因此受歡迎還由於其易於使用的強大功能，

如柱狀圖、線形圖、餅狀圖、熱區圖和內置地理空間支持。

因爲logstash基於java語言研發，若是運行在業務服務器上會有較大的資源損耗，因而就有了把logstash

的功能進行拆解，也就是在原始架構了多一層，造成了如下架構：

四層架構：

第一層：lostash-agent：收集日誌+發送給logstash-indexer，不作日誌解析

第二層：logstash-indexer：解析從logstash-agent傳送過來的日誌+發送給elasticsearch

第三層：elasticsearch：索引日誌+存儲日誌+提供檢索API

第四層：kibana：從elasticsearch中抽取數據進行展現+生成圖表

因爲logstash自己是不存儲日誌自己的，若是多臺服務器同時使用logstash-agent向logstash-indexer

發送大量日誌數據，對logstash-indexer來講壓力會很是大，而且極有可能出現數據丟失的狀況，因此有

給logstash-agent和logstash-indexer之間添加一層消息隊列需求，因而在上面四層的基礎上，又多出了

一層，造成了比較完善的架構：

五層架構：

第一層：lostash-agent：收集日誌+發送給message-queue，不作日誌解析

第二層：message-queue：專業緩存logstash-agent發送過來的大量日誌數據（經常使用隊列：kafka/redis……）

第三層：logstash-indexer：從message-queue中取出數據並進行解析，解析完成後發送給elasticsearch

第四層：elasticsearch：索引日誌+存儲日誌+提供檢索API

第五層：kibana：從elasticsearch中抽取數據進行展現+生成圖表

第二層引用了消息隊列，須要咱們考慮消息隊列的選型問題：

須要咱們考慮的是若是前端全部的logstash-agent送往消息隊列的數據量不是特殊大的狀況，能夠先用redis

作爲消息隊列，但須要明白redis默認是基於內存的消息隊列，若是內存不足夠，但便會致使內存充滿後的消息

將會被redis自動丟棄，也就會帶來數據丟失問題。其二，redis的是基於分佈式pub/sub插件來實現，消息不可

重複消費。

若是對於以上方案不太滿意，能夠考慮使用kafka來作分佈式的消息隊列，kafka對於併發數據流很是大的場景

可以有很好的支持，kafka默認使用磁盤存儲隊列數據，所能容納的數據量以及數據的可行性顯然比redis要強大。

其次，kafka的消息支持重複消費。但kafka自身就是分佈式的架構，因此須要有分佈式集羣管理工具，默認使用

同一流派的zookeeper，此二者都是基於java語言研發的，安裝時須要安裝jdk環境。

因爲logstash始終是比較重量級，因而就有了filebeat替換logstash-agent收集日誌，因此上面的層次沒變

只是第一層的實現方式變了，因此最終的架構演變以下：

最流行架構：

第一層：filebeat：收集日誌+發送給message-queue，不提供日誌解析功能

第二層：message-queue：專業緩存logstash-agent發送過來的大量日誌數據（經常使用隊列：kafka/redis……）

第三層：logstash-indexer：從message-queue中取出數據並進行解析，解析完成後發送給elasticsearch

第四層：elasticsearch：索引日誌+存儲日誌+提供檢索API

第五層：kibana：從elasticsearch中抽取數據進行展現+生成圖表

filebeat：基於go語言研發，相對logstash來講要輕量的太多，作爲agent端安裝在各個業務服務器上不用擔憂佔用

太多的服務器資源。

如今的企業大多使用的是深化到最後的這一套架構，相比之下，最後的這套五層架構也是至關成熟及穩定了，若是有想

上日誌系統的朋友建議能夠考慮使用filebeat+kafka（zookeeper）+logstash+elasticsearch+kibana這套架構。

畢竟考慮到後期後的擴容以及優化操做都比較有利。

這是給你們簡單的分享了一下ELK架構的演變之路，寫的比較粗糙，基礎理論知識請自行學習。本系列博文適合有必定基礎

的同仁閱讀參考。