背景
一直對ELK一知半解，之前看到別人提到的好處，自己沒有搭建過，在此，做一個學習筆記，爲將來搭建儲備一些知識。
本文主要參考了一篇網上的文章，主要對自己感興趣的內容寫了一些理解，更多的內容參見原文鏈接
ELK架構
首先要對ELK大體的架構有所瞭解，這樣對後面每個組件的學習，才能夠做到心中有數，從網上找到了這張圖，感覺很適合我的學習。從圖中可以看出，整個ELK平臺各個組件的作用如下：
Logstash收集AppServer產生的Log，並存放到ElasticSearch集羣中，而Kibana則從ES集羣中查詢數據生成圖表，再返回給Browser。可見，雖然簡稱是ELK，其實按照下圖的日誌採集順序來說，真正的簡稱應該是LEK。
從部署角度看，從網上找到了這段文字和一張圖，感覺寫的不錯，分享一下：
- 在每臺生成日誌文件的機器上，部署Logstash，作爲Shipper的角色，負責從日誌文件中提取數據，但是不做任何處理，直接將數據輸出到Redis隊列(list)中；1
- 需要一臺機器部署Logstash，作爲Indexer的角色，負責從Redis中取出數據，對數據進行格式化和相關處理後，輸出到Elasticsearch中存儲；
- 部署Elasticsearch集羣，當然取決於你的數據量了，數據量小的話可以使用單臺服務，如果做集羣的話，最好是有3個以上節點，同時還需要部署相關的監控插件；
- 部署Kibana服務，提供Web服務。
![ELK部署圖]()
下面就來逐個介紹LEK各個組件的作用。
LogStash
依然用一個圖來做解釋，從圖中可以看出LogStash的作用。其實就是輸入，過濾，輸出，起到了採集、處理、傳輸的作用。
ElasticSearch
ES之前也看過不少文章，曾經也有項目使用過，個人最大的感受是，ES特別耗費資源，如果項目涉及的服務或者機器不多，建議使用ES要慎重。畢竟單點ES方案並不是長遠之計，如果要建立ES集羣的話，需要注意以下幾點：
- 關於集羣節點，第一，節點類型包括：候選Master節點、數據節點和Client節點。通過設置兩個配置項node.master和node.data爲true或false，來決定將一個節點分配爲什麼類型的節點。第二，儘量將候選Master節點和Data節點分離開，通常Data節點負載較重，需要考慮單獨部署。
- 關於內存，Elasticsearch默認設置的內存是1GB，對於任何一個業務部署來說，這個都太小了。通過指定ES_HEAP_SIZE環境變量，可以修改其堆內存大小，服務進程在啓動時候會讀取這個變量，並相應的設置堆的大小。建議設置系統內存的一半給Elasticsearch，但是不要超過32GB。
- 關於存儲，Elasticsearch默認將數據存儲在/var/lib/elasticsearch路徑下，隨着數據的增長，一定會出現硬盤空間不夠用的情形，此時就需要給機器掛載新的硬盤，並將Elasticsearch的路徑配置到新硬盤的路徑下。通過“path.data”配置項來進行設置，比如“path.data: /data1,/var/lib/elasticsearch,/data”。需要注意的是，同一分片下的數據只能寫入到一個路徑下，因此還是需要合理的規劃和監控硬盤的使用。
Kibana筆記
Kibana提供的是數據查詢和顯示的Web服務，有豐富的圖表樣板，能滿足大部分的數據可視化需求，這也是很多人選擇ELK的主要原因之一。UI的操作沒有什麼特別需要介紹的，經常使用就會熟練。
爲什麼採用redis，原文中有解釋，有興趣的可以去學習一下。 ↩︎