前言

在前面的章節中，我們已經對告警事件中心有了初步的了解，並介紹了告警處理的核心服務，包括 Prometheus Alertmanager 和 Grafana Alerting 的角色定位及其詳細的架構設計。隨後，我們也探討了告警事件中心中的關鍵角色——Grafana OnCall，這使得我們能夠在適當的時間，將告警事件傳遞給最合適的負責人。

這一切鋪墊都是為了接下來的內容，將介紹如何利用 Grafana 全家桶搭建完整的告警事件中心。在接下來的章節中，我們將綜合運用之前介紹的各種工具與概念來實現這一目標。現在，讓我們來看看這些工具如何協同工作，設計出一個高效的告警事件中心架構吧！

了解告警事件管理的主要痛點

在實務上，告警事件管理的範疇非常廣泛，不僅需要了解我們監控的對象、監控的原因以及如何進行監控，還涵蓋了告警事件的收集、處理、通知、輪值以及分析等各個層面。這些概念非常複雜且廣泛，必須具備一定的專業知識才能全面掌握告警事件的全貌，而這也是我們一直努力的方向。

許多團隊往往會使用多種不同的監控和告警系統來應對不同的業務需求和平台，以下我們將列舉幾種系統作為整合監控告警的範例：

• 雲端供應商告警系統：在雲端託管環境中，通常透過雲端供應商提供的監控系統來監控資源，並設定告警規則，如 AWS CloudWatch、Azure Monitor 和 Google Cloud Monitoring。
• Prometheus 監控告警系統：在 Kubernetes 環境中，我們可能會使用 Prometheus 來監控資源，並透過 Alertmanager 發送告警通知。
• Grafana 監控告警系統：如果使用 Grafana 作為統一的監控入口，則可以輕鬆使用 Grafana Alerting 來定期評估各種資料來源，並發送告警通知。
• 地端常用監控系統：某些團隊可能使用傳統的地端監控系統來監控資源並發送告警通知，如 Zabbix 和 Nagios。
• 其他第三方告警系統：有些第三方商用監控系統由於其強大的功能特性，會在特定情境下使用，如 DataDog、PagerDuty 和 OpsGenie。 從上述案例中，我們可以發現，幾乎沒有一套完美的解決方案能夠滿足所有需求。隨著業務和團隊規模的擴大，維護和管理這些各自獨立運作的系統將變得越來越困難。

當我們仔細分析這些痛點後，顯而易見的一點是：既然沒有一套完美的解決方案能完全滿足需求，我們就必須找到一套經過良好規劃的方案，來「整合」這些不同的系統，以解決我們面臨的問題。決方案能夠滿足我們所有的需求，那麼我們就必須找到一套經過良好規劃且能夠「整合」這些系統的解決方案。

Grafana 告警事件中心概念 - 整合一切

還記得 Grafana 打造的 LGTM 產品線以及各種開源監控專案，幫助我們搭建出完整的可觀測性基礎設施嗎？這些工具包括我們熟悉的 Loki、Grafana、Tempo、Mimir、Prometheus 和 Alertmanager。Grafana 團隊付出的努力，正是為了將軟體開發生命週期中的所有監控和可觀測性需求，無論是事前的測試還是上線後的監控、分析、告警與通知，全部整合進 Grafana 全家桶中。

但這還不是 Grafana 團隊的終極目標。他們還希望將 告警事件管理 也納入 Grafana 全家桶。因此，我們看到 Grafana 設計出能夠兼容多種資料來源的告警系統，解決我們告警系統分散難以管理的窘境，並與 Prometheus Alertmanager、Grafana OnCall 甚至是還沒開源的 Grafana Incident 完美整合，提供強大的告警事件管理功能。這將是本章的重點，接下來我們將詳細介紹如何將告警事件管理整合到 Grafana 全家桶中的各種關鍵思路。

告警資料來源整合

