發布日期:2021/11/17
Splunk 管理員日益面臨向多個使用者和應用程式提供 Splunk 服務的獨特挑戰,同時根據總體業務需求平衡服務品質。 大多數時候,它們都有一個共用的 Splunk 基礎結構,這使得根據工作負載優先順序分配 Splunk 資源變得複雜,並確保適當的資源隔離,以防止嘈雜的鄰居問題。
我們將分享Splunk 工作負載管理如何用於解決這些問題, 介紹如何配置該功能,並使用它來保留資源以用於引入和搜索工作負載。
Splunk 工作負載管理首先在 Splunk 企業 7.2 中發佈,後來在 Splunk 企業 7.3 中得到改進。
如何開始工作負載管理
工作負載管理是一個基於規則的框架,用於將系統資源(計算和記憶體)分配給各種工作負載,並在其生命週期中管理工作負載。 對於資源配置,工作負載管理在 Linux 作業系統中使用 cgroup功能。 因此,在使用工作負載管理進行資源配置之前,您需要在所有伺服器(搜索頭和索引子)上設置 cgroup 層次結構。 根據是否使用 systemd,有多種方法可以做到這一點。
分配給 Splunk 的整個系統資源分為三個預定義的類別 - 引入、搜索和雜項。 對於每個類別,您可以分配資源和創建資源池。 對於"引入"和"雜項"類別,您只能創建預設池。 對於搜索類別,您可以創建多個池並從"搜索"類別分配資源。 如果分配給池的 CPU 資源未充分利用,則它們會自動與其他池中運行的工作負載共用。 但是,記憶體分配是池中工作負荷可以使用的最大記憶體。
所有關鍵 Splunk 進程都在引入池中運行,因此,可以通過為每個池設置適當的記憶體限制來提供對 OOM 的保護。 在下面的示例中,即使在運行多個搜索的最壞情況下,引入池獲得至少 30% 的記憶體,因為搜索池和雜項池的總記憶體限制為 70%(65%+5%)。 這在負載沉重的部署中提供了記憶體保護。 模組化和腳本化輸入在雜項池中運行。
對於搜索頭,可以使用圖形化使用者介面定義資源設置。 定義後,這些設置將保存在workload_pools.conf 檔中。 對於索引子群集,需要通過群集母版推送此檔。 在大多數情況下,workload_pools.conf 在搜索頭和索引子之間應該相同,但這不是要求。 如果使用多個獨立搜索頭或具有相同索引子群集的搜索頭群集,則可能需要每個搜索頭(群集)和索引子群集使用不同的設定檔。

注意:這只是一個示例。 分配將取決於您的特定工作負載和部署。
定義工作負荷池後,您可以創建工作負荷規則,將搜索放在不同的搜索池中。 這些規則是謂詞(如應用、使用者、角色和索引)的邏輯組合(例如,如果index=security AND role=security_team,則將搜索置於優先順序池中)。 按順序計算規則,一旦匹配規則,將執行相應的操作。 不計算匹配規則下面列出的規則,因此規則的順序非常重要。 例如,在下面的方案中,規則#2永遠不會匹配。 通常,應將更嚴格的規則排序在頂部。
1. index=security,然後將搜索放在標準池中
2. index=security AND role=security_team,然後將搜索置於優先順序池
引入和搜索工作負載的資源配置
通常,您希望確保繁重的搜索工作負荷不會導致資料引入延遲或丟棄,反之亦然,搜索執行不會因為大量引入負載而受到影響。 這可以通過跨攝錄和搜索類別分配 CPU 和記憶體資源來實現。 下面的示例演示了在啟用工作負載管理的四個時間段通過引入和搜索工作負載的 CPU 利用率。

來自Splunk監控控制台的 CPU 利用率監控
工作負載管理使您能夠分配 Splunk 資源,以滿足您的業務和運營要求。 您可以使用一組規則自動將搜索放置在不同的池中,還可以為某些使用者提供細微性存取控制以選擇自己的工作負荷池。 此外,豐富的監視功能允許您跟蹤利用率並微調資源配置。