前言

在前一章節中，我們已經詳盡地介紹了設定告警規則的各種細節，並深入了解了告警規則在評估過程中所經歷的不同狀態變化及其所代表的意義。經過這一番學習，相信你已經對告警規則的運作方式有了全面的認識。

接下來，讓我們再接再厲，深入探討 Grafana Alerting 將告警事件送出後的一系列運作機制。我們將全面掌握告警事件的傳遞流程、通知設定，以及如何確保告警訊息能夠及時且有效地送達到相關負責人手中。通過這一章節的學習，你將對 Grafana Alerting 在告警事件管理上的整體流程有更完整的了解，進一步強化我們的監控與告警能力。

告警事件通知

Notification 與 Contact Point

在 Grafana 的告警系統中，Notification Policy 和 Contact Point 是兩個關鍵組件，負責將告警通知有效地傳遞給相關人員。透過 Notification Policy，我們可以使用各種彈性且有效的方法，將告警通過 Contact Point 傳遞出去。此外，我們也可以選擇更簡單的方式，直接在告警規則中指定 Contact Point，這樣只要告警觸發，就會將通知直接發送到設定的 Contact Point。

Notification Policy 是告警系統的核心，提供了彈性的路由方式。它可以根據告警的標籤、條件和時機來決定將告警傳遞到哪一個 Contact Point。這種彈性配置可以大幅減少告警噪音，並確保每個告警都能正確傳達。

Notification Policy 可以實現以下功能：

• 定義嵌套的策略，讓子策略繼承或覆蓋父策略的設定。
• 根據告警標籤匹配合適的 Notification Policy，實現告警的動態路由。

Contact Point 是用來設定告警通知的具體目的地，例如電子郵件、Slack、OnCall、Webhook 等。它包含了一組整合配置，可以自訂通知訊息並使用通知模板。Contact Point 可以直接被指定於告警規則中，或者透過 Notification Policy 來傳遞告警。

Notification Policy 與 Label 設計

在 Alerting 中的 Notification Policy 設定中，我們可以像是熟悉的 Prometheus 告警規則一樣，針對不同的告警事件，添加不同 label 和設定不同的通知策略。這使告警事件的通知鏈路更加清晰，也讓我們在通知策略中可以更方便地使用這些標籤來過濾和分組告警通知。

我們也在前面的介紹中不斷的強調 Folder 在 Grafana 設計理念中的重要地位，而 Folder 的設計理念與 Notification Policy 的設計是相輔相成的。因為當我們將告警規則設定在特定 Fodler 之下，Grafana 就會自動將告警規則所屬的 Folder 以 grafana_folder 標籤的形式添加到告警規則中，這樣的設計讓我們在通知策略中可以更方便地使用這些標籤來過濾和分組告警通知。所以只要我們在 Folder 階層中定義好清晰的團隊、服務、環境的結構，就可以在通知策略中快速過濾出我們所需要的告警通知。

由上面的兩張圖片，我們可以清楚的看到，即使我們沒有特地加上 grafana_folder 這個標籤，Grafana 依然會自動幫我們隱性附加上去。

Note: 前綴為 grafana_ 的標籤由 Grafana 保留以供特殊用途。若要取消 Grafana Alerting 新增保留標籤，可以透過 Unified_alerting.reserved_labelsdisabled_labels 配置中的選項來停用它。

告警規則 Grouping 與 Muting 設定

在告警規則的 Notification 設定中，許多設定會繼承自 Notification Policy，例如 Grouping 和 Muting 設定，但我們仍然可以根據不同情況，彈性地覆蓋父層的設定。這裡有幾個值得注意的重點：

• Muting timings：我們可以單獨設定 Muting Time，並在不同的告警規則中重複使用，達到更精細的靜音控制。
• 分組（Grouping）：在 Grafana Alerting 中，預設使用 grafana_folder 和 alertname 作為分組標籤，這使得同一個 Folder 下的告警事件能夠直覺地被歸類，方便管理和查看。
• 時間設定（Timings）：這裡提供了 Prometheus AlertManager 中熟悉的三個參數：Group wait、Group interval 和 Repeat interval。在 Grafana 中，我們可以以告警規則為最小單位來進行調整，提供更靈活的時間控制。