在告警管理中，使用多樣化的資料來源來評估告警規則是必須的，而最常見的資料格式便是時序指標（Time-Series Metrics）。這種格式在實時監控系統狀態上極具優勢，特別是對於資源使用、性能指標的追蹤等，能夠提供準確的數據。因此，Prometheus 作為開源社群中的領先時序數據收集與儲存工具，憑藉其廣泛的兼容性，成為告警資料來源整合的核心支柱。Grafana Alerting 與 Grafana 的 Datasource 完美整合，則進一步彌補了 Prometheus 在非監控指標場景的不足，使我們能夠利用更多類型的資料來進行告警評估。

Prometheus 整合

在當前的開源社群中，Prometheus 已成為收集和存儲時序指標的標準解決方案。它的彈性來源於廣泛的 Exporter 機制，能夠輕鬆整合各種服務和資源，並將這些資源的監控指標轉化為時序數據。以下是幾個常見的整合場景：

• 主機指標收集：若需監控伺服器主機的資源使用情況，可以使用 Node Exporter（收集硬體資源指標）、cAdvisor（收集容器資源使用情況）、Blackbox Exporter（檢測外部系統可用性）等工具，將主機的詳細指標收集到 Prometheus 中。
• 第三方服務指標收集：針對常見的第三方服務，開源社群提供了各式各樣的 Exporter，如：MySQL Exporter（收集 MySQL 數據庫性能指標）、Redis Exporter（收集 Redis 服務運行情況）、Elasticsearch Exporter（收集 Elasticsearch 集群狀態），使得不同服務的監控能無縫整合到 Prometheus 中。
• 雲端供應商指標收集：雲端供應商如 AWS，其資源的監控數據需要透過 API 或 CLI 來獲取。透過 Yet Another CloudWatch Exporter (YACE)，可以將 AWS 平台中的資源指標如 EC2、RDS、S3 整合到 Prometheus 中，實現對雲端資源的全面監控。

Grafana 整合

Grafana 一直以來都專注於兼容各種資料來源，並實現了他們推崇的 Big Tent 理念。這使得 Grafana 不僅僅是一個圖表工具，而是一個強大的監控和可觀測性平台。在 Grafana Alerting 中，您可以使用任何 Grafana 支援的資料來源來作為告警規則的依據。這不僅補足了 Prometheus 在非時序監控指標上的局限性，還讓使用者可以利用日誌、追蹤、雲端資料等非傳統指標進行告警設定。

告警事件路由整合

到目前為止，我們已經能夠將所有的告警資料來源整合到 Prometheus 和 Grafana，並利用這些工具來評估是否需要觸發告警事件。對應的告警事件將分別發送至 Prometheus Alertmanager 和 Grafana Alerting 進行處理，這有效解決了告警資料來源過於分散的問題。然而，接下來我們面臨的挑戰是如何統一管理這兩套不同系統的告警事件路由，確保告警能夠準確地傳遞到適當的處理系統。

將 Grafana Alerting 告警事件轉發到 Prometheus Alertmanager

還記得我們之前提到的 Grafana Alerting 架構嗎？它的內部設計主要基於 Grafana Evaluation Engine，並與內部的 Prometheus Alertmanager 緊密集成。然而，這個內部的 Alertmanager 僅能接收來自 Grafana 內部的告警事件，這意味著它在架構上更像是告警事件的生產者與通知者。

基於此，我們可以利用 Grafana Alerting 的通知機制，將其告警事件轉發至外部的 Prometheus Alertmanager 來進行統一的告警管理。這樣，Prometheus Alertmanager 不僅能處理來自 Prometheus 自身的告警事件，還能整合來自 Grafana Alerting 的事件，實現更全面的告警管理。

在我們開啟了接收 Grafana Alerting 的告警事件設定後，我們可以在 Prometheus Alertmanager 中看到來自 Grafana Alerting 的告警事件。這樣的設計不僅簡化了多系統之間的告警管理，還能讓我們統一管理所有告警事件的路由策略。此外，您可以在 Alerting Settings 頁面中選擇告警事件是否同時發送至 Grafana Alerting 和 Prometheus Alertmanager，以便進行靈活的告警通知。

