全部產品
Search
文件中心

Simple Log Service:警示分組合并

更新時間:Jul 30, 2024

警示管理根據路由合并策略對合格警示發送通知。

路由合并規則

警示路由合并基於合并基準、行動策略、首次等待時間、變化等待時間和重複等待時間完成。只有上述配置完全相同時,才會被歸到同一個合并集合中。

例如某服務中的2個主機分別從20:00和20:01開始每分鐘觸發一次高CPU警示。此時您可以按照服務名稱建立警示合并策略,在首次及新增的警示被發送後,後續重複的警示將被延遲發送。

參考

合并基準

合并基準表示根據警示屬性和警示標籤進行合并。警示提供內建合并基準和自訂合并基準,詳細說明如下表所示。

合并基本類型

說明

內建合并基準

Log Service提供內建的合并基準。

  • 按警示源規則+所有標籤:由相同警示規則引發的警示,且其標籤相同時,合并為一組進行警示通知。

  • 按警示源規則:由相同警示規則引發的警示合并為一組,進行警示通知。

  • 按警示源專案:屬於同一Project下的警示合并為一組,進行警示通知。

  • 按警示源專案+嚴重度:屬於同一Project下的警示,且其嚴重度相同時,合并為一組進行警示通知。

  • 按警示源專案+所有標籤:屬於同一Project下的警示,且其標籤相同時,合并為一組進行警示通知。

自訂合并基準

您使用警示屬性和警示標籤自訂合并基準。

  • 可作為合并基準的警示屬性包括使用者aliuid、警示規則ID、警示顯示名稱、警示嚴重度、規則所在地區和規則所在專案。

  • 可作為合并基準的警示標籤包括不使用標籤、使用所有標籤和自訂標籤。

行動策略

行動策略定義了警示通知的發送方式。您可以在設定警示路由合并策略時或建立警示規則時關聯相應的行動策略。如果在合并策略配置中選擇了動態行動策略,則優先採用警示規則建立時指定的行動策略。若選擇了其他行動策略,則按照合并策略中指定的行動策略。

首次等待、變化等待和重複等待

  • 情境1:在首次等待時間內只產生警示A。

    假設首次等待時間為5秒、變化等待時間為1分鐘、重複等待時間為4小時,橙色表示警示A、藍色代表警示B。

    • 在00:00:00時,警示A產生,同時警示合并集合被建立,但是由於設定了首次等待時間,所以Log Service不會立即發送通知。

    • 在00:00:05(達到首次等待時間)時,Log Service第一次發送警示通知。

    • 第一次發送警示通知後,以變化等待時間為周期,對合并集合內的警示進行檢查。第一個變化等待時間(1分鐘)內,警示B產生並進入合并集合。所以在00:01:05時,Log Service第二次發送警示通知。

    • 繼續以變化等待時間為周期進行檢查,該合并集合內一直只有警示A和警示B。直到距離上次發送警示的間隔達到重複等待時間(4小時),即在04:01:05時,Log Service第三次發送警示通知。

  • 情境2:在首次等待時間內產生了警示A和警示B。

    假設首次等待時間為5秒、變化等待時間為1分鐘、重複等待時間為4小時,橙色表示警示A、藍色代表警示B。

    • 在00:00:00~00:00:05期間,警示A和警示B產生,同時警示合并集合被建立,但是由於設定了首次等待時間,所以Log Service不會立即發送通知。

    • 在00:00:05(達到首次等待時間)時,第一次發送警示通知。

    • 第一次發送警示通知後,以變化等待時間為周期,對合并集合內的警示進行檢查。在00:00:05~04:01:05期間,該合并集合內一直只有警示A和警示B。直到距離上次發送警示的間隔達到重複等待時間(4小時),即在04:01:05時,第二次發送警示通知。

參數

說明

首次等待

首次建立合并集合後,等待多久發送第一次警示通知。通常設定為秒層級的時間。

變化等待

合并集合內的警示資料(新增警示或警示狀態改變)發生變化後,等待多久發送警示通知。通常設定為分鐘層級的時間。如果您需要儘快收到警示通知,也可設定為秒級時間。

重複等待時間

合并集合內的警示資料重複(無新增警示和狀態變化,僅其他屬性例如標題、內容等改變)後,等待多久發送警示通知。通常設定為小時層級的時間。

說明

當您在建立時配置了動態行動策略,則無需在警示策略中配置重複等待時間。系統預設用警示監控規則的重複等待時間覆蓋警示分組的重複等待時間。

樣本

建立警示監控規則時,您可以配置不同的警示策略,將觸發的警示進行分組合并或者不合併作業。以下是具體樣本。

情境1:分組合并

按照規則所在專案、env標籤和service標籤,對警示進行合并。

  • 警示事件

    // 警示A
    {
      "alert_name": "Alert1",
      "project": "Project1",
      "labels": {
        "env": "test",
        "service": "service1"
      }
    }
    
    // 警示B
    {
      "alert_name": "Alert2",
      "project": "Project1",
      "labels": {
        "env": "prod",
        "service": "service2"
      }
    }
    
    // 警示C
    {
      "alert_name": "Alert3",
      "project": "Project1",
      "labels": {
        "env": "test",
        "service": "service1"
      }
    }
    
    // 警示D
    {
      "alert_name": "Alert4",
      "project": "Project1",
      "labels": {
        "env": "prod",
        "service": "service2"
      }
    }
  • 配置

    image

  • 合并結果

    警示A和警示C歸到同一個合并集合中,警示B和警示D被歸到同一個合并集合中。

情境2:不合并機制

在警示策略的路由合并配置中,如果設定合并基準警示規則+所有標籤,則警示會按照合并基準分到不同合并集合。例如,有如下兩個警示監控規則:

  • 警示監控規則1開啟分組評估,警示策略配置為不開啟進階模式開關,合并基準警示規則+所有標籤。那麼警示管理將分別發送主機1警示、主機2警示和主機3警示通知。

  • 警示監控規則2不開啟分組評估,警示策略配置為不開啟進階模式開關,合并基準警示規則+所有標籤。那麼警示管理將發送一條包含所有主機的警示通知。

buhebing