Contact Point 設定

Contact Point 是用於設定告警通知發送方式的配置。在告警規則或 Notification Policy 中，都可以指定一個 Contact Point 來進行通知。

一個 Contact Point 可以包含多種整合方式，每一個方式都可以將通知發送到特定的電子郵件、Webhook，或其他服務，例如 Slack、PagerDuty、Grafana OnCall 等。此外，Contact Point 還定義了要發送的通知訊息，可以是預設訊息、自訂訊息，或使用通知模板。

你也可以配置一個不指定任何整合方式的 Contact Point，此時將不會發送任何通知。

Notification Policy 設定

Notification Policy 決定告警如何路由到 Contact Point。它們以樹狀結構呈現，每個 Policy 都可以有一個或多個子 Policy。除了預設的 Default Policy 外，其他 Policy 都可以匹配特定的告警標籤。

當告警觸發時，會首先由 Default Policy 進行評估，然後再由各個子 Policy 進行匹配。這些子 Policy 繼承 Default Policy 的設定，除非在子層上進行覆蓋。此外，每個 Policy 都會指定要將匹配到的告警發送到哪個 Contact Point，實現告警的靈活路由。

Notification Policy 與 Label 匹配

使用 Label 匹配可以將告警規則連結到 Notification Policy 和 Silence，提供彈性管理告警的方式，決定由哪個 Policy 處理，或哪些告警需要靜默。

Label Matcher 由三個部分組成：標籤名稱、運算子和值。

• 標籤名稱：必須精確匹配要連結的標籤名稱。
• 值：依據運算子的不同來決定如何匹配。
• 運算子：包括 =（完全匹配）、!=（不等於）、=~（正則匹配）、!~（不正則匹配）。

當使用多個標籤匹配器時，它們會使用 AND 邏輯運算，必須全部符合才算匹配成功。

Notification Policy 的路由順序

在 Notification Policy 的路由順序中，首先評估的是預設的 Default Policy。一旦找到匹配的 Policy，系統會按照顯示順序繼續評估其子 Policy。如果子 Policy 與告警匹配，系統會遞迴地評估其更深層的子 Policy，直到找不到匹配為止。最深層的匹配 Policy 將負責處理該告警。

預設情況下，當系統找到一個匹配的 Policy 後，不會繼續搜尋同層的其他 Policy。但如果希望該告警能同時被其他同層的 Policy 處理，可以啟用「Continue matching sibling nodes」的選項。

Note：預設的 Default Policy 會匹配所有告警，並在沒有子 Policy 或子 Policy 無法匹配告警標籤時負責處理該告警，確保沒有任何告警被遺漏。

Slience 與 Muting 的差異

在 Grafana Alerting 中，Silence 和 Muting 都是用來控制告警通知的方式，但它們的應用範圍和使用場景有所不同：

• Silence（靜默） 用法：Silence 是一個臨時的設定，用來在特定時間段內抑制特定告警的通知。可以指定標籤組合（如服務名稱、環境等）來設置 Silence，使匹配這些標籤的所有告警在靜默期間不發送通知。 場景：通常用於計劃內的維護或事件處理期間，防止不必要的告警通知，避免干擾。適用於需要在特定時間段內暫時禁止某些告警的情況。

• Muting（靜音） 用法：Muting 是在 Notification Policy 中設定的，用於永久地靜音特定類型的告警。它會根據告警的標籤組合來決定哪些告警不應該觸發通知。 場景：適合用於長期或永久性不需要通知的告警，例如一些非關鍵性指標的告警，或者頻繁觸發但不影響服務的告警。

告警模版與模版語言

在 Prometheus AlertManager 中，我們就已經知道告警模版與模版語言的強大，而在 Grafana Alerting 中，我們也可以使用相同的語法加上更彈性的方式來進行告警模版的設定。透過引入動態內容到告警通知內容中，並且不論是 Label 或是 Annotation 都可以使用模版語言來豐富的告警上下文。

