將所有文檔的列更新為Elasticsearch的最佳實踐

Question

我正在開發一個日志分析系統。 輸入是日志文件。 我有一個外部Python程序，該程序讀取日志文件並確定記錄（行）或日志文件是“正常”還是“惡意”。 我想使用Elasticsearch Update API通過添加一個名為result的新列，將我的Python程序的結果（“正常”或“惡意”）附加到Elasticsearch。 這樣我可以通過Kibana UI清楚地看到程序的結果。

簡單來說，我的Python代碼和Elasticsearch都分別使用日志文件作為輸入。 現在，我想將結果從Python代碼更新為Elasticsearch。 最好的方法是什么？

我可以想到幾種方法：

1. Elasticsearch自動為文檔分配一個ID（ _id ）。 如果我可以找到Elasticsearch如何計算_id ，那么我的Python代碼可以自行計算，然后通過_id更新相應的Elasticsearch文檔。 但是問題是，Elasticsearch官方文檔沒有說明它用於生成_id算法。

2. 我自己將一個ID（如行號）添加到日志文件中。 我的程序和Elasticsearch都將知道此ID。 我的程序可以使用此ID進行更新。 但是，缺點是我的程序每次都必須搜索此ID，因為它只是一個普通字段，而不是內置的_id。 性能會很差。

3. 我的Python代碼從Elasticsearch獲取日志，而不是直接讀取日志文件。 但這使系統易碎，因為Elasticsearch成為關鍵點。 我只希望Elasticsearch當前成為日志查看器。

因此，在當前視圖中，第一個解決方案將是理想的。 但是我不確定是否還有更好的方法？

Answer 1

如果可能，請重新構建應用程序的結構，以便將結構化的日志信息直接寫入諸如Elasticsearch之類，而不是將純文本格式轉儲至日志文件。 晚點再謝我。

這並不總是可行的（例如，如果您不控制日志源）。 我對您的解決方案有一些意見。

1. 這感覺很脆 。 Elasticsearch並不基於特定文檔的屬性_id 。 根據已存儲的現有_id字段進行選擇（我認為也是基於隨機種子）。 即使可行，依賴未記錄的屬性也是與Elasticsearch經常對記錄文件進行重大更改的團隊打交道的好方法。
2. 這個其實還不錯 。 Elasticsearch支持手動選擇文檔的ID。 即使不是這樣，它在批量詞查詢中的表現也很好，不會像您想象的那樣成為瓶頸。 如果您確實有太多數據可能會破壞您的應用程序，那么Elasticsearch可能不是最佳工具。

3. 這個解決方案很棒 。 它具有超強的可擴展性，並且不依賴於復雜的依賴關系，即如何構建日志文件，如何選擇在Elasticsearch中為該索引編制索引以及如何選擇使用Python讀取日志。 相反，您只是得到一個文檔，如果您需要更新它，則可以進行更新。

   Elasticsearch在這里並不是失敗的最糟糕點（如果ES下降，那么您的應用程序在任何這些解決方案中都將下降）–您所做的查詢（讀取和寫入）是原來的兩倍。 如果因數2使您的應用程序終止，則您可能需要一個更好的解決方案（即避免使用Elasticsearch），或者需要投入更多的硬件。 ES支持各種分片配置，您可以廉價地構建強大的服務器。

但是，有一個問題，為什么在Elasticsearch中有需要使用此特殊的正常/惡意屬性進行更新的日志？ 如果您是將它們放入ES的人，則只需在存儲它們之前對其進行適當的標記，以防止多余的閱讀困擾您。 如果這不是一個選擇，那么您可能仍想直接讀取ES，以將日志無論如何都提取到Python中，以避免再次解析原始日志文件的巨大開銷。

如果這是在發布正常/惡意代碼時對現有ES數據的一次性修補程序，則不必擔心速度提高2倍。 如果您擔心要關閉群集，只需限制查詢。 該修復程序最終將執行，並且可能比我們繼續討論最佳選擇的速度更快。