Prometheus之Alertmanager介紹

一 告警功能概述

Prometheus對指標的收集、存儲同告警能力分屬於Prometheus Server和Alertmanager連個獨立的組件，前者僅負責基於告警規則生成告警通知，具體的告警操作則由后者完成；

• Alertmanager負責處理由客戶端發來的告警通知
  • 客戶端通常是Prometheus Server，但它也支持接收來自其它工具的告警；
  • Alertmanager對告警通知進行分組、去重后，根據路由由規則將其路由到不同的receiver，如Email、短信或PagerDuty等；

二 Prometheus告警邏輯

• 首先要配置Prometheus稱為Alertmanager的告警客戶端；
  • 反過來，Alertmanager也是應用程序，它自身同樣應該納入Prometheus的監控目標；
• 配置邏輯
  • 在Alertmanager上定義receiver，他們通常是能夠基於某個媒介接收告警消息的特定用戶；
    • Email、Wechat、Pagerduty、Slack和Webhook等是為常見的發送告警信息的媒介；
    • 在不同的媒介上，代表告警消息接收人的地址表示也會有所不同；
  • 在Alertmanager上定義路由規則（route），以便將收到的告警通知按需分別進行處理；
  • 在Prometheus上定義告警規則生成告警通知，發送給Alertmanager；

三 Alertmanager 

3.1 Alertmanager功能

Alertmanager除了基本的告警通知能力外，Alertmanager還支持對告警進行去重、分組、抑制、靜默和路由等功能；

• 分組（Grouping）：將相似告警合並為單個告警通知的機制，在系統因大面積故障而觸發告警潮時，分組機制能避免用戶被大量的告警噪聲淹沒，進而導致關鍵信息的隱沒；
• 抑制（Inhibition）：系統中某個組件或服務故障而觸發告警通知后，那些依賴於該組件或服務的其它組件或服務可能也會因此而觸發告警，抑制便是避免類似的級聯告警的一種特性，從而讓用戶能將精力集中於真正的故障所在；
• 靜默（Silent）：是指在一個特定的時間窗口內，即便接收到告警通知，Alertmanager也不會真正向用戶發送告警信息的行為；通常，在系統例行維護期間，需要激活告警系統的靜默特性；
• 路由（route）：用於配置Alertmanager如何處理傳入的特定類型的告警通知，其基本邏輯是根據路由匹配規則的匹配結果來確定處理當前告警通知的路徑和行為；

3.2 告警規則文件

類似於記錄規則，告警規則（Alerting rule）也定義在獨立的文件中，而后由Prometheus在rule_files配置段中加載；

• 盡管可以將所有的告警規則定義在同一個文件中，但出於便捷管理之目的，建議將其按功能分布放置於不同的文件中；
• rule_files配置段加載告警規則的文件，同樣可以使用文件名通配機制；

rule_files:
  - "rules/*.yaml"
  - "alert_rules/*.yaml"   #專用於加載告警規則相關的文件

3.3 告警規則

類似於記錄規則，有着類似或相關聯功能的告警規則同樣可以組織為group，從而為規則名稱提供“名稱空間”；一個組內的每個告警規則必須有個名稱，且在該組內其名稱必須唯一；

• alert：告警規則的名稱
• expr：基於PromQL表達式的告警觸發條件（布爾表達式），用於計算是否有時間序列可以滿足該條件；可以使用由Recording rule定義的指標；
• for：控制在觸發告警之前，測試表達式的值必須為true的時長；
  • 表達式值為true，但其持續時間未能滿足for定義的時長時，相關的告警狀態為pending；
  • 滿足該時長之后，相關的告警江北觸發，並轉為firing狀態；
  • 表達式的值為false時，告警將處於inactive狀態；
• labels：告警規則被激活時，相關時間序列上的所有標簽都會添加到生成告警實例之上，而labels則允許用戶在告警上附加其它自定義的標簽；該類標簽支持模板化；
  • 告警的名稱及其標簽即為告警的標識，因而，這類似於時間序列的標識機制；
• annotations：附加在告警之上的注解信息，其格式類似於標簽，但不能被用於標識告警實例；經常用於存儲告警摘要，且其值支持模板化；

3.4 觸發告警

• Prometheus以一個固定的周期來評估所有告警規則，其值由evaluate_interval參數定義，默認15s；在每個評估周期內，Prometheus會計算每個告警規則中的布爾表達式並更新告警狀態；
• 未使用for字句的告警，會自動從Inactive狀態轉為Firing，它只需要一個評估周期便能觸發；而帶有for字句的告警狀態將先轉為Pending，而后才到Firing，因而至少需要兩個評估周期才能觸發；
  • 除以Pending狀態的告警，在其支持時長滿足for字句的定義之前，若布爾表達式的值轉回了false，則告警狀態將轉回Inactive；
  • 由此可見經由Pending在到Firing的轉換，可以確保告警更有效，且不會來回浮動；
• Prometheus將為Pending和Firing狀態中的每個告警創建指標，該指標名稱為ALERT，其值固定為1，並且在告警處於Pending和Firing狀態期間存在；在此之后，它將不接受任何更新，知道過期；

3.5 告警模板

Prometheus支持在告警中使用模板

• 告警模板是指在告警中的標簽和注解上引用時間序列的標簽和樣本值的方法；
• 它使用標准的Go語法，並暴露一些包含時間標簽和值的變量；
  • 標簽引用：{{$label_name}}
  • 指標樣本值引用：{{$value}}
• 若要在description注解中引用觸發告警的時間序列上的instance和job標簽的值，可分別使用“{{$label.instance}}”和“{{$label.job}}”；

3.6 告警路由

Alertmanager的route配置段支持定義樹狀路由表，入口位置稱為根節點，每個子節點可以基於匹配條件定義出一個獨立的路由分支；

• 所有告警都將進入路由根節點，而后進行子節點遍歷；
• 若路由上continue字段的值為false，則遇到第一個匹配的路由分支后即終止；否則，將繼續匹配后續的子節點；

3.7 記錄規則

3.7.1 recording rule

• 記錄規則將生成新的時間序列，因而其名稱必須是規范的指標名稱格式；
• 記錄規則必須定義在規則組（rule group）中，各規則按給定的順序依次運行；

3.7.2 規則組的定義語法

groups:
  [ - <rule_group> ]
  
<rule_group>

name: <string>
[ interval: <duration> | default = global.evaluation_interval ]
[ limit: <int> | default = 0 ]

rules:
  [ - <rule> ... ]

3.7.3 記錄規則的定義語法

<rule>

record: <string>
expr: <string>
labels:
  [ <labelname>: <labelvalue> ]

3.7.4 記錄規則使用案例

記錄規則通常要保存於單獨的文件中。如rules/recording_rules.yaml;

而后在prometheus.yml中通過rule_files加載該文件；

groups:
  - name: example
    rules:
    - record: job:http_inprogress_requests:sum
      expr: sum by (job) (http_inprogress_requests)