1 ELK架構介紹
1.1 核心組成
這三款軟件都是開源軟件，通常是配合使用，而且又先后歸於Elastic.co公司名下，故又被簡稱為ELK Stack。下圖是ELK Stack的基礎組成。
1.2 Elasticsearch介紹
Elasticsearch是一個實時的分布式搜索和分析引擎，它可以用於全文搜索，結構化搜索以及分析，采用Java語言編寫。它的主要特點如下：
-
實時搜索，實時分析
-
分布式架構、實時文件存儲，並將每一個字段都編入索引
-
文檔導向，所有的對象全部是文檔
-
高可用性，易擴展，支持集群（Cluster）、分片和復制（Shards和Replicas）
-
接口友好，支持JSON
Elasticsearch支持集群架構，典型的集群架構如下圖所示：
從圖中可以看出，Elasticsearch集群中有Master Node和Slave Node兩種角色，其實還有一種角色Client Node，這在后面會做深入介紹。
1.3 Logstash介紹
Logstash是一款輕量級的、開源的日志收集處理框架，它可以方便的把分散的、多樣化的日志搜集起來，並進行自定義過濾分析處理，然后傳輸到指定的位置，比如某個服務器或者文件。Logstash采用JRuby語言編寫，它的主要特點如下：
Logstash的理念很簡單，從功能上來講，它只做三件事情：
-
input：數據收集
-
filter：數據加工，如過濾，改寫等
-
output：數據輸出
別看它只做三件事，但通過組合輸入和輸出，可以變幻出多種架構實現多種需求。Logstash內部運行邏輯如下圖所示：
其中，每個部分含義如下：
-
Shipper：主要用來收集日志數據，負責監控本地日志文件的變化，及時把日志文件的最新內容收集起來，然后經過加工、過濾，輸出到Broker。
-
Broker：相當於日志Hub，用來連接多個Shipper和多個Indexer。
-
Indexer：從Broker讀取文本，經過加工、過濾，輸出到指定的介質（可以是文件、網絡、elasticsearch等）中。
Redis服務器是logstash官方推薦的broker，這個broker起數據緩存的作用，通過這個緩存器可以提高Logstash shipper發送日志到Logstash indexer的速度，同時避免由於突然斷電等導致的數據丟失。可以實現broker功能的還有很多軟件，例如kafka等。
這里需要說明的是，在實際應用中，LogStash自身並沒有什么角色，只是根據不同的功能、不同的配置給出不同的稱呼而已，無論是Shipper還是Indexer，始終只做前面提到的三件事。
這里需要重點掌握的是logstash中Shipper和Indexer的作用，因為這兩個部分是logstash功能的核心。
1.4 kibana介紹
Kibana是一個開源的數據分析可視化平台。使用Kibana可以為Logstash和ElasticSearch提供的日志數據進行高效的搜索、可視化匯總和多維度分析，還可以與Elasticsearch搜索引擎之中的數據進行交互。它基於瀏覽器的界面操作可以快速創建動態儀表板，實時監控ElasticSearch的數據狀態與更改。
1.5 ELK工作流程
一般都是在需要收集日志的所有服務上部署logstash，作為logstash shipper用於監控並收集、過濾日志，接着，將過濾后的日志發送給Broker，然后，Logstash Indexer將存放在Broker中的數據再寫入Elasticsearch，Elasticsearch對這些數據創建索引，最后由Kibana對其進行各種分析並以圖表的形式展示。
有些時候，如果收集的日志量較大，為了保證日志收集的性能和數據的完整性，logstash shipper和logstash indexer之間的緩沖器（Broker）也經常采用kafka來實現。
在這個圖中，要重點掌握的是ELK架構的數據流向，以及logstash、Elasticsearch和Kibana組合實現的功能細節。
2 ZooKeeper基礎與入門
2.1 ZooKeeper概念介紹
在介紹ZooKeeper之前，先來介紹一下分布式協調技術，所謂分布式協調技術主要是用來解決分布式環境當中多個進程之間的同步控制，讓他們有序的去訪問某種共享資源，防止造成資源競爭（腦裂）的后果。
這里首先介紹下什么是分布式系統，所謂分布式系統就是在不同地域分布的多個服務器，共同組成的一個應用系統來為用戶提供服務，在分布式系統中最重要的是進程的調度，這里假設有一個分布在三個地域的服務器組成的一個應用系統，在第一台機器上掛載了一個資源，然后這三個地域分布的應用進程都要競爭這個資源。
但我們又不希望多個進程同時進行訪問，這個時候就需要一個協調器，來讓它們有序的來訪問這個資源。這個協調器就是分布式系統中經常提到的那個“鎖”。
例如"進程1"在使用該資源的時候，會先去獲得這把鎖，"進程1"獲得鎖以后會對該資源保持獨占，此時其它進程就無法訪問該資源，"進程1"在用完該資源以后會將該鎖釋放掉，以便讓其它進程來獲得鎖。由此可見，通過這個“鎖”機制，就可以保證分布式系統中多個進程能夠有序的訪問該共享資源。這里把這個分布式環境下的這個“鎖”叫作分布式鎖。這個分布式鎖就是分布式協調技術實現的核心內容。
綜上所述，ZooKeeper是一種為分布式應用所設計的高可用、高性能的開源協調服務，它提供了一項基本服務：分布式鎖服務，同時，也提供了數據的維護和管理機制，如：統一命名服務、狀態同步服務、集群管理、分布式消息隊列、分布式應用配置項的管理等等。
2.2 ZooKeeper應用舉例
這里以ZooKeeper提供的基本服務分布式鎖為例進行介紹。在分布式鎖服務中，有一種最典型應用場景，就是通過對集群進行Master角色的選舉，來解決分布式系統中的單點故障問題。所謂單點故障，就是在一個主從的分布式系統中，主節點負責任務調度分發，從節點負責任務的處理，而當主節點發生故障時，整個應用系統也就癱瘓了，那么這種故障就稱為單點故障。
解決單點故障，傳統的方式是采用一個備用節點，這個備用節點定期向主節點發送ping包，主節點收到ping包以后向備用節點發送回復Ack信息，當備用節點收到回復的時候就會認為當前主節點運行正常，讓它繼續提供服務。而當主節點故障時，備用節點就無法收到回復信息了，此時，備用節點就認為主節點宕機，然后接替它成為新的主節點繼續提供服務。
這種傳統解決單點故障的方法，雖然在一定程度上解決了問題，但是有一個隱患，就是網絡問題，可能會存在這樣一種情況：主節點並沒有出現故障，只是在回復ack響應的時候網絡發生了故障，這樣備用節點就無法收到回復，那么它就會認為主節點出現了故障，接着，備用節點將接管主節點的服務，並成為新的主節點
此時，分布式系統中就出現了兩個主節點（雙Master節點）的情況，雙Master節點的出現，會導致分布式系統的服務發生混亂。這樣的話，整個分布式系統將變得不可用。為了防止出現這種情況，就需要引入ZooKeeper來解決這種問題。
2.3 ZooKeeper工作原理
（1） Master啟動
在分布式系統中引入Zookeeper以后，就可以配置多個主節點，這里以配置兩個主節點為例，假定它們是"主節點A"和"主節點B"，當兩個主節點都啟動后，它們都會向ZooKeeper中注冊節點信息。
我們假設"主節點A"鎖注冊的節點信息是"master00001"，"主節點B"注冊的節點信息是"master00002"，注冊完以后會進行選舉，選舉有多種算法，這里以編號最小作為選舉算法，那么編號最小的節點將在選舉中獲勝並獲得鎖成為主節點，也就是"主節點A"將會獲得鎖成為主節點，
然后"主節點B"將被阻塞成為一個備用節點。這樣，通過這種方式Zookeeper就完成了對兩個Master進程的調度。完成了主、備節點的分配和協作。
（2） Master故障
如果"主節點A"發生了故障，這時候它在ZooKeeper所注冊的節點信息會被自動刪除，而ZooKeeper會自動感知節點的變化，發現"主節點A"故障后，會再次發出選舉，這時候"主節點B"將在選舉中獲勝，替代"主節點A"成為新的主節點，這樣就完成了主、被節點的重新選舉。
（3）Master恢復
如果主節點恢復了，它會再次向ZooKeeper注冊自身的節點信息，只不過這時候它注冊的節點信息將會變成"master00003"，而不是原來的信息。ZooKeeper會感知節點的變化再次發動選舉，這時候"主節點B"在選舉中會再次獲勝繼續擔任"主節點"，"主節點A"會擔任備用節點。
Zookeeper就是通過這樣的協調、調度機制如此反復的對集群進行管理和狀態同步的。
2.4 Zookeeper集群架構
Zookeeper一般是通過集群架構來提供服務的，下圖是Zookeeper的基本架構圖。
Zookeeper集群主要角色有Server和client，其中，Server又分為Leader、Follower和Observer三個角色，每個角色的含義如下：
-
Leader：領導者角色，主要負責投票的發起和決議，以及更新系統狀態。
-
Follower：跟隨者角色，用於接收客戶端的請求並返回結果給客戶端，在選舉過程中參與投票。
-
Observer：觀察者角色，用戶接收客戶端的請求，並將寫請求轉發給leader，同時同步leader狀態，但不參與投票。 Observer目的是擴展系統，提高伸縮性。
-
Client:客戶端角色，用於向Zookeeper發起請求。
Zookeeper集群中每個Server在內存中存儲了一份數據，在Zookeeper啟動時，將從實例中選舉一個Server作為leader，Leader負責處理數據更新等操作，當且僅當大多數Server在內存中成功修改數據，才認為數據修改成功。
Zookeeper寫的流程為：客戶端Client首先和一個Server或者Observe通信，發起寫請求，然后Server將寫請求轉發給Leader， Leader再將寫請求轉發給其它Server，其它Server在接收到寫請求后寫入數據並響應Leader，Leader在接收到大多數寫成功回應后，認為數據寫成功，最后響應Client，完成一次寫操作過程。
3 Kafka基礎與入門
3.1 kafka基本概念
Kafka是一種高吞吐量的分布式發布/訂閱消息系統，這是官方對kafka的定義，kafka是Apache組織下的一個開源系統，它的最大的特性就是可以實時的處理大量數據以滿足各種需求場景：比如基於hadoop平台的數據分析、低時延的實時系統、storm/spark流式處理引擎等。kafka現在它已被多家大型公司作為多種類型的數據管道和消息系統使用。
3.2 kafka角色術語
在介紹架構之前，先了解下kafka中一些核心概念和各種角色。
-
Broker：Kafka集群包含一個或多個服務器，每個服務器被稱為broker。
-
Topic：每條發布到Kafka集群的消息都有一個分類，這個類別被稱為Topic（主題）。
-
Producer：指消息的生產者，負責發布消息到Kafka broker。
-
Consumer :指消息的消費者，從Kafka broker拉取數據，並消費這些已發布的消息。
-
Partition：Parition是物理上的概念，每個Topic包含一個或多個Partition，每個partition都是一個有序的隊列。partition 中的每條消息都會被分配一個有序的id（稱為offset）。
-
Consumer Group:消費者組，可以給每個Consumer指定消費者組，若不指定消費者組，則屬於默認的group。
-
Message：消息，通信的基本單位，每個producer可以向一個topic發布一些消息。
3.3 Kafka拓撲架構
一個典型的Kafka集群包含若干Producer，若干broker、若干Consumer Group，以及一個Zookeeper集群。Kafka通過Zookeeper管理集群配置，選舉leader，以及在Consumer Group發生變化時進行rebalance。Producer使用push模式將消息發布到broker，Consumer使用pull模式從broker訂閱並消費消息。
3.4 Topic與Partition
Kafka中的topic是以partition的形式存放的，每一個topic都可以設置它的partition數量，Partition的數量決定了組成topic的log的數量。推薦partition的數量一定要大於同時運行的consumer的數量。另外，建議partition的數量大於集群broker的數量，這樣消息數據就可以均勻的分布在各個broker中。
那么，Topic為什么要設置多個Partition呢，這是因為kafka是基於文件存儲的，通過配置多個partition可以將消息內容分散存儲到多個broker上,這樣可以避免文件尺寸達到單機磁盤的上限。同時，將一個topic切分成任意多個partitions，可以保證消息存儲、消息消費的效率，因為越多的partitions可以容納更多的consumer，可有效提升Kafka的吞吐率。因此，將Topic切分成多個partitions的好處是可以將大量的消息分成多批數據同時寫到不同節點上，將寫請求分擔負載到各個集群節點。
3.5 Kafka消息發送的機制
每當用戶往某個Topic發送數據時，數據會被hash到不同的partition,這些partition位於不同的集群節點上，所以每個消息都會被記錄一個offset消息號，就是offset號。消費者通過這個offset號去查詢讀取這個消息。
發送消息流程為：
首先獲取topic的所有Patition，如果客戶端不指定Patition，也沒有指定Key的話，使用自增長的數字取余數的方式實現指定的Partition。這樣Kafka將平均的向Partition中生產數據。如果想要控制發送的partition，則有兩種方式，一種是指定partition，另一種就是根據Key自己寫算法。實現其partition方法。
每一條消息被發送到broker時，會根據paritition規則選擇被存儲到哪一個partition。如果partition規則設置的合理，所有消息可以均勻分布到不同的partition里，這樣就實現了水平擴展。同時，每條消息被append到partition中時，是順序寫入磁盤的,因此效率非常高，經驗證，順序寫磁盤效率比隨機寫內存還要高，這是Kafka高吞吐率的一個很重要的保證。
3.6 Kafka消息消費機制
Kafka中的Producer和consumer采用的是push（推送）、pull（拉取）的模式，即Producer只是向broker push消息，consumer只是從broker pull消息，push和pull對於消息的生產和消費是異步進行的。pull模式的一個好處是Consumer可自主控制消費消息的速率，同時Consumer還可以自己控制消費消息的方式是批量的從broker拉取數據還是逐條消費數據。
當生產者將數據發布到topic時，消費者通過pull的方式，定期從服務器拉取數據,當然在pull數據的時候，服務器會告訴consumer可消費的消息offset。
消費規則：
-
不同 Consumer Group下的消費者可以消費partition中相同的消息，相同的Consumer Group下的消費者只能消費partition中不同的數據。
-
topic的partition的個數和同一個消費組的消費者個數最好一致，如果消費者個數多於partition個數，則會存在有的消費者消費不到數據。
-
服務器會記錄每個consumer的在每個topic的每個partition下的消費的offset,然后每次去消費去拉取數據時，都會從上次記錄的位置開始拉取數據。
3.7 Kafka消息存儲機制
在存儲結構上，每個partition在物理上對應一個文件夾，該文件夾下存儲這個partition的所有消息和索引文件，每個partion(目錄)相當於一個巨型文件被平均分配到多個大小相等segment(段)數據文件中。
partiton命名規則為topic名稱+序號，第一個partiton序號從0開始，序號最大值為partitions數量減1。
在每個partition (文件夾)中有多個大小相等的segment(段)數據文件，每個segment的大小是相同的，但是每條消息的大小可能不相同，因此segment 數據文件中消息數量不一定相等。
segment數據文件有兩個部分組成，分別為index file和data file，此兩個文件是一一對應，成對出現，后綴".index"和“.log”分別表示為segment索引文件和數據文件。
其實Kafka最核心的思想是使用磁盤，而不是使用內存，使用磁盤操作有以下幾個好處：
-
磁盤緩存由Linux系統維護，減少了程序員的不少工作。
-
磁盤順序讀寫速度超過內存隨機讀寫。
-
JVM的GC效率低，內存占用大。使用磁盤可以避免這一問題。
-
系統冷啟動后，磁盤緩存依然可用。
4 Filebeat基礎與入門
4.1 什么是Filebeat
Filebeat是一個開源的文本日志收集器,它是elastic公司Beats數據采集產品的一個子產品，采用go語言開發，一般安裝在業務服務器上作為代理來監測日志目錄或特定的日志文件，並把它們發送到logstash、elasticsearch、redis或Kafka等。可以在官方地址https://www.elastic.co/downloads/beats下載各個版本的Filebeat。
4.2 Filebeat架構與運行原理
Filebeat是一個輕量級的日志監測、傳輸工具，它最大的特點是性能穩定、配置簡單、占用系統資源很少。這也是強烈推薦Filebeat的原因。
從圖中可以看出，Filebeat主要由兩個組件構成： prospector（探測器）和harvester（收集器）。這兩類組件一起協作完成Filebeat的工作。
其中，Harvester負責進行單個文件的內容收集，在運行過程中，每一個Harvester會對一個文件逐行進行內容讀取，並且把讀寫到的內容發送到配置的output中。當Harvester開始進行文件的讀取后，將會負責這個文件的打開和關閉操作，因此，在Harvester運行過程中，文件都處於打開狀態。如果在收集過程中，刪除了這個文件或者是對文件進行了重命名，Filebeat依然會繼續對這個文件進行讀取，這時候將會一直占用着文件所對應的磁盤空間，直到Harvester關閉。
Prospector負責管理Harvster，它會找到所有需要進行讀取的數據源。然后交給Harvster進行內容收集，如果input type配置的是log類型，Prospector將會去配置路徑下查找所有能匹配上的文件，然后為每一個文件創建一個Harvster。
綜上所述，filebeat的工作流程為：當開啟filebeat程序的時候，它會啟動一個或多個探測器（prospector）去檢測指定的日志目錄或文件，對於探測器找出的每一個日志文件，filebeat會啟動收集進程（harvester），每一個收集進程讀取一個日志文件的內容，然后將這些日志數據發送到后台處理程序（spooler），后台處理程序會集合這些事件，最后發送集合的數據到output指定的目的地。
5 ELK常見應用架構
5.1 簡單的ELK應用架構
此架構主要是將Logstash部署在各個節點上搜集相關日志、數據，並經過分析、過濾后發送給遠端服務器上的Elasticsearch進行存儲。Elasticsearch再將數據以分片的形式壓縮存儲，並提供多種API供用戶查詢、操作。用戶可以通過Kibana Web直觀的對日志進行查詢，並根據需求生成數據報表。
此架構的優點是搭建簡單，易於上手。缺點是Logstash消耗系統資源比較大，運行時占用CPU和內存資源較高。另外，由於沒有消息隊列緩存，可能存在數據丟失的風險。此架構建議供初學者或數據量小的環境使用。
5.2 典型ELK架構
此架構主要特點是引入了消息隊列機制，位於各個節點上的Logstash Agent（一級Logstash，主要用來傳輸數據）先將數據傳遞給消息隊列（常見的有Kafka、Redis等），接着，Logstash server（二級Logstash，主要用來拉取消息隊列數據，過濾並分析數據）將格式化的數據傳遞給Elasticsearch進行存儲。最后，由Kibana將日志和數據呈現給用戶。由於引入了Kafka（或者Redis）緩存機制，即使遠端Logstash server因故障停止運行，數據也不會丟失，因為數據已經被存儲下來了。
這種架構適合於較大集群、數據量一般的應用環境，但由於二級Logstash要分析處理大量數據，同時Elasticsearch也要存儲和索引大量數據，因此它們的負荷會比較重，解決的方法是將它們配置為集群模式，以分擔負載。
此架構的優點在於引入了消息隊列機制，均衡了網絡傳輸，從而降低了網絡閉塞尤其是丟失數據的可能性，但依然存在Logstash占用系統資源過多的問題，在海量數據應用場景下，可能會出現性能瓶頸。
5.3 ELK集群架構
這個架構是在上面第二個架構基礎上改進而來的，主要是將前端收集數據的Logstash Agent換成了filebeat，消息隊列使用了kafka集群，然后將Logstash和Elasticsearch都通過集群模式進行構建，此架構適合大型集群、海量數據的業務場景，它通過將前端Logstash Agent替換成filebeat，有效降低了收集日志對業務系統資源的消耗。同時，消息隊列使用kafka集群架構，有效保障了收集數據的安全性和穩定性，而后端Logstash和Elasticsearch均采用集群模式搭建，從整體上提高了ELK系統的高效性、擴展性和吞吐量。