在寫這篇文章之前，我也是不是很清楚，感覺Elasticsearch的ingest node的功能越來越強大。在一次聚會上，我的一個同事也告訴我現在使用ingest node在社區裏越來越普及。他們感覺到Elasticsearch ingest node的便利，同時也可以不需額外的安裝和部署，並且還可以做其它的用途。的確隨着Elasticsearch新的ingest node的功能越來越強大，它和Logstash的很多功能也有重疊的地方。那麼我們在實際的應用中，到底是選擇Logstash還是ingest node呢。Ingest node裏也含有很多的processors供我們使用。你如果對Elasticsearch ingest node裏的processors還不是很瞭解的話，請參閱官方的鏈接https://www.elastic.co/guide/en/elasticsearch/reference/master/ingest-processors.html
一點點歷史
Logstash是Elastic Stack的原始組件之一，長期以來一直是需要分析，豐富或處理數據時使用的工具。多年來，已添加了大量輸入，輸出和過濾器插件，使其成爲一種非常靈活且功能強大的工具，可以使其在各種不同的體系結構中工作。
在Elasticsearch 5.0中引入了ingest節點，作爲在索引之前處理Elasticsearch中的文檔的一種方式。它們允許使用最少的組件的簡單架構，其中應用程序將數據直接發送到Elasticsearch進行處理和索引。這通常可以簡化Elastic Stack的入門，但是也可以隨着數據量的增長而擴展。
但是，ingest節點的確複製了Logstash中的某些功能，因此，我們用戶的一個常見問題是他們應該使用哪個功能。在此博客文章中，我們討論了在兩者之間進行選擇時需要考慮的體系結構方面，以幫助您做出更明智的決策。
從上面的圖中，我們可以看出來：針對beats的數據來說，我們可以通過如下的三條途徑：
- Beats ==> Elasticsearch
- Beats ==> Logstash ==> Elasticsearch
- Beats ==> Kafka ==> Logstash ==> Elasticsearch
在我們的實際的使用中，我們應該選擇哪一種途徑呢？
我們如何進出數據？
Logstash與ingest節點之間的主要區別之一是數據的進出方式。
當ingest節點在Elasticsearch的索引流中運行時，必須通過批量或索引請求將數據推送到該節點。 因此，必須有一個將數據主動寫入Elasticsearch的過程。 接收節點無法從外部源（例如消息隊列或數據庫）中提取數據。
處理完數據後，存在類似的限制-唯一的選擇是將數據本地索引到Elasticsearch中。
另一方面，Logstash具有各種各樣的輸入和輸出插件，可用於支持各種不同的體系結構。 它可以充當服務器並接受客戶端通過TCP，UDP和HTTP推送的數據，並主動從 數據庫和消息隊列。 當涉及到輸出時，有很多可用的選項，例如消息隊列（例如Kafka和RabbitMQ）或S3或HDFS上的長期數據歸檔。
排隊和背壓怎麼辦?
將數據發送到Elasticsearch時，無論是直接發送數據還是通過ingest管道發送數據，每個客戶端都必須能夠處理Elasticsearch無法保持或接受更多數據的情況。這就是我們所說的施加背壓（back-pressure）。如果數據節點不能接受數據，則接收節點也將停止接受數據。
如果在Elasticsearch無法訪問或無法長時間接受數據的情況下，無論是在源頭還是在過程中，在處理管道中都沒有建立排隊機制的體系結構都有可能遭受數據丟失的困擾（目前有些beats，比如Filebeat含有背壓支持）。這包括無法存儲和讀取文件數據的Beats以及其他能夠直接寫入Elasticsearch的進程，例如syslog-ng。
Logstash能夠使用其持久隊列功能在磁盤上將數據排隊，從而使Logstash至少可以提供一次傳輸保證，並通過攝取高峯在本地緩衝數據。 Logstash還支持與許多不同類型的消息隊列的集成，從而允許支持多種部署模式。
如何豐富和處理我們的數據？
Ingest節點帶有20多種不同的處理器，涵蓋了最常用的Logstash插件的功能。 但是，一個限制是，攝取節點管道只能在單個事件的上下文中工作。 處理器通常也無法調出其他系統或從磁盤讀取數據，這在某種程度上限制了可以執行的擴充類型。
Logstash有很多可供選擇的插件。 這包括基於配置文件，Elasticsearch或關係數據庫中的查找來添加或轉換內容的插件。
Beats和Logstash還支持根據可配置的標準過濾和刪除事件，這在攝取節點中目前是不可能的。
哪個更容易配置？
這是一個非常主觀的話題，取決於您的背景和習慣。每個攝取節點管道均在JSON文檔中定義，該文檔存儲在Elasticsearch中。可以定義大量不同的管道，但是每個文檔在通過攝取節點時只能由單個管道處理。這種格式可能比Logstash配置文件格式更容易使用，至少對於相當簡單且定義明確的管道而言。對於處理多種數據格式的更復雜的管道，Logstash允許使用條件控制流的事實通常使它更易於使用。 Logstash還支持定義多個邏輯上獨立的管道，這些管道可以通過基於Kibana的用戶界面進行管理。
還值得注意的是，在Logstash中，測量和優化管道性能通常更容易，因爲它支持監視並且具有出色的管道查看器UI，可用於快速查找瓶頸和潛在問題。如果你想對Logstash的監控感興趣的話，請參閱我之前的文章“Logstash: 啓動監控及集中管理”。
硬件佔用空間如何受到影響？
關於ingest節點的一大優點是它允許非常簡單的架構，Beats可以將其直接寫入攝取節點管道。 Elasticsearch集羣中的每個節點都可以充當攝取節點，這至少可以在較小的用例中降低硬件佔用空間並降低架構的複雜性。
一旦數據量增加或處理變得更加複雜，從而導致羣集中的CPU負載更高，通常建議切換到使用專用的接收節點。 此時，將需要額外的硬件來託管專用攝取節點或Logstash，並且硬件佔用空間的任何差異都將在很大程度上取決於用例。
Ingest節點可以執行Logstash無法執行的任何操作嗎？
到目前爲止，似乎Ingest節點僅提供Logstash支持的功能的子集-但是，這並不完全準確。
Ingest節點支持ingest attachment processor plugin，該插件可用於處理和索引常見格式的附件，例如PPT，XLS和PDF。當前沒有等效的插件可用於Logstash，因此，如果您打算索引各種類型的附件，則可能需要ingest節點。
由於ingest管道會在索引數據之前執行，因此它也是添加時間戳的最可靠方法，該時間戳指示何時對事件進行索引，例如爲了準確地測量和分析ingest延遲。在數據成功到達Elasticsearch之前進行設置可能會產生誤導，因爲設置時間戳和將數據索引到Elasticsearch之間可能會有延遲，例如如果正在施加背壓，或者客戶端被迫多次嘗試對數據進行索引。此類時間戳可用於衡量每個文檔的 ingest delay per document。
我們可以一起使用Logstash和Ingest節點嗎？
即使選擇常常是一個自己的喜好，但由於Logstash支持將數據發送到ingest管道，因此自然也可以將它們一起使用。 對於更復雜的體系結構，可能還會有多個邏輯流，它們可能具有非常不同的要求。 有些可能會通過Logstash，而另一些可能會直接發送到Elasticsearch接收節點。 使用對每個數據流最有意義的方法通常會使體系結構更易於維護。
在實際的使用中，由於使用多個組件一起使用，也可能會使得我們的系統的穩定性帶來一定的影響。
結論
Logstash和Elasticsearch ingest節點之間的功能存在重疊。 這意味着可以使用兩種技術來實現某些體系結構。 但是，這兩種選擇都有各自的優缺點，因此分析整個處理管道的要求和體系結構並根據此博客文章中討論的標準選擇最合適的方法非常重要。 選擇並不總是一個接一個，因爲它們可以一起或並行用於處理管道的不同部分。