Note: 如果在 Grafana Alerting 選擇直接透過 Contact Points 通知的話，那麼告警事件會直接發送到 Contact Points 定義的對象，而不會繼續轉發到 Prometheus Alertmanager。

告警事件待命通知整合

在 Prometheus Alertmanager 的定義中，它的主要職責是處理告警事件並發送通知，但它缺乏 Grafana OnCall 所具備的輪值排班和告警分析功能。在實務中，告警事件往往會被無差別地大量發送，導致告警疲勞的問題，這是許多運維團隊的痛點之一，因為告警無法精確傳遞給正確的人來處理。因此，我們需要引入 Grafana OnCall，來專注解決告警通知的精準度問題。通過架構設計，我們可以將 Prometheus Alertmanager 的告警事件進一步轉發到 Grafana OnCall，以實現更細緻的待命通知管理。

在告警事件的通知升級流程中，我們可以根據不同情境設定最合適的通知對象，並確保如果某個通知人員無法回應或處理問題，告警將自動升級到下一個待命人員。此外，我們可以為每個待命人員預定義通知管道，支持多種方式，包括電話、郵件、簡訊、Slack 和 Webhook 等，確保在告警事件發生時，能夠以最合適的方式將通知傳遞到相關人員。

這種待命通知整合帶來了以下幾個優勢：

• 精確通知，避免告警疲勞：通過細緻的通知設計，告警事件能夠被精確地傳遞給合適的處理者，減少了無關人員收到不必要告警的情況，從而減輕了告警疲勞的問題。
• 自動化升級處理：當第一時間無人回應告警時，系統能夠自動升級到下一個待命人員，確保問題不會因為無回應而被忽略，提高了整體事件處理效率。
• 多管道通知：針對不同的待命人員和不同的場景，我們可以靈活選擇通知管道，確保在每種情況下都能夠迅速通知到對應的負責人員。

通過這樣的設計，我們能夠大幅提高告警事件通知的效率和精確度，確保每個告警事件能夠被迅速且有效地處理，最終提升系統的可維護性和可靠性。

告警事故管理整合

在日常營運中，我們經常會收到來自不同系統的各種告警事件，這些事件可能對業務的運行產生不同程度的影響，並進一步演變成事故。在經驗豐富的團隊中，當每次事故發生後，團隊會詳細記錄事故的發生經過、處理過程及結果，並對其進行深入分析，最終形成一份完整的事故報告。這一過程不僅能夠幫助團隊回顧事故的發生與處理細節，還有助於未來避免類似事件的再次發生，實現持續改進。

事故管理的關鍵在於能夠將待命人員在告警處理過程中的寶貴經驗和知識進行系統性地沈澱。這不僅可以幫助提升團隊的應對能力，還能成為公司技術資產的一部分，為日後的事故處理提供參考。

目前，雖然 Grafana 提供的告警事故管理工具 Grafana Incident 還未開源，但這並不意味著告警事故管理必須依賴某一特定工具。更重要的是構建一套完善的事故管理系統。在告警事件的生命週期後段，我們可以利用一些成熟的團隊協作工具來進行事故後的分析與改進工作。常用的工具包括：

• GitHub：我們可以通過 Issues 和 Pull Requests 來記錄和追踪每次事故，並在復盤後提交改進計畫。
• JIRA：JIRA 能夠提供強大的項目管理和事故追蹤功能，幫助團隊有系統地管理事故流程，從報告、分配、處理到結案，每個環節都能清晰記錄。
• Confluence：這是一個團隊知識管理平台，能夠用來撰寫詳細的事故報告，總結事故經驗，並進行知識共享。

透過有效的事故管理系統，管理者只需要專注於經過精煉的事故（Incident）來了解來龍去脈，從而減少告警雜訊和認知負擔，並促進事後分析的精確性。

