Day 2 Elastic Stack(ELK)架構及介紹

前言

上一篇我們簡單介紹了ElasticCloud的最佳主角-ElasticSearch，以及提到大家耳熟能詳的ELK，簡介了ELK原來是包含三個東西－Elasticsearch、Logstash、Kibana。

今天接續著上次的主題，我們會稍微深入一點的介紹這三者，主要會放著三者如何運作；接著我們會進入本次競賽的主要重點，Elastic Cloud，這邊我們會先介紹一下何謂ElasticCloud，以及他比起其他種作法(在GCP or AWS上架設ELK、自己機房電腦架設)的差別；最後因為本次主軸會是ElasticCloud，因此會提一下相較其他種作法他的優點(可能同時也會是缺點)

Elastic Stack

Elastic Stack，前面提到其實就是ELK，而這三樣東西的結合，勢必是有它的意義。首先先上圖：

由上面這個簡圖，我們可以看出三者在架構中扮演的角色，其中LogStash扮演的是
Indexer以及Shipper的角色；Elasticsearch扮演的是Search&Storage；Kibana則是Web Interface

整體運作模式就是，Logstash蒐集Log，透過Broker(這邊是透過Redis，當然也可以透過Kafka或是message queue工具，主要負責多手去蒐集以及暫存log)接著傳遞給予Logstash運作進行Index的動作，這邊大家可以想像成是將這些Log去做標籤的動作。最後儲存在Elasticsearch中，可以供查詢以及其他應用；Kibana在進行web介面上的串接，前端視覺化等等。

所以整體來說，三者是有一個很好的分工以及溝通機制，而這一套流程，大家可能會覺得很虛無縹緲，那我們講一個實際生活中類似的案例。

假設今天我們經營一個圖書館，圖書館會收來自各地的捐贈書籍。所以各地捐贈書籍的蒐集，就是透過Logstash在運作；接著透過許多物流(單一或分散的)這也就是redis、message queue的工作；蒐集到館內以後，我們需要對他做書籍編碼，也就是大家去圖書館借書時的流水號；建好索引號以後，就會存放在各櫃。而整個存放空間就是elasticsearch，可以存放，也可以隨時拿出來。而因為有分櫃分區，也可以拿出不同類別的書。而Kibana，大家可以想像可能就會是一個虛擬的線上圖書館，展示這些書的一個存放狀況。

透過上面相信大家比較知道這三者的分工，下次簡單介紹一下三者。

Elastic Search

上一章節已經提過了，elasticsearch就是一個作為存取，以及進行搜尋引擎演算法的一個啟動，可以透過部屬去串聯多台達到分散式cluster的效果

Logstash

Logstash可以將蒐集的Log進行處理，將純文字透過正規表示parse成統一格式，讓後續的存取以及查詢更加方便且合理

Kibana

前端的呈現，不管是logstash或是elasticsearch本身狀況，以及建立的index狀況，可以呈現資料查詢結果、視覺化以及Dashboard

後記

昨天我們簡單介紹了Elasticsearch，以及略提到了ELK，今天我們詳細講解了ELK整體架構，每個服務負責的部分。明天會介紹Elastic Cloud，以及以一個初學者來說，如何選擇建構一個屬於自己的ELK服務。介紹部分基本上到明天就會結束，後續就會開始切入實際應用，建構一個Elastic Cloud以及實際上的操作，前面這些介紹在後面實際應用就會一直遇到！