何時在 Graylog (Elasticsearch) 中使用新索引？
我一直在尋找幾天來找到關於 Graylog/Elasticsearch 如何使用索引以及何時創建新索引的一個很好的解釋。有很多關於分片索引的資訊，但關於索引本身的資訊並不多，除了它們是一組關於要保留多少數據以及如何管理它們的設置，但不是為什麼。（或者在我看來）
背景：
我們將 Graylog 4.0 與 Elasticsearch 7.10 和 MongoDB 3 一起使用。
我們嘗試集中來自 6 個倉庫位置的日誌（彼此相距數百公里）。每個都有 6 到 20 個 RFID 門，每個門都有日誌。每個門都有連接到中央控制器中間件的連接器中間件，並且所有這些中間件都有日誌。然後是自動化倉庫“AWMS”的控制器、WMS伺服器、ERP伺服器及其前端。我們還考慮從執行這些服務的伺服器的 Windows 事件日誌中收集至少一些事件。
通常我們需要分析一個子系統中的問題，因此需要搜尋其中一個日誌。有時我們需要查看從 RFID 門到 AWMS、WMS 和 ERP 的整個流程。
目前，我考慮為每個日誌創建一個流，並在搜尋中使用相關的流。（或者這種方法是否已經存在缺陷，如果是，為什麼？）
問題：
- Graylog中設置的索引是否只是保留策略的設置？
- 如果我有很多或幾個索引，會有什麼影響？
- 在Elasticsearch Index Model中，聽起來分片大小及其分佈對搜尋性能有主要影響，而索引只是管理分片的框架
- 我的案例應該有多少個索引集？
- 每個流多個？
- 每個流一個？
- 每個位置一個？
- 每個子系統一個？
- 每個保留時間或大小間隔一個？
- 一個全球的？
- 從性能的角度來看，這重要嗎？
- 我在哪裡可以找到關於這些東西的更多資訊，這解釋了“為什麼”，而不僅僅是“如何”來管理索引？（我一直在研究Graylog 索引模型、Elasticsearch 索引模型、Elasticsearch 索引模板）
Graylog中設置的索引是否只是保留策略的設置？
不要忘記索引集對底層 ElasticSearch 基礎設施中的索引有直接影響，您應該考慮到這一點，因為 ElasticSearch 完全與索引及其分片（數據分佈、副本等）有關。
數據類型和欄位也是一回事：您不能（不應該）在同一個索引集中擁有具有混合數據類型的相同欄位（例如，如果欄位
device存在是Integer因為 System1 使用設備號但 System2 需要Text類型這個欄位，因為設備標識符是一個字元串，那麼您應該將所有內容儲存為字元串，或者創建一個單獨的索引集以將兩種數據類型及其各自的好處保持在相同的欄位名稱下）。這通常是您可能不想將 Windows 日誌儲存在與其他任何內容相同的索引集中的原因（將此應用於您的案例，這可能適用於您的 ERP/WMS 數據源？…）因為它們可以容易導致數百個不同的欄位（建議避免超過每個索引限制1000 個欄位）。
所以，不，這不僅僅是關於保留策略。作為反思的起點，我建議您考慮在其索引集中對各種數據源類型進行分組（Windows 日誌的索引集，Linux 伺服器的另一個索引集，例如防火牆的另一個索引集，因為從數據類型來看它是有意義的觀點看法）。
如果我有很多或幾個索引，會有什麼影響？
這取決於您的 ElasticSearch 基礎設施，並且“很多”是未定義的……看看Sizing ElasticSearch和Size your shards。記住您將執行什麼樣的查詢以及在哪個時間範圍內可能有助於在索引大小和 ElasticSearch 必須查詢以滿足您的請求的索引數量之間找到適當的平衡。
不幸的是，沒有一種萬能的分片策略。在一種環境中有效的策略可能無法在另一種環境中擴展。一個好的分片策略必須考慮到您的基礎設施、案例和性能預期。
$$ … $$
我的案例應該有多少個索引集？
流配置了一個索引集，不能為一個流設置多個索引集。關於其他點，我已經在上面回答了。
但是，請注意，您可以在同一個索引集上配置多個流，如果您想將這些流與相同的基礎數據一起使用並且只想限制某些使用者對日誌子集的訪問，這非常有用：您可以路由消息根據您想要的各種流之間的條件，如果這些流都共享相同的索引集，您將不會複製消息。