Day 6 我們已經完成第一條告警規則：

server01
CPU > 90%
持續 5 分鐘
↓
Firing

到這裡，Grafana 已經可以判斷 Server 是否出現異常。

但還有一個問題。

如果沒有人打開 Grafana，其實還是不會知道告警發生了。

所以今天要做的事情很單純：

當 Alert 進入 Firing 時，把通知主動送出去。

這次先使用 Discord Webhook 當作測試通知管道。

主要原因很簡單：設定不複雜，也很適合拿來驗證整個告警流程。

今天要完成的流程

昨天我們做到：

server01
↓
Node Exporter
↓
Prometheus
↓
Grafana
↓
Alert Rule
↓
Firing

今天再多接最後一段：

server01
↓
Prometheus
↓
Grafana
↓
CPU > 90%
↓
Firing
↓
Discord
↓
收到通知

今天不增加新的監控項目。

先讓目前這一條 CPU Alert 可以真的送到我們手上。

Step 1：準備 Discord Webhook

先準備一個 Discord Server，建立一個專門接收監控通知的頻道。

例如：

#server-alert

進入該頻道的設定，找到 Webhook 功能，建立一組 Webhook。

完成後會取得一個 Webhook URL。

格式大概像：

https://discord.com/api/webhooks/...

這組網址等於是這個通知頻道的入口。

所以：

Webhook URL 不要公開，也不要直接放進 GitHub。

如果未來程式需要使用，可以另外放到環境變數或設定檔中。

Step 2：建立 Grafana Contact Point

接著回到 Grafana。

找到：

Alerting → Contact points

建立新的 Contact Point。

名稱可以先設定：

Discord-Server-Alert

Integration 選擇：

Discord

接著把剛才取得的 Webhook URL 貼進去。

設定完成後，可以先使用 Grafana 提供的：

Test

測試通知。

如果 Discord 收到測試訊息，就代表：

Grafana
↓
Discord Webhook
↓
Discord Channel

這段已經成功。

Step 3：讓 Alert 使用這個通知管道

有 Contact Point 之後，還需要告訴 Grafana：

哪些告警要送到哪裡？

這就是 Notification Policy 的工作。

進入：

Alerting → Notification policies

把目前的 CPU Alert 指向：

Discord-Server-Alert

這樣當告警進入 Firing 時，就會送到 Discord。

目前整體流程變成：

Server01 High CPU
↓
Firing
↓
Notification Policy
↓
Contact Point
↓
Discord
Step 4：先測試通知

設定完成後，我不建議馬上故意讓 Server CPU 跑到 90%。

先用 Grafana 的 Test 功能確認：

Grafana
↓
Webhook
↓
Discord

有沒有正常。

如果 Discord 收到類似：

Test alert

Alerting
Grafana TestAlert

代表基本通知功能正常。

這樣如果後面真正 Alert 沒有收到通知，就可以把問題縮小到 Alert Rule 或 Notification Policy，而不是一開始什麼都一起查。

Step 5：測試真正的 Alert

接下來才測試我們 Day 6 建立的：

Server01 High CPU

原本條件是：

CPU > 90%
持續 5 分鐘

但實驗時其實沒有必要真的等 CPU 跑到 90%。

可以暫時把測試門檻降低。

例如：

CPU > 20%
持續 1 分鐘

這樣比較容易讓 Alert 進入：

Normal
↓
Pending
↓
Firing

當 Grafana 判斷為 Firing 之後，Discord 就應該收到通知。

收到第一封真正的告警

如果設定都正常，Discord 上應該會收到類似：

[FIRING]

Server01 High CPU

Instance:
192.168.1.101:9100

Status:
Firing

這時候整個流程才算真的串起來。

因為現在已經不是：

我打開 Grafana，才發現 CPU 有問題。

而是：

CPU 發生異常，系統主動來找我。

Alert 恢復正常後呢？

告警不只是要通知「發生問題」。

恢復正常也很重要。

例如：

CPU 95%
↓
Firing
↓
收到通知

後來 CPU 降回：

CPU 35%

Grafana 會把 Alert 從：

Firing

恢復成：

Normal

通知系統也可以告訴我們：

[RESOLVED]

Server01 High CPU

這樣維運人員才知道：

剛才的異常現在已經恢復。

不然只有「出問題」的通知，卻不知道什麼時候恢復，其實也會造成困擾。

不要讓告警變成另一種垃圾訊息

做到這裡，我也開始覺得告警有一個問題需要注意。

假設設定：

CPU > 70%

而 Server 平常就很容易超過 70%。

結果可能一天收到幾十次：

High CPU
High CPU
High CPU
High CPU
High CPU

久了最大的可能不是 Server 被修好。

而是：

大家開始不看告警。

所以 Threshold 不是設定得越敏感越好。

真正要考慮的是：

什麼狀況
+
持續多久
+
是否真的需要人處理

這三件事情。

這也是後面慢慢增加 Memory、Disk 等規則時，我會繼續注意的地方。

Day 7 完成

今天沒有增加新的監控項目。

我們只把 Day 6 的 Alert 往後接了一步：

Prometheus
↓
Grafana
↓
Alert Rule
↓
Firing
↓
Contact Point
↓
Discord

完成：

✓ 建立 Discord Webhook
✓ 建立 Grafana Contact Point
✓ 設定 Notification Policy
✓ 測試告警通知
✓ 收到 Firing 通知
✓ 確認 Resolved 狀態

到 Day 7 為止，我們已經完成最基本的：

監控 → 判斷異常 → 主動通知

這其實已經是一套最基本的監控告警流程。

接下來的問題

現在收到的通知大概還是：

Server01 High CPU
CPU > 90%
Status: Firing

它告訴我們：

有問題。

但它還沒有回答：

為什麼會有問題？

例如 CPU 95%，接下來維運人員還是要登入 Server，再去確認：

哪個 Process 在吃 CPU？
Memory 是否也異常？
最近有沒有 Error Log？
Service 是否正常？

所以接下來，我想開始讓自己的程式加入這套流程。