在官方提供的圖片中，我們可以看到整個模版化的過程。從最一開始告警規則評估後取得 intance 的標籤值，在 Annotation 中被模版動態的產生出 server1 的數值，而在通知的訊息中，我們也可以看到告警的詳細資訊。

告警注釋模版

告警註釋模板是一種自訂告警通知的有效方式，透過定義註釋可以為告警添加額外的資訊和上下文。Grafana 官方建議我們在註釋中定義 summary、description、runbook url 等常用欄位，以提供更豐富的背景資訊，協助快速定位問題。值得注意的是，Grafana Alerting 會將 dashboard id 和 panel id 一起定義在註釋中，這意味著即使告警規則綁定的 Dashboard 或 Panel 不存在，也不會影響到告警的運作，確保告警能夠正常發送。

告警標籤模版

上圖是一個簡單的範例，展示如何使用標籤模板來生成告警等級：

{{ if (gt $values.A.Value 90.0) -}}
critical
{{ else -}}
low
{{- end }}

告警標籤模板允許我們在告警規則中動態生成標籤值，這在以下情況非常有用：

• 動態生成標籤：在某些情況下，標籤的值可能需要根據告警規則的評估結果動態生成。例如，根據不同的 CPU 使用率生成不同的告警等級。
• 減少重複：如果多個告警規則需要生成相同的標籤值，可以使用模板來減少重複。
• 提高可讀性：通過使用模板，可以將標籤的生成邏輯與告警規則分離，提高代碼的可讀性和可維護性。

在這個例子可以看出 Grafana Alerting 的標籤模版應用場景更勝 Prometheus AlertManager 一籌。在多重查詢和告警模版語法的搭配之下，我們擁有更大的空間去設定告警規則。

告警通知模版

通知範本用於自訂告警通知的格式和內容，確保每次發送的通知都具有一致性。所以它並不是與標籤模版和注釋模版一同屬於告警規則的設定，而是屬於 Contact Point 的設定。

透過使用通知範本，可以根據不同的聯絡點（Contact Points）來定義通知的標題、描述和額外資訊，使通知更具可讀性和針對性。Grafana 提供了靈活的模板語法，讓我們可以根據告警的標籤、查詢結果和註釋內容來構建通知訊息。此外，透過自訂通知範本，我們可以在通知中包含重要資訊，如告警狀態、觸發時間、影響範圍等，從而讓接收者能更快速地了解問題情況並採取相應行動。

在告警通知模版設定的介面中，我們可以享受到 Grafana 的良好的模版預覽體驗，透過可視化的方式來進行告警通知模版的設定。

使用 Webhook.site 驗證告警通知內容

設定好 Contact Point 和告警通知模版後，我們可以透過 Webhook.site（https://webhook.site/） 這個線上工具來驗證告警通知的內容。

此時，我們只要在告警規則中，指定 Webhook.site 作為 Contact Point，並在告警通知模版中，使用 Webhook.site 中提供的 URL 作為通知的接收地址，就可以透過發送測試告警事件來驗證告警通知的內容。

Note: Webhook.site 是一個提供 Webhook 免費的線上驗證工具，可以幫助我們快速驗證告警通知的內容。

結語

在這個 Grafana Alerting 系列中，我們詳細的提供了等同於保母級的設定介面介紹，透過各種實際的介面操作連結搭配實際案例，讓大家可以快速的了解並上手 Grafana Alerting 的各項功能。在這過程中我們循序漸進的從 Prometheus AlertManager 的介紹到 Grafana Alerting 的交叉比對，讓大家可以清楚的知道兩者之間的差異與功能上的不同。這也是我們在實際的導入與規劃時，可以更清楚的知道兩者之間的定位與適合的應用場景。

最終，期望我們可以根據不同的需求來選擇使用 Grafana Alerting 或是 Prometheus AlertManager，甚至可以兩者並用，互相搭配，例如：在 Grafana 中使用告警規則來進行告警的初步過濾，然後再將符合條件的告警事件透過 AlertManager 進行更細緻的路由和通知。