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