Elasticsearch的幾種架構性能對比測試報告
1.前言
選定了Elasticsearch作為存儲的數據庫，但是還需要對Elasticsearch的基礎架構做一定測試，所以，將研究測試報告輸出如下。
2.日志系統架構的基礎
2.1所需環境和依賴軟件
1）Elasticsearch：分布式存儲數據庫，用於存儲產生的日志，是架構和系統的核心所在。
2）Filebeat：輕量級日志收集器，可以自動將日志發送至Es或者logstash
3）Logstash：日志收集/清洗工具，將日志過濾，清洗后可以放入Es，並且可以減緩Es的訪問壓力，控制寫入速度。
2.2日志系統架構的基本思想
日志系統中，讀寫功能應該是最重要和最需要優化的地方，在不斷的有日志寫進和讀取的情況下，我們需要做到如下幾點：
1）緩解Es的讀寫壓力
2）降低日志系統資源占比
3）能夠處理日志系統一般的異常情況（如宕機等）
4）提高日志系統的健壯性和可用性
3.日志架構的對比評測
3.1測試環境
| 機器環境 |
機器內存 |
機器CPU |
機器IP |
| Centos7 |
6G |
4 |
10.0.6.244 |
| Centos7 |
6G |
4 |
10.0.6.247 |
| 服務名 |
版本 |
包大小 |
| Elasticsearch |
6.3.2 |
91M |
| filebeat |
6.5.1 |
11M |
| logstash |
6.5.1 |
161M |
3.2單純的Elasticsearch 集群
不需要任何轉發日志，緩存日志服務。直接接入Es的api寫入日志，沒有中間層，直接訪問Es，讀寫都是如此。詳細如下圖：
直接通過封裝好的Es_api進行數據讀寫，在上層將數據進行清洗或者是處理之后寫入Es。
測試分別導入500,1000,10000條數據。
Elasticsearch占用資源和系統壓力如下:
| 導入數據 |
Es占用內存 |
Es占用CPU |
導入時間 |
| 500條日志 |
22.3%（占用） |
2.3% |
1-3S |
| 1000條日志 |
22.6%（占用） |
2.3%-12% |
2-6S |
| 10000條日志 |
22.9%（占用） |
2.3%-40% |
9S |
適用場景：日志不多，但是需要分布式的系統，一萬條數據存儲的index大概是1.3M，兩台機器就是2.6M。
優點：
方便，開箱可用，模塊已經寫好了，直接上就可以，不需要其他依賴。數據格式可控。輸出方便。
缺點：
這種架構忽略了宕機和分片損壞的情況，如果宕機的話，Es選舉節點時無法導入數據，這樣會造成數據丟失。在機器資源不足的情況下，導入大規模數據的時候Es會卡死。需要在代碼層做處理，例如分批導入或者設置最大的導入數據值，增加代碼冗余量。
3.3 Elasticsearch 搭配 filebeat
什么是Filebeat：
Filebeat是一個日志收集器，Filebeat是一個日志文件托運工具，在你的服務器上安裝客戶端后，filebeat會監控日志目錄或者指定的日志文件，追蹤讀取這些文件（追蹤文件的變化，不停的讀），並且轉發這些信息到elasticsearch或者logstarsh中存放。
FIlebeat如何工作:
當你開啟filebeat程序的時候，它會啟動一個或多個探測器（prospectors）去檢測你指定的日志目錄或文件，對於探測器找出的每一個日志文件，filebeat啟動收割進程（harvester），每一個收割進程讀取一個日志文件的新內容，並發送這些新的日志數據到處理程序（spooler），處理程序會集合這些事件，最后filebeat會發送集合的數據到你指定的地點。
通過filebeat的機制，將指定日志的log文件自動收集然后發送到Es中。中間不會直接對接Es接口，可以指定傳輸進Es的條數。可以指定日志。
詳細邏輯如下圖：
Filebeat可以將日志轉發給logstash或者Es。
測試導入數據：
| 導入數據 |
Es占用內存 |
Es占用CPU |
Filebeats內存 |
導入時間 |
| 500條日志 |
22.3%（占用） |
2.3% |
1.32% |
1-2S |
| 1000條日志 |
22.6%（占用） |
2.3%-10% |
3.47% |
2-4S |
| 10000條日志 |
22.9%（占用） |
2.3%-20% |
6.7% |
7-12S |
適用場景：
數據量大，日志數量多，服務器資源有限的分布式日志系統。
原理和架構邏輯：
通過Filebeat這個日志生成器從指定的日志文件進行日志收集，收集到日志文件之后，將日志文件傳輸至logstash或者Elastaticsearch，並且FIlebeat有智能判斷，可以斷點續傳，可以從上次斷掉的位置繼續接力傳輸，只要log文件在更新，那么Filebeat的傳輸將不會停止。
優點：
斷點續傳，直接輸入Es，速度快，避免直接寫入Es造成服務器壓力過大，資源占用小，可以做簡單的分類。可以指定每次傳入條數等。
缺點：
不能進行數據清洗，數據雜亂，只能做簡單的日志傳輸器用。
3.4 Elasticsearch 搭配logstash
什么是logstash：
Logstash 是一個輕量級、開源的服務器端數據處理管道，允許各種來源收集數據，進行動態轉換，並將數據發送到希望的目標。它最常用作 Elasticsearch 的數據管道，Elasticsearch 是一個開源分析和搜索引擎。由於它與 Elasticsearch 緊密集成，具備強大的日志處理功能並提供 200 多個預構建的開源插件來索引數據，因此 Logstash 是將數據加載到 Elasticsearch 的常用工具。
Logstash的工作原理：
Logstash 內部也是管道的方式進行數據的搜集、處理、輸出。在 Logstash 中，包括了三個階段:
輸入 input --> 處理 filter（不是必須的） --> 輸出 output。
每個階段都由很多的插件配合工作，比如 file、elasticsearch、redis 等等。
每個階段也可以指定多種方式，比如輸出既可以輸出到 Elasticsearch 中，也可以指定到 stdout 在控制台打印。
Logstash的工作邏輯如下圖：
測試導入數據：
| 導入數據 |
Es占用內存 |
Es占用CPU |
logstash內存 |
導入時間 |
| 500條日志 |
23%（占用） |
1.0% |
11.4% |
1-2S |
| 1000條日志 |
23.2%（占用） |
2.3%-13% |
16.3% |
10-22S |
| 10000條日志 |
22.9%（占用） |
5%-32% |
17.2% |
30-33S |
Logstash優點：
1.可伸縮性
2.節拍應該在一組Logstash節點之間進行負載平衡。
3.建議至少使用兩個Logstash節點以實現高可用性。
4.每個Logstash節點只部署一個Beats輸入是很常見的，但每個Logstash節點也 可以部署多個Beats輸入，以便為不同的數據源公開獨立的端點。
5.彈性：Logstash持久隊列提供跨節點故障的保護。對於Logstash中的磁盤級彈 性，確保磁盤冗余非常重要。
6.可過濾：對事件字段執行常規轉換。可以重命名，刪除，替換和修改事件中的 字段。可擴展插件生態系統，提供超過200個插件，以及創建和貢獻自己的靈活 性。
Logstash缺點：
Logstash耗資源較大，運行占用CPU和內存高。另外沒有消息隊列緩存，存在數 據丟失隱患。Logstash設置jvm小了啟動很慢或者會啟動失敗。
3.5 Elasticsearch 搭配logstash和Filebeat
架構圖如下所示：
這種架構在日志數據源和 Logstash（或 Elasticsearch） 中增加了 Beats 。Beats 集合了多種單一用途數據采集器，每款采集器都是以用於轉發數據的通用庫 libbeat 為基石，beat 所占的系統CPU和內存幾乎可以忽略不計，libbeat平台還提供了檢測機制，當下游服務器負載高或網絡擁堵時，會自動降低發生速率。
流程圖：
Filebeat將日志發送給Logstash進行分析和過濾，然后由Logstash轉發給Elasticsearch。
優點：
全面，穩定，在網絡阻塞的情況下可以很方便的處理問題，讓日志不至於丟失。
缺點：
占用過大內存，消耗過多資源，Es+logstash加在一起消耗的資源過多，日志系統沒有那么多數據量的話就可以不用搭建這套系統。