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架構的演變之路，寫的比較粗糙，基礎理論知識請自行學習。本系列博文適合有一定基礎
的同仁閱讀參考。