在典型的告警事件系統中，會產生大量的原始告警事件（Event）。這些事件可能代表不同系統或服務中的各種異常情況，而管理者面臨的挑戰在於如何從這些海量的事件中找出真正需要關注的問題。為了應對這一挑戰，告警事件系統會將屬於同一問題的多個事件進行合併，形成一個更具代表性的告警（Alert）。

然而，即便是這些告警，仍然可能過於頻繁或重複，增加了不必要的認知負擔。因此，進一步的過濾和聚合非常關鍵。通過對告警進行智能化處理，系統可以根據關鍵屬性（如相同的標籤或文本的高相似度）將多個相關的告警合併成單一的 事故（Incident）。這樣，最終通知到管理者的將不再是零散的告警事件，而是一個經過精簡和合併的事故，極大地降低了不必要的打擾。

最後，我們可以將事故（Incident）的處理結果記錄在事故報告中，並進行深入分析，以確保未來能夠避免類似問題的再次發生。

告警事件管理介面整合

在整個 Grafana 告警事件中心 中，我們強調了 Grafana 在告警事件整合管理上的重要角色，從 告警資料來源、告警事件路由、告警通知、告警分析，再到 事故管理。這些方面展示了 Grafana 在告警事件管理上的深入整合與顯著成果。為了進一步提升整體的告警管理流程，我們不僅僅依賴 Grafana 系列產品，還可以通過 Grafana 平台將 Prometheus Alertmanager 的告警設定介面整合進來，實現統一的操作介面。

Prometheus 告警規則

當我們在 Prometheus 的 Datasource 中開啟 Alerting UI 功能後，就能夠在 Grafana 的 Alerting Rule 頁面中看到 Prometheus 的告警規則列表與詳細狀態內容。

Prometheus Alertmanager 告警通知

在 Grafana 的 Notification Policies 頁面中，我們同樣可以透過下拉選單切換到以 Prometheus Alertmanager 為告警資料來源的通知設定介面。

Prometheus Alertmanager 告警靜默

不僅如此，我們還可以透過 Grafana 的告警介面來管理 Prometheus Alertmanager 的告警靜默設定。到此看來，我們已經將 Prometheus Alertmanager 介面中的大部分功能都整合到 Grafana 的告警介面中了。

告警事件中心 IaC 與 GitOps 整合

在經過我個人對於 Grafana 告警事件中心的整合實踐與探索後，最終我選擇使用 Terraform 作為告警事件中心設定管理的終極解決方案。而使用 Terraform 來整合 Prometheus Rule、Grafana Alerting 以及 Grafana OnCall 的各種設定，目地是達成基於 Grafana IaC 並結合 GitOps 的告警設定管理整合。

在這個方案中，我使用 Terraform Kubernetes Provider 來管理 Prometheus 的告警規則，並通過先前章節介紹過的 Terraform Grafana Provider 來配置 Grafana Alerting 和 Grafana OnCall 系統。這樣的架構不僅能讓所有告警相關設定都在同一版本控制系統下統一管理，還能利用 GitOps 流程實現持續的自動化部署與更新，確保整個告警系統始終處於最佳狀態，並且更易於維護與擴展。

結語

在本章節中，我們深入探討了 Grafana 告警事件中心的架構設計與整合實踐。從告警資料來源整合到告警事件路由管理，再到 待命通知管理和事故管理整合，我們看到了 Grafana 生態系統如何為一個完整的告警事件管理流程提供了強大的支持。這些工具不僅能夠簡化監控系統的日常維運，還能提升告警的精準性，減少告警疲勞，最終提升系統的可觀測性與可靠性。

最後，透過 Terraform 實現的 Grafana IaC 與 GitOps 的理念引入告警事件管理，我們實現了對 Prometheus、Grafana Alerting 和 Grafana OnCall 的設定進行基於代碼的統一設定管理。這不僅讓我們能夠透過版本控制系統來追蹤變更，還能利用 GitOps 流程實現持續的自動化部署，確保告警系統隨時保持在最佳狀態。這一整合架構為未來的擴展與維護奠定了良好的基礎，讓告警事件管理變得更加靈活、高效，並具備長期可持續性。