日誌系統（FileBeats+elasticSearch+Kibana）
FileBeats+elasticSearch+Kibana 統一版本 7.3.2
環境：window10 64位
FileBeats
filebeat中文指南：https://elkguide.elasticsearch.cn/elasticsearch/performance/bulk.html
什麼是FileBeats？
輕量級的日誌處理工具
在你的服務器上安裝客戶端後，filebeat會監控日誌目錄或者指定的日誌文件，追蹤讀取這些文件（追蹤文件的變化，不停的讀），並且轉發這些信息到elasticsearch或者logstarsh中存放
官方文檔：elastic.co/guide/en/beats/filebeat/current/filebeat-installation.html
下載壓縮包zip格式 版本7.3.2
安裝步驟：
-
從下載頁面下載Filebeat Windows zip文件 。
-
將zip文件的內容解壓縮到
C:\Program Files。 -
將
filebeat-<version>-windows目錄重命名爲Filebeat。 -
windows10 自帶有windows PowerShell,直接在左下角搜索框中輸入PowerShell，直接打開（默認管理員權限）/以管理員身份打開PowerShell （右鍵單擊PowerShell圖標，然後選擇“以管理員身份運行”）
-
在PowerShell提示符下，運行以下命令將Filebeat安裝爲Windows服務：
進入安裝目錄下：
PS > cd 'C:\Program Files\Filebeat' PS C:\Program Files\Filebeat> .\install-service-filebeat.ps1
注意：如果在系統上禁用了腳本執行，則需要爲當前會話設置執行策略以允許腳本運行:
PowerShell.exe -ExecutionPolicy UnRestricted -File .\install-service-filebeat.ps1`。
filebeat.yml配置：
filebeat.inputs:
- type: log
enabled: true
#定義日誌文件的路徑
paths:
#默認配置位置
- D:\filebeat\var\log\*.log
#- D:\log\*.log
#- c:\programdata\elasticsearch\logs\*
此示例中的輸入收集路徑中的所有文件D:\filebeat\var\log\*.log，這意味着Filebeat將收集目錄/var/log/結尾的所有文件.log`。
測試是否讀到文件並輸出到filebeat臨時文件：
注意：輸出文件名稱是默認的，可以自己改動
加入配置：
output.file:
path: "D:/filebeat/logs/"
filename: filebeat
rotate_every_kb: 10240
number_of_files: 7
permissions: 0600
關閉連接elasticSearch的輸出
#output.elasticsearch:
# Array of hosts to connect to.
# hosts: ["localhost:9200"]
# Optional protocol and basic auth credentials.
#protocol: "https"
#username: "elastic"
#password: "changeme"
注意：不能沒有輸出，也不能配置多個輸出 否則filebeat啓動不了
filebeat原理：
Filebeat包含兩個主要組件：input[輸入]和harvester[收割機/收集器]。這些組件一起工作以尾部文件並將事件數據發送到您指定的輸出。
缺點：
filebeat官方提供的功能比較單一，往往無法滿足我們的需求（比如說允許寫入Redis但不允許從Reids中讀出來，若需要讀則需要藉助logstash這樣笨重的組件。不允許寫到Metaq/rabbitmq一類的中間件做消息存儲以緩解ES端的壓力）
filebeat的性能瓶頸在publish層面。也就是write to es的效率不盡如人意。
什麼是harvester？
harvester負責讀取單個文件的內容。收割機逐行讀取每個文件，然後將內容發送到輸出。每個文件啓動一個harvester。harvester負責打開和關閉文件，這意味着在harvester運行時文件描述符保持打開狀態。如果在收集文件時將其刪除或重命名，Filebeat將繼續讀取該文件。這樣做的副作用是磁盤上的空間將保留，直到收割機關閉爲止。默認情況下，Filebeat保持文件打開直到close_inactive到達。
關閉收割機有以下後果：
-
關閉文件處理程序，如果在收割機仍在讀取文件時刪除了文件，則釋放了基礎資源。
-
只有在
scan_frequency經過之後，纔會再次開始文件的收集。 -
如果在harvester關閉時移動或刪除文件，則文件的收割將不會繼續。
什麼是輸入？
輸入負責管理harvester並查找所有可讀取的資源。
指定類型例如：log,則輸入將在驅動器上找到與定義的全局路徑匹配的所有文件，併爲每個文件啓動harvester。每個輸入都在其自己的Go例程中運行。
如果自harvester關閉，原來文件的大小已更改，則僅拾取新行。不會再從頭讀取。
filebeat如何保持文件的狀態？
Filebeat保留每個文件的狀態，並經常將狀態刷新到註冊表文件中的磁盤。 該狀態用於記住harvester正在讀取的最後一個偏移量，並確保發送所有日誌行。如果無法到達輸出（例如Elasticsearch或Logstash），則Filebeat會跟蹤發送的最後幾行，並在輸出再次變爲可用時繼續讀取文件(重新開啓輸入，則會繼續讀取文件)。在Filebeat運行時，狀態信息也保存在內存中，用於每個輸入。重新啓動Filebeat時，將使用註冊表文件中的數據來重建狀態，並且Filebeat會在最後一個已知位置繼續每個harvester。
Filebeat檢測文件是否被掃描：對於每個輸入，Filebeat會保留找到的每個文件的狀態。由於可以重命名或移動文件，因此文件名和路徑不足以標識文件。對於每個文件，Filebeat都存儲唯一的標識符以檢測文件是否以前被收穫過。
ignore_older
如果啓用此選項，Filebeat將忽略在指定時間範圍之前修改的所有文件。ignore_older如果長時間保留日誌文件，則配置特別有用。例如，如果要啓動Filebeat，但只想發送最新的文件和上週的文件，則可以配置此選項。
必須設置ignore_older爲大於close_inactive
受此設置影響的文件分爲兩類：
-
從未收集過的文件
-
收穫但未更新的文件的時間不超過 ignore_older
對於以前從未見過的文件，偏移狀態設置爲文件末尾。如果狀態已經存在，則偏移量不會更改。如果以後再次更新文件，則在設置的偏移位置繼續讀取。
該ignore_older設置取決於文件的修改時間，以確定是否忽略文件。如果將行寫入文件時文件的修改時間未更新（在Windows上ignore_older可能會發生），即使稍後添加了內容，此 設置也可能導致Filebeat忽略文件。
要從註冊表文件中刪除先前收集的文件的狀態，請使用clean_inactive配置選項。
在使用Filebeat忽略文件之前，必須先關閉該文件。爲確保在忽略文件時不再收集文件，您必須將ignore_older持續時間設置 爲長於close_inactive。
如果當前正在收集的文件屬於ignore_older，則收集器將首先完成讀取文件並在close_inactive 到達後將其關閉。然後，此後，該文件將被忽略
您可以使用2h（2小時）和5m（5分鐘）之類的時間字符串。默認值爲0，這將禁用設置。註釋掉配置與將其設置爲0具有相同的效果。
如果用例涉及每天創建大量新文件，則可能會發現註冊表文件變得太大？
官方推薦使用配置：
爲了減小註冊表文件的大小，有兩個可用的配置選項：clean_removed和clean_inactive
對於您不再碰觸而被忽略的舊文件（請參閱參考資料ignore_older），我們建議您使用clean_inactive。如果從磁盤中刪除了舊文件，請使用該clean_removed選項。
close_*
配置選項用於之後的某一標準或時間以關閉harvester。
關閉收割機意味着關閉文件處理程序。如果在關閉harvester之後更新文件，則文件將在scan_frequency經過後再次被拾取。但是，如果在harvester關閉時移動或刪除文件，Filebeat將無法再次拾取該文件，並且收割機尚未讀取的任何數據都將丟失。
close_*當Filebeat嘗試從文件讀取時，這些設置將同步應用，這意味着如果Filebeat由於輸出阻塞，完整隊列或其他問題而處於阻塞狀態，則本應關閉的文件保持打開狀態，直到Filebeat再次嘗試讀取從文件中。(注:如果出現輸出阻塞問題，或者是其他問題導致處於阻塞狀態，則文件保持打開狀態，直到再次嘗試讀取文件內容。)
clean_inactive
啓用此選項後，如果在指定時間內未收穫文件，則Filebeat將關閉文件句柄。當收穫機讀取了最後一條日誌行時，定義週期的計數器開始計數。它不是基於文件的修改時間。如果關閉的文件再次更改，則將啓動新的harvester，並且在scan_frequency經過之後將獲取最新的更改 。
我們建議您將其設置close_inactive爲大於最不頻繁更新日誌文件的值。例如，如果您的日誌文件每隔幾秒鐘更新一次，則可以安全地設置close_inactive爲1m。如果存在更新率差異很大的日誌文件，則可以使用具有不同值的多種配置。
設置close_inactive較低的值意味着文件句柄將盡快關閉。但是，這樣做的副作用是，如果關閉harvester，則不會實時發送新的日誌行。
關閉文件的時間戳與文件的修改時間無關。而是，Filebeat使用內部時間戳記來反映上次收穫文件的時間。例如，如果close_inactive設置爲5分鐘，則在收割機讀取文件的最後一行之後，開始5分鐘的倒計時。
您可以使用2h（2小時）和5m（5分鐘）之類的時間字符串。默認值爲5m。
close_renamed
僅當您瞭解數據丟失是潛在的副作用時，才使用此選項。
啓用此選項後，Filebeat在重命名文件時關閉文件處理程序。例如，在旋轉文件時會發生這種情況。默認情況下，harvester保持打開狀態並繼續讀取文件，因爲文件處理程序不依賴於文件名。如果close_renamed啓用了該選項，並且文件的重命名或移動方式與爲其指定的文件模式不再匹配，則不會再次提取該文件。Filebeat將無法完成文件讀取。
WINDOWS：如果Windows日誌循環系統由於無法旋轉文件而顯示錯誤，則應啓用此選項。
close_removed
啓用此選項後，Filebeat將在刪除文件時關閉harvester。通常，僅當文件在所指定的時間內處於非活動狀態後才應將其刪除close_inactive。但是，如果文件過早刪除而您未啓用close_removed，則Filebeat會將文件保持打開狀態以確保harvester已經完成。如果此設置導致文件由於過早從磁盤中刪除而無法完全讀取，請禁用此選項。
默認情況下啓用此選項。如果禁用此選項，則還必須禁用clean_removed。
WINDOWS：如果Windows日誌循環系統由於無法旋轉文件而顯示錯誤，請確保啓用此選項。
close_eof
僅當您瞭解數據丟失是潛在的副作用時，才使用此選項。
啓用此選項後，一旦到達文件末尾，Filebeat就會關閉文件。當您的文件僅寫入一次且不時更新時，此功能很有用。例如，當您將每個日誌事件寫入新文件時，就會發生這種情況。默認情況下禁用此選項
close_timeout
僅當您瞭解數據丟失是潛在的副作用時，才使用此選項。另一個副作用是，多行事件可能不會在超時到期之前完全發送出去.
啓用此選項後，Filebeat會爲每個收割機提供預定義的生存期。無論閱讀器在文件中的何處，經過close_timeout一段時間後，閱讀都會停止。當您只想在文件上花費預定義的時間時，此選項對於較舊的日誌文件很有用。雖然close_timeout將在預定義的超時後關閉文件，但是如果文件仍在更新中，則Filebeat將根據定義的再次啓動新的收割機scan_frequency。並且此收割機的close_timeout將以超時倒數再次開始。
如果輸出被阻止，此選項特別有用，這使Filebeat甚至對於從磁盤上刪除的文件，也保持打開的文件處理程序。進行設置close_timeout以5m確保定期關閉文件，以便操作系統可以釋放它們。
如果設置close_timeout爲equal ignore_older，則在關閉收割機的情況下修改文件時將不會拾取該文件。設置的這種組合通常會導致數據丟失，並且不會發送完整的文件。
當您使用close_timeout包含多行事件的日誌時，收割機可能會在多行事件的中間停止，這意味着將僅發送部分事件。如果收割機再次啓動並且文件仍然存在，則僅發送事件的第二部分。
默認情況下，此選項設置爲0，表示已禁用
clean_*
選項用於清除註冊表文件中的狀態條目。這些設置有助於減小註冊表文件的大小，並可以防止潛在的inode重用問題。
clean_inactive
僅當您瞭解數據丟失是潛在的副作用時，才使用此選項。
啓用此選項後，經過指定的非活動時間後，Filebeat會刪除文件的狀態。僅當Filebeat已忽略該文件（文件早於ignore_older）時，才能刪除狀態 。該clean_inactive設置必須大於ignore_older + scan_frequency要確保在仍在收集文件的同時不刪除任何狀態。否則，該設置可能導致Filebeat不斷重新發送全部內容，因爲 clean_inactive刪除了Filebeat仍檢測到的文件的狀態。如果文件已更新或再次出現，則會從頭開始讀取文件。
該clean_inactive配置選項是有用的，以減少註冊表文件的大小，特別是如果每天都在產生大量的新文件。
此配置選項對於防止因Linux上的inode重用而導致的Filebeat問題也很有用。有關更多信息，請參見Inode重用導致Filebeat跳過行。
每次重命名文件時，文件狀態都會更新，計數器的計數器將clean_inactive再次從0開始。
在測試期間，您可能會注意到註冊表包含應根據clean_inactive設置刪除的狀態條目。發生這種情況是因爲Filebeat直到再次打開註冊表以讀取其他文件時才刪除條目。如果要測試clean_inactive設置，請確保Filebeat配置爲從多個文件中讀取，否則文件狀態永遠不會從註冊表中刪除。
clean_removed
啓用此選項後，如果在磁盤上找不到以最後一個已知名稱命名的文件，則Filebeat將從註冊表中清除文件。這意味着在收割機完成後重命名的文件也將被刪除。默認情況下啓用此選項。
如果共享驅動器在短時間內消失並再次出現，則將從頭開始再次讀取所有文件，因爲狀態已從註冊表文件中刪除。在這種情況下，建議您禁用該clean_removed 選項。
如果還禁用，則必須禁用此選項close_removed
scan_frequency
Filebeat多久檢查一次指定用於收集的路徑中的新文件。例如，如果您指定一個glob如/var/log/*，則使用所指定的頻率掃描目錄中的文件 scan_frequency。指定1可以儘可能頻繁地掃描目錄，而不會導致Filebeat頻繁掃描。我們不建議設置此值<1s。
如果您需要近乎實時地發送日誌行，請不要設置太低， scan_frequency而要進行調整，close_inactive以使文件處理程序保持打開狀態並不斷輪詢文件。
默認設置爲10秒。
scan.sort
此功能是試驗性的，在將來的版本中可能會完全更改或刪除。Elastic會盡力解決所有問題，但是實驗性功能不受官方GA功能的支持SLA約束。
如果您爲此設置指定了空字符串以外的其他值，則可以使用確定使用升序還是降序scan.order。可能的值爲modtime和filename。要按文件修改時間排序，請使用modtime，否則請使用filename。將此選項留空可將其禁用。
如果爲此設置指定一個值，則可以scan.order用來配置文件是按升序還是降序掃描。
默認設置爲禁用。
scan.order
此功能是試驗性的，在將來的版本中可能會完全更改或刪除。Elastic會盡力解決所有問題，但是實驗性功能不受官方GA功能的支持SLA約束。
scan.sort設置爲無時，指定使用升序還是降序。可能的值爲asc或desc。
默認設置爲asc。
tail_files
如果此選項設置爲true，Filebeat將在每個文件的末尾而不是開頭開始讀取新文件。如果將此選項與日誌輪換結合使用，則可能會跳過新文件中的第一個日誌條目。默認設置爲false。
此選項適用於Filebeat尚未處理的文件。如果您以前運行過Filebeat，並且文件的狀態已經保留，tail_files則將不適用。收穫將在先前的偏移量處繼續進行。若要應用於tail_files所有文件，必須停止Filebeat並刪除註冊表文件。請注意，這樣做會刪除所有以前的狀態。
首次在一組日誌文件上運行Filebeat時，可以使用此設置來避免索引舊的日誌行。首次運行後，建議禁用此選項，否則您可能會在文件輪換期間丟失行。
symlinks
該symlinks選項允許Filebeat除常規文件外還收穫符號鏈接。收集符號鏈接時，即使文件報告了符號鏈接的路徑，Filebeat也會打開並讀取原始文件。
配置用於收穫的符號鏈接時，請確保原始路徑已排除。如果將單個輸入配置爲同時收集符號鏈接和原始文件，則Filebeat將檢測到該問題，並且僅處理找到的第一個文件。但是，如果配置了兩個不同的輸入（一個用於讀取符號鏈接，另一個用於讀取原始路徑），則將同時獲取兩個路徑，從而導致Filebeat發送重複的數據，並且輸入覆蓋彼此的狀態。
symlinks如果指向日誌文件的符號鏈接在文件名中包含其他元數據，並且您要在Logstash中處理元數據，則該選項很有用。例如，Kubernetes日誌文件就是這種情況。
由於此選項可能會導致數據丟失，因此默認情況下它被禁用。
backoff
退避選項指定Filebeat如何主動搜索打開的文件以進行更新。在大多數情況下，您可以使用默認值。
該backoff選項定義到達EOF後Filebeat在再次檢查文件之前等待的時間。默認值爲1s，這意味着如果添加了新行，則每秒檢查一次文件。這可以實現近實時爬網。每當文件中出現新行時，該backoff值都會重置爲初始值。默認值爲1s。
max_backoff
達到EOF後Filebeat等待再次檢查文件的最長時間。從檢查文件中退回多次之後，max_backoff無論爲指定了什麼 ，等待時間都不會超過backoff_factor。因爲讀取新行最多需要10s，所以將10s指定爲max_backoff表示在最壞的情況下，如果Filebeat多次退出，則可能會將新行添加到日誌文件中。默認值爲10秒。
要求：設置max_backoff爲大於backoff或等於scan_frequency（backoff <= max_backoff <= scan_frequency）。如果max_backoff需要更高，建議改爲關閉文件處理程序，然後讓Filebeat再次提取文件。
backoff_factor
此選項指定增加等待時間的速度。退避係數越大，max_backoff達到該值的速度就越快。退避因子呈指數增加。允許的最小值是1。如果將此值設置爲1，則會禁用退避算法，並且該backoff值將用於等待新行。backoff每次將數值乘以backoff_factor直到max_backoff。預設值爲2。
harvester_limit
該harvester_limit選項限制了針對一個輸入並行啓動的harvester的數量。這直接與打開的文件處理程序的最大數量有關。默認harvester_limit值爲0，表示沒有限制。如果要收集的文件數超過操作系統的打開文件處理程序限制，則此配置很有用。
限制收割機的數量意味着可能不會並行打開所有文件。因此，我們建議您將此選項與選項結合使用，close_*以確保更頻繁地停止收割機，以便可以拾取新文件。
當前，如果可以再次啓動新的收割機，則隨機選擇收割機。這意味着可能會啓動剛剛關閉然後再次更新的文件的收集器，而不是較長時間未收集的文件的收集器。
此配置選項適用於每個輸入。您可以使用此選項通過分配更高的收割機限制來間接爲某些輸入設置更高的優先級。
tags
Filebeat包含在tags每個已發佈事件的字段中的標籤列表。使用標記，可以輕鬆地在Kibana中選擇特定事件或在Logstash中應用條件過濾。這些標籤將被添加到常規配置中指定的標籤列表中。
filebeat.inputs:
- type: log
. . .
tags: ["json"]
fields
您可以指定可選字段以將其他信息添加到輸出中。例如，您可以添加可用於過濾日誌數據的字段。字段可以是標量值，數組，字典或它們的任何嵌套組合。默認情況下，您在此處指定的字段將被分組fields到輸出文檔中的子詞典下。要將自定義字段存儲爲頂級字段，請將fields_under_root選項設置爲true。如果在常規配置中聲明瞭重複字段，則其值將被此處聲明的值覆蓋。
filebeat.inputs:
- type: log
. . .
fields:
app_id: query_engine_12
fields_under_root
如果將此選項設置爲true，則自定義 字段將作爲頂級字段存儲在輸出文檔中，而不是分組在fields子詞典下。如果自定義字段名稱與Filebeat添加的其他字段名稱衝突，則自定義字段將覆蓋其他字段
processors
應用於輸入數據的處理器列表。
請參閱過濾和增強導出的數據，以獲取有關在配置中指定處理器的信息。
pipeline
要爲此輸入生成的事件設置的接收節點管道ID。
也可以在Elasticsearch輸出中配置管道ID，但是此選項通常會導致配置文件更簡單。如果在輸入和輸出中都配置了管道，則使用輸入中的選項。
filebeat.yml配置：
file beat 輸出到elasticsearch集羣：
setup.template.settings:
index.number_of_shards: 3 #指定索引的分片
output.elasticsearch: #輸出到elasticsearch集羣，沒用集羣就寫本機或者一個就行了
hosts: ["127.0.0.1:9300","127.0.0.1:9301","127.0.0.1:9302"]
##輸出到console
#output.console:
# pretty: true
# enable: true
filebeat斷電異常關閉，會自動修改yml文件的 enabled: true屬性爲false，請注意查看
filebeat.yml詳細配置：
###################### Filebeat Configuration Example #########################
# This file is an example configuration file highlighting only the most common
# options. The filebeat.reference.yml file from the same directory contains all the
# supported options with more comments. You can use it as a reference.
#
# You can find the full configuration reference here:
# https://www.elastic.co/guide/en/beats/filebeat/index.html
# For more available modules and options, please see the filebeat.reference.yml sample
# configuration file.
#=========================== Filebeat inputs =============================
filebeat.inputs:
# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.
- type: log
# Change to true to enable this input configuration.
enabled: true
encoding: utf-8
include_lines: ['ERROR','WARN','INFO']
#輸入在指定路徑中檢查新文件的頻率
scan_frequency: "5s"
#如果tail_files設置爲true, Filebeat從文件尾開始監控文件新增內容把新增的每一行文件作爲一個事件依次發送而不是從文件開始處重新發送所有內容。但最後一條是不會讀取的
tail_files: false
# 每 1 秒檢測一次文件是否有新的一行內容需要讀取
backoff: "1s"
#定義每個收割機在獲取文件時使用的緩衝區大小
harvester_buffer_size: 16384 #40960000
# Paths that should be crawled and fetched. Glob based paths.
paths:
#- /var/log/*.log
#- c:\programdata\elasticsearch\logs\*
- E:\IDEA_project\logdemo\logs\*.log
# Exclude lines. A list of regular expressions to match. It drops the lines that are
# matching any regular expression from the list.
#exclude_lines: ['^DBG']
# Include lines. A list of regular expressions to match. It exports the lines that are
# matching any regular expression from the list.
#include_lines: ['^ERR', '^WARN']
# Exclude files. A list of regular expressions to match. Filebeat drops the files that
# are matching any regular expression from the list. By default, no files are dropped.
#exclude_files: ['.gz$']
# Optional additional fields. These fields can be freely picked
# to add additional information to the crawled log files for filtering
#fields:
# level: debug
# review: 1
### Multiline options
# Multiline can be used for log messages spanning multiple lines. This is common
# for Java Stack Traces or C-Line Continuation
# The regexp Pattern that has to be matched. The example pattern matches all lines starting with [
#multiline.pattern: ^\[
# Defines if the pattern set under pattern should be negated or not. Default is false.
#multiline.negate: false
# Match can be set to "after" or "before". It is used to define if lines should be append to a pattern
# that was (not) matched before or after or as long as a pattern is not matched based on negate.
# Note: After is the equivalent to previous and before is the equivalent to to next in Logstash
#multiline.match: after
#============================= Filebeat modules ===============================
filebeat.config.modules:
# Glob pattern for configuration loading
path: ${path.config}/modules.d/*.yml
# Set to true to enable config reloading
reload.enabled: false
# Period on which files under path should be checked for changes
#reload.period: 10s
#==================== Elasticsearch template setting ==========================
setup.template.settings:
index.number_of_shards: 5
#index.codec: best_compression
#_source.enabled: false
#================================ General =====================================
# The name of the shipper that publishes the network data. It can be used to group
# all the transactions sent by a single shipper in the web interface.
#name:
# The tags of the shipper are included in their own field with each
# transaction published.
#tags: ["service-X", "web-tier"]
# Optional fields that you can specify to add additional information to the
# output.
#fields:
# env: staging
#============================== Dashboards =====================================
# These settings control loading the sample dashboards to the Kibana index. Loading
# the dashboards is disabled by default and can be enabled either by setting the
# options here or by using the `setup` command.
#setup.dashboards.enabled: false
# The URL from where to download the dashboards archive. By default this URL
# has a value which is computed based on the Beat name and version. For released
# versions, this URL points to the dashboard archive on the artifacts.elastic.co
# website.
#setup.dashboards.url:
#============================== Kibana =====================================
# Starting with Beats version 6.0.0, the dashboards are loaded via the Kibana API.
# This requires a Kibana endpoint configuration.
setup.kibana:
# Kibana Host
# Scheme and port can be left out and will be set to the default (http and 5601)
# In case you specify and additional path, the scheme is required: http://localhost:5601/path
# IPv6 addresses should always be defined as: https://[2001:db8::1]:5601
#host: "localhost:5601"
#kibana 地址
host: "localhost:5601"
# Kibana Space ID
# ID of the Kibana Space into which the dashboards should be loaded. By default,
# the Default Space will be used.
#space.id:
#============================= Elastic Cloud ==================================
# These settings simplify using Filebeat with the Elastic Cloud (https://cloud.elastic.co/).
# The cloud.id setting overwrites the `output.elasticsearch.hosts` and
# `setup.kibana.host` options.
# You can find the `cloud.id` in the Elastic Cloud web UI.
#cloud.id:
# The cloud.auth setting overwrites the `output.elasticsearch.username` and
# `output.elasticsearch.password` settings. The format is `<user>:<pass>`.
#cloud.auth:
#================================ Outputs =====================================
# Configure what output to use when sending the data collected by the beat.
#-------------------------- Elasticsearch output ------------------------------
output.elasticsearch:
# Array of hosts to connect to.
hosts: ["localhost:9200"]
#單個ElasticSearch批量API索引請求中要批量處理的最大事件數 默認50
bulk_max_size: 18000
# Optional protocol and basic auth credentials.
#protocol: "https"
#username: "elastic"
#password: "changeme"
#----------------------------- Logstash output --------------------------------
#output.logstash:
# The Logstash hosts
#hosts: ["localhost:5044"]
# Optional SSL. By default is off.
# List of root certificates for HTTPS server verifications
#ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]
# Certificate for SSL client authentication
#ssl.certificate: "/etc/pki/client/cert.pem"
# Client Certificate Key
#ssl.key: "/etc/pki/client/cert.key"
#================================ Processors =====================================
# Configure processors to enhance or manipulate events generated by the beat.
processors:
- drop_fields:
fields: ["log","input","host","agent","@metadata","ecs"]
- add_host_metadata: ~
- add_cloud_metadata: ~
#================================ Logging =====================================
# Sets log level. The default log level is info.
# Available log levels are: error, warning, info, debug
#logging.level: debug
# At debug level, you can selectively enable logging only for some components.
# To enable all selectors use ["*"]. Examples of other selectors are "beat",
# "publish", "service".
#logging.selectors: ["*"]
#============================== Xpack Monitoring ===============================
# filebeat can export internal metrics to a central Elasticsearch monitoring
# cluster. This requires xpack monitoring to be enabled in Elasticsearch. The
# reporting is disabled by default.
# Set to true to enable the monitoring reporter.
#monitoring.enabled: false
# Sets the UUID of the Elasticsearch cluster under which monitoring data for this
# Filebeat instance will appear in the Stack Monitoring UI. If output.elasticsearch
# is enabled, the UUID is derived from the Elasticsearch cluster referenced by output.elasticsearch.
#monitoring.cluster_uuid:
# Uncomment to send the metrics to Elasticsearch. Most settings from the
# Elasticsearch output are accepted here as well.
# Note that the settings should point to your Elasticsearch *monitoring* cluster.
# Any setting that is not set is automatically inherited from the Elasticsearch
# output configuration, so if you have the Elasticsearch output configured such
# that it is pointing to your Elasticsearch monitoring cluster, you can simply
# uncomment the following line.
#monitoring.elasticsearch:
#================================= Migration ==================================
# This allows to enable 6.7 migration aliases
#migration.6_to_7.enabled: true
更多細節配置，請查閱官方文檔：elastic.co/guide/en/beats/filebeat/current/filebeat-installation.html
出現問題：filebeat 輸出到集羣，加載不了默認索引模板，暫時未知，
Elasticsearch
elasticSearch中文文檔：https://es.xiaoleilu.com/
官方文檔：https://www.elastic.co/guide/en/elasticsearch/reference/6.0/getting-started.html
安裝參考博客：https://blog.csdn.net/dulei17816/article/details/92624185
乾貨：https://www.cnblogs.com/xing901022/p/4967796.html
查詢參考：
https://segmentfault.com/a/1190000019446507
https://www.cnblogs.com/leeSmall/p/9215909.html
Elasticsearch是一個基於Apache Lucene(TM)的開源搜索引擎，
Lucene只是一個庫，必須使用Java來作爲開發語言並將其直接集成到你的應用中，
Lucene非常複雜，需要深入瞭解檢索的相關知識來理解它是如何工作的
Elasticsearch也使用Java開發並使用Lucene作爲其核心來實現所有索引和搜索的功能，但是它的目的是通過簡單的RESTful API來隱藏Lucene的複雜性，從而讓全文搜索變得簡單。
Elasticsearch不僅僅是Lucene和全文搜索；
-
分佈式的實時文件存儲，每個字段都被索引並可被搜索
-
分佈式的實時分析搜索引擎
-
可以擴展到上百臺服務器，處理PB級結構化或非結構化數據
所有的這些功能被集成到一個服務裏面，你的應用可以通過簡單的RESTful API、各種語言的客戶端甚至命令行與之交互。
開箱即用（安裝即可使用）。
運行cmd進入命令界面 : 進入安裝目錄
運行以下命令：
前端啓動：
cd D:\elasticsearch-7.3.2\bin
D:\elasticsearch-7.3.2\bin>.\elasticsearch.bat
後端啓動：
cd D:\elasticsearch-7.3.2\bin
D:\elasticsearch-7.3.2\bin>.\elasticsearch.bat -d
後端啓動是沒有信息的。
啓動完成後，打開瀏覽器訪問http://localhost:9200/
出現以下畫面則啓動成功
安裝elastic search-head:
最簡單的安裝方式：charmed 插件；
在谷歌商店可以直接搜索elastic search-head進行安裝，安裝完成即可使用。
要有翻牆工具：安裝谷歌助手之類的工具可以翻牆
REST API:
postman 工具進行發送請求：
例如創建索引：注意發送格式爲application/json
test爲索引名稱
請求類型爲：PUT
##創建索引
插入數據：
進入要插入數據的索引下：http://localhost:9200/test/log/
test爲索引名稱
log 爲數據類型
請求類型爲：POST
進入elastic search-head進行數據查看：
添加成功!
我們可以指定數據唯一標識_Id 指定之後就不會是隨機字符串了，例如： http://localhost:9200/test/log/1001
示例是沒有指定的，默認隨機生成
update:
在elastic search中數據是不能修改的，只能通過全面覆蓋的方式進行修改。
但是我們要的是局部數據更新：
這個內部就要操作四步：
1、檢索出舊文檔的json數據
2、修改數據
3、刪除舊文檔數據
4、索引新文檔
示例：
發送方式：POST
http://localhost:9200/test/log/fReHa20B9aDxYvXTaFY1/_update
注意:是 _update
不能直接傳遞參數，需要使用doc進行包裝，否在會發生400數據傳輸錯誤
{
"doc":{
"level":"error"
}
}
每次的操作 對應數據的 版本也會增加
刪除一條不存在的數據，會出現404，響應解結果也會提示 not found
刪除一條數據並不會馬上從磁盤上刪除，而是被標記成刪除狀態，因爲內部是批量刪除，也就是說會等更多的刪除操作，或者時間預定時間，
查詢數據：
查詢指定數據根據Id查詢
發送方式：GET
http://localhost:9200/test/log/fReHa20B9aDxYvXTaFY1
查詢全部數據：注意 是 _search
http://localhost:9200/test/log/_search
關鍵字搜索：
http://localhost:9200/test/log/_search?q=age:20之類的
DSL搜索：
DSL查詢(Query DSL(Domain Specific Language 特定領域語言)),允許構建更加複雜、強大的查詢， 以json形式的請求體出現。
發送方式：POST
http://localhost:9200/test/log/_search
帶參，json格式：
{
"query":{
"bool":{
#過濾
"filter":{
"range":{#範圍
"sort":{
# gt 大於
"gt"：時間戳
}
}
},
# 必須匹配的
"must":{
"match":{ #match只是查詢的一種
"level":"error"
}
}
}
}
}
高亮顯示：只需要在query後面添加即可
{
"query":{
"bool":{
"must":{
"match":{
"level":"info"
}
}
}
},
"highlight":{
"fields":{
"level":{
}
}
}
}
聚合查詢：
{
"aggs":{
"all_interests": {
"terms": {
"field":"level"
}
}
}
}
出現錯誤：
Fielddata is disabled on text fields by default. Set fielddata=true on [level] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory. Alternatively use a keyword field instead."
對排序和聚合等操作，用單獨的數據結構(fielddata)緩存到內存裏了，默認是不開啓的，需要單獨開啓。
Fielddata可以消耗大量的堆空間，特別是在加載高基數text字段時。一旦fielddata被加載到堆中，它將在該段的生命週期中保持在那裏。此外，加載fielddata是一個昂貴的過程，可以導致用戶體驗延遲命中。這就是爲什麼fielddata默認是禁用的
推薦：使用my_field.keyword字段進行聚合，排序
刪除索引：
只需要進入到要刪除的索引： http://localhost:9200/test/
發送類型爲：DELETE
批量操作：
批量查詢:
發送請求：POST
URL:http://localhost:9200/filebeat-7.3.2-2019.09.25-000001/_doc/_mget
注意：是 _mget _doc 都帶有下劃線
{
"ids":["R6BnZ20Bxr3L20nFhohK","SaBnZ20Bxr3L20nFhohK"]
}
_bulk操作：
Elasticsearch 中支持 批量插入，修改、刪除等操作都是通過 _bulk得api操作得
請求方式：PUT
請求格式如下：
注意後面 \n
{action :{metadata}}\n
{request body}\n
{action :{metadata}}\n
{request body}\n
批量插入數據示例：
{"create":{"_index":"test","_type":"log"}}
{"type":"log","message":"你個渣渣","level":"info","date":"2019-9-27"}
最後一行要有空行
批量刪除：
{"delete":{"_index":"test","_type":"log","_id":"fhdhbG0B9aDxYvXThFYe"}}
{"delete":{"_index":"test","_type":"log","_id":"gBdrbG0B9aDxYvXTJFb"}}
{"delete":{"_index":"test","_type":"log","_id":"fReHa20B9aDxYvXTaFY1"}}
同樣最後回車留一行空白行
創建明確類型得索引：
發送方式：PUT
url: http://localhost:9200/test/
"analyzer":"ik_max_word" 中文分詞
{
"settings":{
"index":{
"number_of_shards":"2"，
"number_of_replicas":"0"
}
},
"mappings":{
"properties":{
"name":{
"type":"text"
},
"age":{
"type":"integer"
},
"mail":{
"type":"keyword"
},
"hobby":{
"type":"text",
"analyzer":"ik_max_word"
},
"date":{
"type":"text"
}
}
}
}
查看映射：
發送GET請求，
url:http://localhost:9200/test/_mapping
注意：是 _mapping
插入數據：
_bulk操作
{"index":{"_index":"test","_type":"person"}}
{"name":"王發發","age":"120","mail":"[email protected]","hobby":"打豆豆，唱歌","date":"2019-9-27"}
{"index":{"_index":"test","_type":"person"}}
{"name":"王水水","age":"119","mail":"[email protected]","hobby":"打遊戲，唱歌","date":"2019-9-27"}
結構化查詢：
term主要用於精確匹配一些值，比如說 日期，數字，布爾值，或者not_analyzed的字符串（未經分析的文本數據類型）
示例：
發送POST請求
json格式
{
"query":{
"term":{
"age":"20"
}
}
}
terms查詢：
與term有點類似，但是terms允許指定多個匹配條件，如果某個字段指定了多個值，那麼文檔需要一起去做匹配：
{
"query":{
"terms":{
"age":[20,21,23]
}
}
}
範圍操作符：
gt:: 大於
gte:: 大於等於
lt:: 小於
lte:: 小於等於
示例：
{
"query":{
"range":{
"age":{
"gte": 10,
"lte": 30
}
}
}
}
exists查詢：
exists 查詢可以用於查找文檔中是否包含指定字段或沒有包含某個字段，類似於sql語句中的is_null條件
{
"query":{
"exists": {#必須包含
"field":"age"
}
}
}
match查詢：
一個標準查詢，不管你需要全文吧查詢還是精確查詢，基本上都要使用它。如果你使用match查詢一個全文吧字段，它會再真正查詢之前用分析器先分析match一下查詢字符：
{
"query":{
"match":{
"age": 10
}
}
}
如果用match下指定一個確定值，在遇到數字、日期或者布爾值、或者not_analyzed的字符串時，它將爲你搜索給定的值
bool查詢：
bool查詢可以用來合併多個條件查詢結果的邏輯，
包含以下操作符：
must: 多個查詢條件的完全匹配，相當於and
must_not:多個查詢條件的相反匹配，相當於not
should: 至少有一個查詢條件匹配，相當於or
這些參數可以分別繼承一個查詢條件或者一個查詢條件的數組：
{
"query":{
"bool":{
"must":{
"hobby":"打遊戲"
},
"must_not":{
"match":{
"hobby":"打豆豆"
}
}
}
}
}
過濾查詢：
{
"query":{
"bool":{
"filter":{
"term":{
"age": 20
}
}
}
}
}
查詢和過濾的對比：
一條過濾語句會詢問每個文檔的字段值是否包含特定值
查詢語句會詢問每個文檔的字段值於特定值的匹配程度如何，一條查詢語句會計算每個文檔於查詢語句的相關性，會給出一個相關性評分_score,並且按照相關性對匹配到的文檔進行排序，這種評分方式非常適用於一個沒有完全配置結果的全文搜索。
一個簡單的文檔列表，快速匹配運算並存入內存是十分方便的，每個文檔僅需要1個字節，這些緩存的過濾結果集與後續請求的結合使用是非常高效的。
查詢語句不僅要查找相匹配的文檔，還需要計算每個文檔的相關性，所以一般來說查詢語句比過濾語句更耗時，查詢的結果也不可以緩存。
結論：在做精確匹配搜索時，最好使用過濾語句，過濾語句可以緩存數據。
加入中文分詞，默認不支持中文
參考安裝IKAnalyzer插件：https://blog.csdn.net/wolfcode_cn/article/details/81907220
下載對應的IKAnalyzer版本：https://github.com/medcl/elasticsearch-analysis-ik/releases
編譯了的elasticsearch-analysis-ik-7.3.2.zip
在elasticsearch安裝目錄下的D:\elasticsearch-7.3.2\plugins裏
將解壓的所有文件放進去，重啓就可以看到加載信息
測試：
發送方式： POST
url: http://localhost:9200/_analyze 格式：application/json
analyzer： 指定分詞器名稱 ik_max_word
{
"analyzer":"ik_max_word",
"text":"我是中國人"
}
結果：
{
"tokens": [
{
"token": "我",
"start_offset": 0,
"end_offset": 1,
"type": "CN_CHAR",
"position": 0
},
{
"token": "是",
"start_offset": 1,
"end_offset": 2,
"type": "CN_CHAR",
"position": 1
},
{
"token": "中國人",
"start_offset": 2,
"end_offset": 5,
"type": "CN_WORD",
"position": 2
},
{
"token": "中國",
"start_offset": 2,
"end_offset": 4,
"type": "CN_WORD",
"position": 3
},
{
"token": "國人",
"start_offset": 3,
"end_offset": 5,
"type": "CN_WORD",
"position": 4
}
]
}
效果符合預期。
全文單詞搜索：
url: http://localhost:9200/test/_doc/_search
發送方式 ：POST
highlight： 高亮
{
"query":{
"match":{
"hobby":"唱歌"
}
},
"highlight":{
"fields":{
"hobby":{
}
}
}
}
過程：
1、檢查字段類型： hobby 字段是一個text類型（指定Ik_max_word分詞器）這意味着查詢字符串本身也應被分詞；比如輸入 “愛打遊戲” 本身也是分成 “愛 ” “打遊戲”之類的
2、分析查詢字符串：將查詢的字符串 “音樂” 傳入分詞器種，輸出的結果是單項 “音樂” 。以爲只有一個單詞項，所以match 查詢執行的是單個底層term查詢
3、查找匹配文檔
用term查詢在倒排序索引中查詢 “音樂” 然後獲取一組包含該項的文檔，
4、爲每個文檔評分
用term查詢計算出每個文檔相關度評分_score ,這是種將 詞頻（term frequency，即詞“音樂” 在相關文檔的hobby字段中出現的頻率。）和反向文檔頻率（inverse document frequency，即在所有文檔 hobby 字段中出現的頻率），以及字段的長度（字段越短相關度越高）相結合的計算方式。
全文多詞搜索：
包含 “遊戲” 和“唱歌”
由於版本問題，後面match不在支持"operator":"and"的方式
改用：”multi_match“
{
"query":{
"multi_match" : {
"query": "唱歌 打遊戲",
"operator":"and"
}
},
"highlight":{
"fields":{
"hobby":{
}
}
}
}
可以調整匹配度： "minimum_should_match":"40%"
組合查詢：
{
"query":{
"bool":{
"must":{
"match":{
"hobby":"唱歌"
}
},
"must_not":{
"match":{
"hobby":"豆豆"
}
},
"should":{
"match":{
"hobby":"遊戲"
}
}
}
}
}
bool查詢會爲每一個文檔計算相關度評分_score，再將所有匹配的must和should語句的分數 _score求和最後除以must和should語句的總數。must_not是不會影響評分，它的作用只是排除不相關的文檔
默認情況下，should中的內容不是必須匹配的，如果查詢語句中沒有must,那麼就至少會匹配其中1個，也可以通過minimum_should_match 參數進行控制，該值可以是百分比也可以是數字。
{
"query":{
"bool":{
"must":{
"match":{
"hobby":"唱歌"
}
},
"must_not":{
"match":{
"hobby":"豆豆"
}
},
"should":[
{
"match":{
"hobby":"遊戲"
}
},
{
"match":{
"hobby":"唱歌"
}
}
],
"minimum_should_match":2
}
}
}
權重：
有些時候，我們可能需要對某些詞增加權重來影響該條數據的得分：
如果包含”遊戲“ 權重設爲爲10， 包含 ”豆豆“ 權重爲2
{
"query": {
"bool": {
"must":{
"match":{
"hobby":"唱歌"
}
},
"must_not":{
"match":{
"hobby":"洗澡"
}
},
"should": [
{
"match": {
"hobby": {
"query": "打遊戲",
"boost": 10
}
}
},
{
"match": {
"hobby": {
"query": "打豆豆",
"boost": 2
}
}
}
]
}
}
}
權重影響得分，也就是數據排在前後的原因。
集羣節點：
在elasticsearch 中 ，節點的類型主要有4種：
1、master節點：
配置文件中的node.master屬性爲true(默認爲true)，就有資格被選爲master節點（注意：不是成爲master節點，是候選）；master節點用於控制整個集羣的操作，比如創建或刪除索引，管理其他非master節點等。
2、data節點：
配置文件中node.data屬性爲true(默認爲true)，就有資格被設置成爲data節點（與master一樣，只是有資格的，候選）；data節點主要用於執行數據相關操作，比如文檔的crud
3、客戶端節點：
配置文件中的node.master屬性和node.data屬性均爲false。該節點不能作爲master節點，也不能作爲data節點。
可以作爲客戶端節點。用於響應用戶的請求，把請求轉發到其他節點。類似代理
4、部落節點：
當一個節點配置tribe.*的時候，它是一個特殊的客戶端，可以連接多個集羣，在所有連接的集羣上執行搜索或其他操作。
配置elasticsearch集羣：
建議：在Contos Linux部署
window 部署：6.5參考 https://www.cnblogs.com/ynylub/p/11299763.html
7版本更新：建議http://www.sohu.com/a/301517999_683048
此配置僅供參考，版本不一致，如有錯誤請查看中文文檔或官方
本機搭建elastic search集羣：
修改每個elasticsearch.yml文件
集羣配置es-log-cluster：node1
#爲羣集使用描述性名稱：
cluster.name: es-log-cluster
#爲節點使用描述性名稱：
node.name: node01
#有資格被選爲master節點
node.master: true
#有資格被選爲data節點
node.data: true
#將綁定地址設置爲特定IP（IPv4或IPv6）：
network.host: 0.0.0.0
# 設置節點間交互的tcp端口,默認是9300｡
transport.tcp.port: 9300
爲http設置自定義端口：
http.port: 9200
#在啓動此節點時，傳遞要執行發現的主機的初始列表：
#默認主機列表爲[“127.0.0.1”，“[：：1]”]
#注：這是發現廣播集羣的地址
discovery.seed_hosts: ["host1", "host2"，"host3"]
#使用初始的一組符合主節點條件的節點引導集羣
#cluster.initial_master_nodes: ["node-1", "node-2"]
#對半設置防止腦裂 nodes/2+1 6.5版本 已刪除
#discovery.zen.minimum_master_nodes:2
#在羣集完全重新啓動後阻止初始恢復，直到啓動n個節點 7.3.2版本
cluster.initial_master_nodes: ["node-1"]
#跨域設置
http.cors.enabled: true
http.cors.allow-origin: "*"
集羣配置es-log-cluster：node2
#爲羣集使用描述性名稱：
cluster.name: es-log-cluster
#爲節點使用描述性名稱：
node.name: node02
#有資格被選爲master節點
node.master: true
#有資格被選爲data節點
node.data: true
#將綁定地址設置爲特定IP（IPv4或IPv6）：
network.host: 0.0.0.0
爲http設置自定義端口：
http.port: 9200
#在啓動此節點時，傳遞要執行發現的主機的初始列表：
#默認主機列表爲[“127.0.0.1”，“[：：1]”]
#注：這是發現廣播集羣的地址
discovery.seed_hosts: ["host1", "host2"，"host3"]
#使用初始的一組符合主節點條件的節點引導集羣
cluster.initial_master_nodes: ["node-1"]
#對半設置防止腦裂 nodes/2+1 6.5版本
#discovery.zen.minimum_master_nodes:2
#在羣集完全重新啓動後阻止初始恢復，直到啓動n個節點 7.3.2版本
#gateway.recover_after_nodes: 3
#跨域設置
http.cors.enabled: true
http.cors.allow-origin: "*"
集羣配置es-log-cluster：node3
#爲羣集使用描述性名稱：
cluster.name: es-log-cluster
#爲節點使用描述性名稱：
node.name: node03
#有資格被選爲master節點
node.master: true
#有資格被選爲data節點
node.data: true
#將綁定地址設置爲特定IP（IPv4或IPv6）：
network.host: 0.0.0.0
爲http設置自定義端口：
http.port: 9200
#在啓動此節點時，傳遞要執行發現的主機的初始列表：
#默認主機列表爲[“127.0.0.1”，“[：：1]”]
#注：這是發現廣播集羣的地址
discovery.seed_hosts: ["host1", "host2"，"host3"]
#使用初始的一組符合主節點條件的節點引導集羣
cluster.initial_master_nodes: ["node-1"]
#對半設置防止腦裂 nodes/2+1 6.5版本
#discovery.zen.minimum_master_nodes:2
#在羣集完全重新啓動後阻止初始恢復，直到啓動n個節點 7.3.2版本
#gateway.recover_after_nodes: 3
#跨域設置
http.cors.enabled: true
http.cors.allow-origin: "*"
注意：如果無法加入集羣節點的問題，可能是data文件下已經有node文件，刪除存放存放在data下的所有文件，重啓服務即可。此方法僅供參考。
瀏覽器打開插件elasticsearch -head：
集羣搭建成功！
node-001 爲主節點 master
分片區別：
分片和副片：
爲了將數據添加到Elastic search ，我們需要索引(index) —— 一個存儲關聯數據的地方。實際上，索引只是用來指向一個或多個分片(shards)的邏輯命名空間(logical namespace).
1、一個分片是一個最小級別”工作單元（worker unit）“它只是保存了索引中所有數據的一部分。
2、分片就是一個Lucene實例，並且它本身就是一個完整的搜索引擎，應用程序不會和它直接通信。
3、分片可以是主分片(primary shard)或者是複製分片(replica shard)也叫副片
4、索引中的每個文檔屬於一個單獨的主分片，所以主分片的數量決定了索引最多能存儲多少數據。
5、複製分片也叫副片只是主分片的一個副本，它可以防止硬件故障導致的數據丟失，同時可以提供讀請求、比如搜索或者從別的shard取回文檔。
6、當索引創建完成的時候，主分片的數量就固定了，但是複製分片的數量可以隨時調整。
故障轉移
狀態：
綠色(green)： 當前集羣狀態爲綠色， 表示所有節點和分片都可以正常使用
黃色(yellow)：當前集羣狀態爲黃色,表示主節點可以正常使用， 部分 副本分片不可用
紅色(red)：部分主分片和副片不可用
當一個data節點故障，則會把分片複製給其他節點，直到該節點重新恢復正常，重新加入集羣，健康狀態就會從黃色變爲綠色。
當一個master節點故障，則master節點則會重新在剩下的節點選舉，
健康狀態就會從黃色變爲綠色，當故障節點master恢復到正常，則重新加入集羣，此時故障節點已經不在是master節點，而是有資格的候選master節點的普通節點，
腦裂問題：
腦裂即爲雙主master節點，故障的master節點重新恢復正常，但不會加入之前集羣，成爲一個獨立的集羣。
爲了防止腦裂問題，在配置參數的時候一定要加入
# nodes/2+1
discovery.zen.minimum_master_nodes:2
文檔寫入流程：
1、客戶端給node1(master)發送新建、索引或刪除請求
2、節點使用文檔的_id確定文檔屬於分片0，轉發請求到node3，分片0位於這個節點
3、node3在主分片上執行請求，如果成功，它轉發請求到相應的位於node1和node2的複製節點上。當所有的複製節點返回成功，node3返回報告成功到請求的節點，請求節點在報告給客戶端。
搜索文檔（單個）：
順序步驟：
1、客戶端給node1發送get請求
2、節點使用文檔的_id確定文檔分片屬於0，分片0對應的複製分片在三個幾點上都有，此時它轉發請求到node2。
3、node2返回文檔給node1然後返回給客戶端
對於讀數據的請求，爲了平衡負載，請求節點會爲每個請求選擇不同的分片———循環所有分片副本。
可能出現的情況： 一個被索引的文檔已經存在於主分片上，但是還沒有同步到副片，這時候副片分片會報告文檔不存在，主分片會成功返回文檔，當同步到了所有副片並返回成功，索引請求副片則會成功返回數據給用戶，文檔在主分片和副片也就都可以正常使用的。
深度分頁
1、from+size 實現分頁
優點：實時性好，能進行按頁數進行分頁，指定跳到某頁
缺點：在深度分頁時，會帶來嚴重的性能問題：CPU、內存、IO、網絡帶寬數據量越大，越往後翻頁，性能越低b)
2、scroll 深度分頁
優點：適用於後臺批處理任務，初始化時將所有符合搜索條件的搜索結果緩存起來，可以想象成快照，遍歷時，從這個快照裏取數據，也就是說，因爲初始化的時候就已經固定了數據量，所以在初始化後對索引插入、刪除、更新數據都不會影響遍歷結果。
缺點：不適合用來做實時搜索，每次都要傳參數 scroll，刷新搜索結果的緩存時間。
3、search_after
優點：search_after 提供了一個實時的光標來避免深度分頁的問題，其思想是使用前一頁的結果來幫助檢索下一頁。
缺點：需要使用一個值的字段作爲排序字段，否則不能使用search_after方法，只能處理下一頁，無法往上翻頁，不能自由跳到一個隨機頁面。
使用search_after的前提是要使用一個唯一標識的字段進行排序。
例如：
POST請求：http://localhost:9200/filebeat-7.3.2-2019.10.08-000001/_doc/_search
{
"size": 2,
"query": {
"match": {
"message": "error"
}
},
"sort": [
{
"_id": {
"order": "asc"
}
},
{
"message.keyword": {
"order": "asc",
"unmapped_type":"long"
}
}
]
}
結果如下：
其中message的排序數值好像是不變的，也就是說message.keyword可有可無
但 _id的唯一標識排序是一定要的，就靠這唯一標識排序
查詢全部文件:
使用”match_all“
{
"size": 5,
"query": {
"match_all": {
}
},
"sort": [
{
"_id": {
"order": "asc"
}
}
]
}
同原理拿到最後一個sort的數值
進行分頁查詢
{
"size": 5,
"query": {
"match_all": {
}
},
"search_after": [
"-Cupqm0Be7MT9ybOc6KM"
],
"sort": [
{
"_id": {
"order": "asc"
}
}
]
}
kibana可視化
Kibana是一個開源分析和可視化平臺，旨在與Elasticsearch協同工作。
下載官方最新的版本，與elasticSearch的版本一致 避免導致一些不必要的問題。
解壓完成後，確保elasticSearch成功啓動。
在Kibana安裝目錄的config目錄下找到Kibana.yml 修改
# The URLs of the Elasticsearch instances to use for all your queries.
elasticsearch.hosts: ["http://localhost:9200"]
修改完成後重新啓動Kibana.bat
cd D:\kibana-7.3.2-windows-x86_64\bin
D:\kibana-7.3.2-windows-x86_64\bin>.\Kibana.bat
啓動等待幾秒鐘，出現以下畫面，啓動成功！
如果出現 Error: No Living connections 意思是： error ：沒有活動連接，
訪問http://localhost:5601 則會出現：Kibana server is not ready yet
請檢查elasticSearch是否成功啓動；
請檢查是否配置kibana.yml
elasticsearch.hosts: ["http://localhost:9200"]
請檢查版本與elasticSearch的版本是否一致；
創建索引：
進入左側工具欄的Management
index Management 可查看索引和生命策略
index Patterns 搜索並創建別名
創建過程中可添加過濾
成功後點擊左側工具欄DIscover 進行數據查詢
生成可視化圖表：
如果已經有了可視化圖，則會出現如下圖，也可以重新創建
已生成的可視化：
設置好可視化可以點擊save進行保存。如果沒保存，下次進入就沒了需要重新創建。
儀表盤：
作用：將多套可視化的結果進行整合至單一頁面內,而後提供搜索查詢或者點擊可視結果內的某元素指定過濾條件，從而實現結果過濾,錶板能夠幫助我們更全面地瞭解總體日誌內容，並將各可視結果同日志關聯起來。
創建儀表盤，可以直接將可視化的模板添加到儀表盤進行保存。
儀表盤看到的數據和可視化的數據是一樣的。
開啓安全驗證：
進入安裝目錄下D:\elasticsearch-7.3.2\bin
執行：elasticsearch-setup-passwords interactive
#開始爲保留用戶Elastic、APM_系統、Kibana、Logstash_系統、Beats_系統、遠程監控_用戶設置密碼。
#當進程進行時，系統將提示您輸入密碼。
#請確認是否要繼續[Y/N]
Initiating the setup of passwords for reserved users elastic,apm_system,kibana,logstash_system,beats_system,remote_monitoring_user.
You will be prompted to enter passwords as the process progresses.
Please confirm that you would like to continue [y/N]
#輸入[彈性]的密碼：
Enter password for [elastic]:
#重新輸入[彈性]的密碼：
Reenter password for [elastic]:
#輸入[APM U系統]的密碼：
Enter password for [apm_system]:
#重新輸入[APM U系統]的密碼：
Reenter password for [apm_system]:
#輸入[Kibana]的密碼：
Enter password for [kibana]:
#重新輸入[Kibana]的密碼：
Reenter password for [kibana]:
#輸入[日誌存儲系統]的密碼：
Enter password for [logstash_system]:
#重新輸入[logstash_system]的密碼：
Reenter password for [logstash_system]:
#輸入[beats_system]的密碼：
Enter password for [beats_system]:
#重新輸入[beats_system]的密碼：
Reenter password for [beats_system]:
#輸入[遠程監視用戶]的密碼：
Enter password for [remote_monitoring_user]:
#重新輸入[遠程監視用戶]的密碼：
Reenter password for [remote_monitoring_user]:
#更改了用戶[APM U系統]的密碼
Changed password for user [apm_system]
#更改了用戶[Kibana]的密碼
Changed password for user [kibana]
#更改了用戶的密碼[日誌存儲系統]
Changed password for user [logstash_system]
#更改了用戶[Beats_系統]的密碼
Changed password for user [beats_system]
#更改了用戶[遠程監視用戶]的密碼
Changed password for user [remote_monitoring_user]
#更改了用戶的密碼[彈性]
Changed password for user [elastic]
在filebeat.yml配置裏面修改
output.elasticsearch:
# Array of hosts to connect to.
hosts: ["localhost:9200"]
#單個ElasticSearch批量API索引請求中要批量處理的最大事件數 默認50
bulk_max_size: 18000
# Optional protocol and basic auth credentials.
#protocol: "https"
#username: "elastic"
#password: "changeme" #沒修改就是默認密碼changeme
username: "elastic"
password: "123456"
在kibana.yml中修改
#驗證elastic search身份
elasticsearch.username: "elastic"
elasticsearch.password: "123456"
完成之後重啓elasticsearch：
打開瀏覽器Chrome：點擊插件Elastic Search Head
第一次會有彈出框驗證用戶和密碼之後就不會了，除非你重啓elastic search服務。
接着打開kibana也會提示驗證身份
filebeat讀取文件輸出到elastic search有數據就成功了。
簡單的安全就設置完成了。
日記框架：FileBeats+elasticSearch+Kibana
FileBeats：讀取指定目錄的文件
RabbitMQ：轉發FileBeats讀取到的日誌文件的內容
Elasticsearch：存儲RabbitMQ轉發過來的內容
測試說明：由於是本地測試，側重於測試數據性能。所以安全策略未開啓，在配置文件的時候也就少了很多用戶和證書之類的配置。
配置：
在FileBeats安裝目錄下的filebeat.yml 裏， 設置輸出到Elasticsearch
output.elasticsearch:
#Array of hosts to connect to.
hosts: ["localhost:9200"]
在elasticsearch啓動成功的前提下，啓動kibana可視化工具連接elasticsearch
配置config下的kibana.yml
打開註釋
elasticsearch.hosts: ["http://localhost:9200"]
啓動在安裝目錄下找到 bin\kibana.bat 點擊運行即可，
打開瀏覽器，訪問localhost:5601默認訪問地址
一開始進入是沒有數據的， 點擊直接創建數據，不要使用推薦樣本
如果file beat 讀取到文件並輸出到elasticsearch，那麼kibana可視化中
點擊左邊工具欄上的 Management
可以看到你Index Management
點擊 Index Lifecycle Policies 可以看到你的策略及模板
點擊Index patterns 創建你的索引
在創建索引的過程中可以添加你的過濾器
創建完成後，點擊Discover 開始查詢
問題總結：
問題：filebeat輸出到elasticsearch 能讀取到日誌內容，輸出elasticsearch 一直回退，數據傳輸不了？
答: 猜測有可能是elasticsearch鎖住了內存，數據寫不了；建議重啓elasticsearch，還是不行就重啓電腦， 待定！
問題：日誌Info類型的啓動日誌怎麼過濾？比如說info級別的程序啓動消息？
答：filebeat貌似可以使用參數：include_lines: ['ERROR','WARN','INFO']來採集數據，
#問題：filebeat採集idea生產的日誌數據出現重複，默認配置讀取未處理過的文件出現少部分數據丟失的情況。
答：filebeat文件內部出現問題，建議檢查文件，或初始filebeat.yml文件，重新啓動電腦是個不錯的選擇。
如果是Linux系統那麼這個問題的根本原因在於 vim 編輯文件保存的時候會修改文件的 inode，此時 filebeat 會把它做新文件處理，所以又全部讀取了一遍
第一次運行filebeat 讀取已存在的日誌，如果文件沒有更新，則不會出現重複讀取數據。
默認配置tail_files: 設置爲true，防止讀取已經讀取過的數據。但是vim修改的文件無效。
如果是window10系統，則可以在dos命令執行echo 增加文件內容，但是或有一個亂碼的問題。
建議重啓電腦後，檢查文件，然後重新啓動filebat進行測試。
問題：filebeat 可以輸出連接到rabbitmq嗎？
答：官方回覆暫不支持rabbitMQ, 在配置文件filebeat.reference.yml 有關於rabbitmqde 模塊，暫時不知道有什麼用處。
問題：filebeat採集log，每次filebeat程序斷開，重新啓動之後，不會繼續採集log，請問是什麼原因呢？爲什麼filebeat重啓不再讀取文件？
答：1、如果這個文檔五分鐘內沒有更新的話，並且filebeat重啓，這時候就不會再採集這個文件，就認爲這個文件是已經不需要採集的文件，如果想要繼續採集可以刪除registry文件或者更新log文件，這是可能之一
2、在收割機關閉時移動或刪除文件，Filebeat將無法再次拾取該文件，並且harvester尚未讀取的任何數據都將丟失。
問題：爲什麼kibana連接elasticsearch可視化，檢索不到數據？
答：如果文件讀取完成，斷開重新啓動filebeat,如果文件沒有新的改動，比如增加消息，那麼filebeat也會認爲這個文件不需要再採集。如果這時候，你刪除了索引及全部信息，那麼重新啓動的時候elasticsearch不會創建新的索引，因爲filebeat並沒有讀取文件採集信息，所以用kibana連接elasticsearch的時候檢索不到信息。
問題：爲什麼100W的日誌信息只查詢出部分數據？
答：filebeat輸出到elastic search 邊讀邊存；實時更新數據。
如果數據量太大，當然就查詢不到還沒進入elastic search的數據，要等待file beat讀取日誌內容輸出到elasticsearch完成後，才能查詢
問題： 讀取後的字段太多，能刪除一些不重要的字段嗎？ 比如@metadata，log等等,,,
答：filebeat配置中log、input、agent和ecs都可以去掉，@metadata和host不能被去掉
問題：爲什麼filebeat輸出到文件 速度很快，而輸出到elasticsearch卻很慢？
答： filebeat輸出到文件使用的是io流，對於讀寫文件很快，測試filebeat的時候讀取大概117MB的日誌，一共100W行日誌，配置了文件大小
默認爲1024kb，我們修改成1024000000kb, 文件數量2；filebeat可以在30-40s之內讀取寫入完成；但是在輸出到elasticsearch進行查詢時，
用的是默認的配置，會很慢，我們可以修改成批處理最大處理數爲15000左右， 速度會有很大的提升
在filebeat配置文件中drop掉不重要的字段，也是可以提高那麼一丟丟速度。具體參考壓測結果。
elasticsearch查詢效率：https://blog.csdn.net/Aria_Miazzy/article/details/88068145
問題：開啓驗證之後，post請求數據失敗，安全驗證出錯 "type": "security_exception", "reason": "missing authentication credentials for REST request [/filebeat-7.3.2-2019.10.11-000001/doc/search?pretty]"
答：看報錯信息就知道是安全驗證沒通過，開啓驗證之後每次請求都要加帶身份驗證，
命令執行：curl --user elastic:123456 XGET "http://localhost:9200/filebeat-7.3.2-2019.10.11-000001/_doc/_search?pretty"
或者轉換爲http網格請求：
例如postman：
如果是Java代碼模擬請求,加入以下代碼：
String name = "elastic";
String password = "123456";
String authString = name + ":" + password;
System.out.println("auth string: " + authString);
//Base64編碼
byte[] authEncBytes = Base64.encodeBase64(authString.getBytes("utf-8"));
String authStringEnc = new String(authEncBytes);
//Authorization格式，注意“Basic ” 有個空格
conn.setRequestProperty("Authorization", "Basic " + authStringEnc);
一時間沒有想到
特別感謝：簡書繁天涯 轉換成http網格式：https://www.jianshu.com/p/38c43b2c0b4d
壓測性能：
不斷產生新的日誌，進行測試寫入輸出時間 要求：1s 10w左右
測試：100w tomcat日誌消息
filebeat 直接輸出到elasticsearch
默認配置
讀取：11:21:26.827 1568949686
結束：11:53:52.202 1568951632
耗時： 1946s 約等於32分鐘
filebeat.yml 中刪除了字段
- drop_fields:
fields: ["log","input","host","agent","@metadata","ecs"]
其中host、@metadata 是不能被刪除的
耗時： 1889s 約等於31分鐘
結論: 刪除不總要的字段是可以提高寫入速度，每行字段少了，寫入也就快那麼一點
修改輸入輸出配置：
定義每個收割機在獲取文件時使用的緩衝區大小 默認1681
filebeat.inputs:
harvester_buffer_size: 40960000
修改elasticsearch 最大處理數 默認50
outelasticsearch:
bulk_max_size: 15000
測試：100W tomcat日誌消息
bulk_max_size: 15000 耗時： 130s左右
bulk_max_size: 18000 harvester_buffer_size: 40960000 耗時： 120s 左右
結論：修改elastic search的單次批處理的最大處理個數， 可以極大的提升性能，但要根據硬件進行測試，設置優化
本機測試： bulk_max_size: 18000 harvester_buffer_size: 40960000 平均耗時： 125s 左右
第一次啓動創建索引的時候會慢10秒左右。
優化：
修改filebeat.yml 配置
- type: log
# Change to true to enable this input configuration.
enabled: true
encoding: utf-8
#exclude_lines: ['^DBG']
#include_lines: ['^ERR', '^WARN']
#輸入在指定路徑中檢查新文件的頻率
scan_frequency: "5s"
#如果tail_files設置爲true, Filebeat從文件尾開始監控文件新增內容把新增的每一行文件作爲一個事件依次發送而不是從文件開始處重新發送所有內容。
tail_files: false
#定義每個收割機在獲取文件時使用的緩衝區大小
harvester_buffer_size: 40960000
# Paths that should be crawled and fetched. Glob based paths.
paths:
#- /var/log/*.log
#- c:\programdata\elasticsearch\logs\*
#- D:\filebeat\var\log\*
- E:\IDEA_project\logdemo\logs\*.log
setup.template.settings:
#分片 3
index.number_of_shards: 3
測試：100W tomcat日誌消息
filebeat 讀取 寫入文件
文件設置大小：1024000000 kb ##默認配置1024 這裏我們改大一些
文件數量： 2個 ### 默認文件數量 7個 範圍2-1024個
開始讀取時間： 2019-09-20 06:28:12.689Z
結束寫入文件時間： 2019-09-20 06:28:49.417Z
耗時：37s
結論： 設置輸出文件的大小會影響filebeat讀取文件的速度。
elk 存在漏洞，攻破原理，以及如何防護
1、 Elasticsearch Kibana6.4.3之前版本和5.6.13之前版本中的Console插件存在嚴重的本地文件包含漏洞可導致拒絕服務攻擊、任意文件讀取攻擊、配合第三方應用反彈SHELL攻擊，Kibana中存在的一個關鍵LFI漏洞，使得攻擊者能夠在服務器上運行本地代碼，可造成直接的危害就是拒絕服務攻擊 。
具體問題是官方的node.js出現問題，官方已修復
而遠程調用漏洞，按照 elasticsearch 官方處理建議, 將默認的監聽 IP 設定在 127.0.0.1, 關閉動態執行腳本能力: script.disable_dynamic: true ( 均在它的配置文件中完成 )
加固：保證防火牆開啓。
1、提高file beat輸出到elasticsearch的速度:
需求： 關鍵詞預警(日誌出錯，攻擊)
使用第三方插件： ElastAlert 開源，需要搭建python環境。 麻煩
使用elastic官方kibana: Watcher 要錢 惱火
自己寫：
idea java開發: 模擬發送elasticsearch的索引查詢請求， 每10秒一次，
elasticsearch提供2種方式查詢數據：
搜索API
ES提供了兩種搜索的方式：請求參數方式 和 請求體方式。
請求參數方式
curl 'localhost:9200/bank/_search?q=*&pretty'
其中bank是查詢的索引名稱，q後面跟着搜索的條件：q=*表示查詢所有的內容
請求體方式（推薦這種方式）
curl -XPOST 'localhost:9200/bank/_search?pretty' -d '
{
"query": { "match_all": {} }
}'
這種方式會把查詢的內容放入body中，會造成一定的開銷，但是易於理解。在平時的練習中，推薦這種方式。
ElasticSearch性能優化：
一、索引效率優化：索引優化主要是在 Elasticsearch 插入層面優化
方法：
批量提交：
當有大量數據提交的時候，建議採用批量提交。
如果在提交過程中，遇到 EsRejectedExecutionException 異常的話，則說明集羣的索引性能已經達到極限了。這種情況，要麼提高服務器集羣的資源，要麼根據業務規則，減少數據收集速度，比如只收集 Warn、Error 級別以上的日誌
優化硬件：
優化硬件設備一直是最快速有效的手段。
-
在經濟壓力能承受的範圍下， 儘量使用固態硬盤 SSD。SSD 相對於機器硬盤，無論隨機寫還是順序寫，都較大的提升。
-
磁盤備份採用 RAID0。因爲 Elasticsearch 在自身層面通過副本，已經提供了備份的功能，所以不需要利用磁盤的備份功能，同時如果使用磁盤備份功能的話，對寫入速度有較大的影響。
增加 Refresh 時間間隔：
爲了提高索引性能，Elasticsearch 在寫入數據時候，採用延遲寫入的策略，即數據先寫到內存中，當超過默認 1 秒 （index.refresh_interval）會進行一次寫入操作，就是將內存中 segment 數據刷新到操作系統中，此時我們才能將數據搜索出來，所以這就是爲什麼 Elasticsearch 提供的是近實時搜索功能，而不是實時搜索功能。
當然像我們的內部系統對數據延遲要求不高的話，我們可以通過延長 refresh 時間間隔，可以有效的減少 segment 合併壓力，提供索引速度。在做全鏈路跟蹤的過程中，我們就將 index.refresh_interval 設置爲 30s，減少 refresh 次數。
同時，在進行全量索引時，可以將 refresh 次數臨時關閉，即 index.refresh_interval 設置爲 -1，數據導入成功後再打開到正常模式，比如 30s。
減少副本數量：
Elasticsearch 默認副本數量爲 3 個，雖然這樣會提高集羣的可用性，增加搜索的併發數，但是同時也會影響寫入索引的效率。
在索引過程中，需要把更新的文檔發到副本節點上，等副本節點生效後在進行返回結束。使用 Elasticsearch 做業務搜索的時候，建議副本數目還是設置爲 3 個，但是像內部 ELK 日誌系統、分佈式跟蹤系統中，完全可以將副本數目設置爲 1 個。
二、查詢效率優化
路由
當我們查詢文檔的時候，Elasticsearch 如何知道一個文檔應該存放到哪個分片中呢？它其實是通過下面這個公式來計算出來
shard = hash(routing) % number_of_primary_shards
routing 默認值是文檔的 id，也可以採用自定義值，比如用戶 id。
不帶 routing 查詢
在查詢的時候因爲不知道要查詢的數據具體在哪個分片上，所以整個過程分爲 2 個步驟
-
分發：請求到達協調節點後，協調節點將查詢請求分發到每個分片上。
-
聚合: 協調節點蒐集到每個分片上查詢結果，在將查詢的結果進行排序，之後給用戶返回結果。
帶 routing 查詢
查詢的時候，可以直接根據 routing 信息定位到某個分配查詢，不需要查詢所有的分配，經過協調節點排序。
向上面自定義的用戶查詢，如果 routing 設置爲 userid 的話，就可以直接查詢出數據來，效率提升很多。
Filter VS Query
Use filter context instead of query context if possible. 儘可能使用過濾器上下文（Filter）替代查詢上下文（Query
-
Query：此文檔與此查詢子句的匹配程度如何？
-
Filter：此文檔和查詢子句匹配嗎？
Elasticsearch 針對 Filter 查詢只需要回答「是」或者「否」，不需要像 Query 查詢一下計算相關性分數，同時 Filter 結果可以緩存。
不過Query 查詢計算相關性分數，可以設置優先顯示的數據，具體請查看“權重”設置
大翻頁
在使用 Elasticsearch 過程中，應儘量避免大翻頁的出現。
正常翻頁查詢都是從 From 開始 Size 條數據，這樣就需要在每個分片中查詢打分排名在前面的 From + Size 條數據。協同節點收集每個分配的前 From + Size 條數據。協同節點一共會受到 N * （ From + Size ）條數據，然後進行排序，再將其中 From 到 From + Size 條數據返回出去。
如果 From 或者 Size 很大的話，導致參加排序的數量會同步擴大很多，最終會導致 CPU 資源消耗增大。
可以通過使用 Elasticsearch scroll 和 scroll-scan 高效滾動的方式來解決這樣的問題。具體寫法，可以參考
Elasticsearch: 權威指南 - scroll 查詢(https://www.elastic.co/guide/cn/elasticsearch/guide/cn/_fetch_phase.html)
不過scroll 查詢不適合實時查詢，適用於羣發消息，因爲scroll初始化時將所有符合搜索條件的搜索結果緩存起來，也就是已經固定了數量，遍歷時，從這個緩存裏取數據。所以在初始化後對索引插入、刪除、更新數據都不會影響遍歷結果。
我們可以使用 search_after進行替代scroll深度分頁。具體請看search_after深度分頁。
JVM 設置
32G 現象
Elasticsearch 默認安裝後設置的堆內存是 1 GB。 對於任何一個業務部署來說， 這個設置都太小了。
比如機器有 64G 內存，那麼我們是不是設置的越大越好呢？
其實不是的。
主要 Elasticsearch 底層使用 Lucene。Lucene 被設計爲可以利用操作系統底層機制來緩存內存數據結構。 Lucene 的段是分別存儲到單個文件中的。因爲段是不可變的，這些文件也都不會變化，這是對緩存友好的，同時操作系統也會把這些段文件緩存起來，以便更快的訪問。
如果你把所有的內存都分配給 Elasticsearch 的堆內存，那將不會有剩餘的內存交給 Lucene。 這將嚴重地影響全文檢索的性能。
標準的建議是把 50％ 的可用內存作爲 Elasticsearch 的堆內存，保留剩下的 50％。當然它也不會被浪費，Lucene 會很樂意利用起餘下的內存。
同時瞭解過 ES 的同學都聽過過「不要超過 32G」的說法。
其實主要原因是 ：JVM 在內存小於 32 GB 的時候會採用一個內存對象指針壓縮技術。在 Java 中，所有的對象都分配在堆上，並通過一個指針進行引用。 普通對象指針（OOP）指向這些對象，通常爲 CPU 字長 的大小：32 位或 64 位，取決於你的處理器。指針引用的就是這個 OOP 值的字節位置。
對於 32 位的系統，意味着堆內存大小最大爲 4 GB。對於 64 位的系統， 可以使用更大的內存，但是 64 位的指針意味着更大的浪費，因爲你的指針本身大了。更糟糕的是， 更大的指針在主內存和各級緩存（例如 LLC，L1 等）之間移動數據的時候，會佔用更多的帶寬.
所以最終我們都會採用 31 G 設置(前提是你有這麼大的內存，不然還是乖乖的設置一半內存)
假設你有個機器有 128 GB 的內存，你可以創建兩個節點，每個節點內存分配不超過 32 GB。 也就是說不超過 64 GB 內存給 ES 的堆內存，剩下的超過 64 GB 的內存給 Lucene
如果你的內存只有8g（家用學習）,我建議你 設置2g就行了，集羣節點不要超過3個，根據你的內存來決定啓動幾個，否在你的電腦將會卡到爆。
加入中間加RabbitMQ:
大部分博客使用的都是中間件kafka，那麼rabbitmq應該也可以纔對。官方雖然說明不支持rabbitMQ,但那是2018年8月,中間件應該是差不多的，所以我覺得rabbitMQ應也可以纔對。繼續研究。
注：部分爲官方文檔與其他不知道（忘記了）地方複製粘貼的，此文檔爲學習fek搭建的記錄文檔