ELK 日志中心分布式架構的逐步演化

當前環境

1. logstash：5.2

說明

記得寫 “基于ELK+Filebeat搭建日志中心” 時，有朋友跟我說：“你的日志中心缺少了消息隊列。” 是的，沒有考慮。因為暫時用不到，架構的演變一定是根據業務的發展逐步完成的。我覺得任何東西，太少或太過都未必是好事。構架能滿足公司當前的發展，那就是好的。

當然我不是指架構可以隨意設計，只要滿足需求就好。我們設計的架構，滿足現有需求當然是先決條件，但還得看得到可預見的未來，為架構的演進預留一定的擴展性。

所以架構既得滿足公司業務，還要參考一些成熟的方案，不能生搬硬套。這也是我也這篇文章的原因，自知能力有限，要講分布式我肯定講不好，其中勢必有很多坑。所以借鑒官網原文，給目前或今后要做分布式的同學一點建議（當然也包括我~）。

這里我不會對原文逐字翻譯，會根據自己的理解，以我自己能看懂的表述來翻譯給大家看。

概述

當Logstash的使用場景逐步演進時，我們之前的架構也將隨之發生改變。本文討論了在復雜度逐漸遞增下的Logstash架構一系列的演變過程。我們先從一個最簡單的架構開始，然后在此架構上來逐漸增加內容。本文的示例是將數據寫入到了ES（ Elasticsearch ）集群，其實Logstash可以寫的 輸出源 非常多。

最簡架構

Logstash最簡單的架構可以由一個Logstash實例和一個ES實例組成，兩者直接相連。按照Logstash的 處理流程 ，我們使用了一個收集數據的 INPUT插件 和一個數據寫入ES的 OUTPUT插件 ，最后按照實例配置文件上的固定配置，啟動Logstash。配置文件中，INPUT插件與OUTPUT插件是必須的，且OUTPUT默認輸出方式是stdout，FILTER是可選的，下文會講到。

引入 Filters

日志數據默認是無結構化的，經常包含一些無用信息，有時也會丟失一些本可從日志中獲取的相關信息。你可以使用 FILTER插件 來解析你的日志，從中提取有效字段，剔除無用的信息，還可以從有效字段中衍生出額外信息。例如，filters可以從IP地址中衍生出地理信息，將其添加進日志中，也可以使用 grok filter 解析文本信息，使其結構化。

當然，添加FILTER插件對性能是有一定影響的。這取決于FILTER插件執行的計算量，以及處理的日志大小。grok filter的正則計算尤其占用資源。解決資源消耗大的一種方式是利用計算機多核的特性進行并行計算。使用 -w 參數來設置 Logstash filter 任務的執行線程數。例如，bin/logstash -w 8 命令使用的是8個不同的線程來處理filter。

引入 Filebeat

Filebeat 是一款有Go語言編寫的輕量級日志收集工具，主要作用是收集當前服務器上的日志，并將收集的數據輸出到目標機器上進行進一步處理。Filebeat 使用 Beats 協議與Logstash實例進行通信。使用 Beats input 插件 來配置你的Logstash的實例，讓其能夠接收Beats傳來的數據。

Filebeat使用的是源數據所在機器的計算資源，Beats input 插件最小化了Logstash實例的資源需求，這種架構對于有資源限制要求的場景來說，非常有用。

引入ES集群

Logstash 一般不與ES的單節點進行通信，而是和多個節點組成的ES集群進行通信，采用的協議默認是HTTP。

你可以使用ES提供的REST API接口向集群寫入數據，傳輸的數據格式為JSON。使用REST接口在代碼中不需要引入JAVA的客戶端類或任何額外的JAR包。相比節點協議與傳輸格式，沒有性能上的弊端。若要做到接口安全通信，可以使用 X-Pack Security ，它支持SSL與HTTP basic的安全校驗。

當你使用HTTP協議時，可以在Logstash的 ES output 插件配置中，提供ES集群的多個請求地址，ES的請求將自動做到負載均衡。多個ES節點通過路由流量到活躍節點的方式也為ES集群提供的高可用性。

你也可以使用ES的 JAVA API將數據序列化為二進制后，再進行傳輸。該協議可以嗅探請求的地址，你可以選擇集群中任意的客戶端或節點進行通信。

使用HTTP，可以將ES集群與Logstash實例相分離。 與此相反，節點協議把運行Logstash實例的機器作為一個運行中的ES節點，與ES集群連接在了一起。數據同步是將數據從一個節點傳輸至集群中的其余節點。當該機器作為集群的一部分，該段網絡拓撲變得可用，對于使用相對少量持久連接的場景來說，使用節點協議是較合適的。

你也可以使用第三方的負載均衡硬件或軟件，來處理Logstash與外部應用的連接。

注意：確保你的Logstash配置不直接連接到ES 管理集群的主節點 上。將Logstash連接到客戶端或數據節點上，來保護ES集群的穩定性。

使用消息隊列處理吞吐量峰值

當Logstash接收數據的能力超過了ES集群處理數據的能力時，你可以使用消息隊列來作為緩沖。默認情況下，當數據的處理速率低于接收速率，Logstash的接收將產生瓶頸。由于該瓶頸會導致事件在數據源中被緩沖，所以使用消息隊列來抗壓將成為你架構中的重要環節。

添加一個消息隊列到你部署的Logstash中，對數據丟失也提供了一定的保護。當Logstash實例在消息隊列中消費數據失敗時，數據將會在另一個活躍的Logstash中重新消費。

目前市面上提供的第三方消息隊列，如Redis，Kafka，RabbitMQ。Logstash都提供了相應的input、output插件與之做集成。當Logstash的部署中添加了消息隊列，Logstash的處理將分為兩個階段：第一階段（傳輸實例），負責處理數據采集，并將其存入消息隊列；第二階段（存儲實例），從消息隊列中獲取數據，應用所配置的filter，將處理過的數據寫入ES中。

采用多連接保證Logstash高可用

為了使Logstash架構更適應單節點不可用的情況，，你可以在數據源與Logstash集群間建立負載均衡。這個負載均衡管理與Logstash實例的連接，保證了在單個實例不可用的情況下，數據采集與處理的正常進行。

上面的架構中存在一種問題，每個Logstash實例都只提供一種INPUT。當某一個實例不可用時，該類型的數據將無法繼續收集，例如RSS訂閱或文件輸入。為了使INPUT的處理更健壯，每個Logstash實例都要配置多個input通道，如下圖：

該架構基于你配置的INPUT，可以并行工作。對于更多的INPUT輸入，你可以增加更多的Logstash實例來進行水平擴展。這也增加了架構的可靠性，消除了單點故障。

Logstash的擴展

一個成熟的Logstash部署有以下幾方面：

• INPUT層從數據源中采集數據，由合適的input 插件組成。
• 消息隊列作為數據采集的緩沖與故障轉移的保護。
• FILTER層從消息隊列中獲取數據進行解析和其他操作。
• indexing層將處理的數據傳輸到ES。

這其中的每一層都可以通過增加計算資源進行擴展。隨著你使用場景的發展與所需資源的增加，定期檢查這些組件的性能。當Logstash一旦遇到輸入的瓶頸，可考慮增加消息隊列的存儲。相反，通過增加更多的Logstash輸出實例來增加ES集群的寫入速率。

 

來自：https://github.com/jasonGeng88/blog/blob/master/201703/logstash_deploye_scale.md