哈囉，大家好歡迎來到我們 30 天實戰之旅的最後一天！

在昨天的 Day 29，我們成功地設定了 Grafana 的告警規則，讓系統具備了「判斷問題」和「知道要通知誰」的能力。但我們在 Contact Point 中留下的，還只是一個 placeholder Webhook URL。

今天，我們就要來完成這最後、也最酷的一步：串接 LINE Messaging API，打造一個不僅能主動推播告警，甚至能與我們進行簡單互動的告警機器人！

Part 1：為何是 LINE Messaging API？LINE Notify 不行嗎？

熟悉 LINE 的朋友可能會問，為什麼不用更簡單的 LINE Notify？
LINE Notify 只需要一組 Token，就能輕鬆地推播訊息。但在 2025 年 3 月，LINE 官方終止了透過 Webhook 方式串接 LINE Notify 的服務。

因此，要打造一個專業的告警機器人，我們必須使用功能更強大的 LINE Messaging API，目前需要到 Line Official Account 去做註冊。註冊的名稱和信箱等資訊之後都還可以再做修改，比較重要的是會拿到 Channel Access Token和 Channel Secrets ，這在等一下的步驟會詳細介紹。

Part 2：架構概覽：為何需要一個「Webhook 中介服務」？

下一個問題是：「為什麼 Grafana 不能直接將告警發送到 LINE Messaging API？」中間還要透過 Webhook 呢？答案在於格式不相容與功能缺失：

1. 格式不相容：Grafana 發出的 Webhook 告警，有其固定的 JSON 格式。而 LINE Messaging API 接收訊息時，期望的是另一套完全不同的 JSON 格式。
2. 認證缺失：LINE API 要求所有請求，都必須在 HTTP 標頭中帶上 Authorization: Bearer <Channel Access Token>。Grafana 的預設 Webhook 無法輕易地加入這個動態的認證標頭。
3. 缺乏回應端點：為了實現「雙向互動」（例如，我們在 LINE 中回覆「狀態」，機器人就回報系統健康度），我們需要一個公開的、能接收來自 LINE 伺服器訊息的 Webhook 端點。Grafana 本身無法扮演這個角色。在我們的專案中，Webhook 是一個用 Flask (Python) 撰寫的輕量級 Web 服務。

Part 3：準備工作

1. 建立帳號：前往 LINE Official Account Manager 建立一個官方帳號，這就是你的機器人本體。

2. 進入開發者後台：前往 LINE Developers Console，建立一個新的 Provider 和一個 Messaging API Channel。
3. 取得關鍵憑證：在 Channel 設定頁面，你會找到兩個最重要的憑證：
   • Channel access token：這是我們的 Webhook 服務用來主動發送訊息給 LINE 的「鑰匙」。
   • Channel secret：這是我們的 Webhook 服務用來驗證收到的訊息是否真的來自 LINE 的「密碼」。

Part 4：打造 Webhook 中介服務

我們的 Flask Webhook 服務，至少需要兩個 API 端點：

1. /push (接收來自 Grafana 的告警)：
   • 這個端點是對內的，只有 Grafana 會呼叫它。
   • 它的工作是：接收 Grafana 發來的 JSON 告警 -> 解析內容 -> 組裝成 LINE API 能看懂的訊息格式 -> 使用 Channel access token，將訊息推播出去。
2. /callback (接收來自 LINE 的訊息)：
   • 這個端點必須是對外公開的，我們要將它的網址填回 LINE Developer Console 的 Webhook URL 設定中。
   • 它的工作是：
     • 驗證簽章：LINE 在發送訊息時，會在 HTTP 標頭中附帶一個簽章。我們的服務必須使用 Channel secret，對收到的訊息內容進行相同的 HMAC-SHA256 運算，並比對簽章是否一致，以確保訊息不是偽造的。
     • 處理訊息：如果驗證通過，我們就可以解析使用者傳來的訊息，再將結果回傳給使用者。

Part 5：整合一切：將 Webhook 部署到 K8s

這一步，正是我們整個系列所學知識的集大成！

1. 容器化 (Day 5)：為我們的 Flask 應用撰寫 Dockerfile。
2. CI/CD (Day 19-22)：設定 .gitlab-ci.yml，讓 Pipeline 自動：
   • 執行測試。
   • 使用 Kaniko 將 Flask 應用建置成 Docker Image。
   • 將 Image 推送到我們的 Harbor 私有倉庫。
   • 使用 Helm 將這個 Webhook 服務部署到 K8s 叢集中。
3. 注入設定 (Day 12)：在 CI/CD Variable 設定 Channel access token 和 Channel secret 作為 K8s Secrets，安全地注入到 Webhook Pod 中。
4. 對外暴露 (Day 15/24)：將 Webhook 服務的 /callback 端點，安全地暴露到我們在 GoDaddy 等地方購買的公開網域名稱上。

Part 6：串接 Grafana 與 Microsoft Teams

串接 Grafana

現在，我們只需要回到 Day 29 建立的 Contact Point，將 URL 修改為我們 Webhook 服務的內部 K8s Service 位址即可！

與 Microsoft Teams 的對比

串接 Teams 相對簡單許多，不過當初找這條 URL 也是找很久！
首先建立 Channel ，點擊右上角三個點點的地方，選擇 「管理頻道」> 連接器 > Incoming Webhook，Create 後它就會直接給你一條 URL。

將這條 URL 貼到 Grafana 的 Webhook Contact Point 中，就完成了！

這篇是我鐵人賽系列的最後一篇，努力趕在國慶連假前結束了挑戰 🥳 
感謝一路以來的閱讀與支持，如果你也正在走在雲原生的學習路上，願這系列能成為你的一點幫助與參考。下次見！👋