# Alert rule

邏輯如下：

- 建立應用程式
- 想要了解應用程式 → 設計指標（metrics）
- 透過 Alert 持續追蹤應用程式
- 告警觸發 → 放下手邊工作，去處理
- 持續被小抖動告警困擾 → 了解到網路環境是不可能完好無缺的，抖動是必然
- 設計 SLO，去定義「什麼是雜訊」
- 根據 SLO 去設計告警

以下，將會以「根據 SLO 去設計告警」，去尋找好的告警設計。

:::info
我認為SLO 是一個**去雜訊的合約**，觸犯了就一定要去了解或處理，沒觸犯則不一定。

所以即使錯誤率低於 SLO，如果認為這個錯誤的 pattern 很奇怪，仍應該嘗試去解決。
:::

## 假設

- SLO: 99.9%
- Time range: 30d

每三十天結算是否有破壞 SLO 的狀況

:::info
三十天這個時間是可以討論，這邊不細講。

事實上，是每週作為 sliding window size，並以 4 週為 total size 來統計。
:::

### 錯誤率

$錯誤率=\frac{失敗數量}{總數}$

可以是 5xx 請求數除以請求總數，或者 latency 超過 300ms 的請求數除以總數。

## 基礎（一）

很直觀的想法，如果 SLO 是 99.9% 那就抓大於 0.1% 的錯誤：統計 10 分鐘內的錯誤率 > 0.1% 就觸發告警

| Pros | Cons |
| - | - |
| 倒站的偵測速度很快 0.1% x 10m x 60s = 0.6s | 偶爾的 0.1% 也會告警， 然而這只是總體可錯誤量的 0.00002% |
| 每個抵觸 SLO 的事件都會被捕捉 | 每 10 分鐘收到 0.09% 的錯誤持續三十天，也都不會告警 |

precesion 高，recall 低

## 基礎（二）

延伸（一）的想法：既然時間短容易假警報，那就拉長。

統計 36 小時內的錯誤率 > 0.1% 就觸發告警

| Pros | Cons |
| - | - |
| 0.1% x 36h x 60m = 2.16m 就能偵測出倒站的狀況 | 重置時間很長，錯誤修好後要 36 小時才能重置告警 |
| 當出現告警，通常都是真的有問題， 不會有假警報 | 長時間的計算是耗費資源的 |
| - | 小錯誤可能會花很長時間才發現， 例如持續有 0.2% 的錯誤率，需要 18 小時才能發現 |

## 基礎（三）

設計 duration（或者 prometheus 的 [for 參數](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/#rule)）

錯誤持續發生才告警，不建議，因為會忽略斷斷續續的告警。

## 燃燒率

回歸主題，SLO 的意義是去掉雜訊，尋找真正有價值的告警。

這時，就把指標（錯誤率）抽象化，變成：**錯誤預算的耗損**。

:::info
就像 KPI v.s OKR，不要去追逐指標，要追逐結果。

指標只是衡量的工具，SLO 才是本質
:::

例如 SLO 約定每 30 天 99.9% 的可用性，假設三十天會有 1B 的請求 也就是只接受 1M 的請求失敗。這 1M 的請求就代表我們的預算。

如果**每小時**會有 0.1%（或者約 1.4K）的請求失敗，需要持續 30 天才會把這個預算耗損，這時稱他的燃燒率為 1；如果每小時會有 0.2% 的請求失敗，燃燒率則為 2；如果 100% 請求失敗，燃燒率則會 1000，也就是說持續 $\frac{30天}{1000}=43.2\text{min}$ 就會耗盡預算。

反過來計算，如果一個小時內消耗了 5% 的錯誤預算，他的燃燒率為何？

$\frac{\frac{0.001 \times 0.05}{1小時}}{\frac{0.001}{\text{720小時}}}=36$

## 錯誤預算（一）

這時，改成統計 1 小時內的錯誤率超過 5% 的錯誤預算，就會變成：

$\text{錯誤率} > 36 \times 0.001$

| Pros | Cons |
| - | - |
| 根據錯誤預算得出，所以是抽象表達， 代表真正觸犯 SLO的告警 | 小於 36 燃燒率的錯誤永遠不會被觸發 |
| 倒站告警只需 2.16m = 60m * 36 / 1000| 恢復時間需要 ~58m |

## 錯誤預算（二）

多個時間維度

| 預算耗損率 | 時間窗格 | 燃燒率 | 告警類型 |
| ---------- | -------- | ------ | -------- |
| 2% | 1h | 14.4 | on-call |
| 5% | 6h | 6 | on-call |
| 10% | 72h | 1 | JIRA |

不管是長時間地錯誤率，還是短暫高錯誤率，都會被抓出來。


| Pros | Cons |
| - | - |
| 高錯誤率可以快速告警； 低錯誤率最終仍能被抓出 | 更多數字要去關心 |
| 不同狀況不同警報方式 | 72h的重置時間仍很高 |
| | 三個同時觸發會很擾人 |

## 錯誤預算（三）

多因子觸發，加速重置時間

| 預算耗損率 | 時間窗格 | 燃燒率 |
| ---------- | -------- | ------ |
| 2% | 1h **& 5m** | 14.4 |
| 5% | 6h **& 30m** | 6 |
| 10% | 72h **& 6h** | 1 |


## 總結

SLO 不會讓應用程式變得更穩定，但是可以幫助我們用客觀的角度去看應用程式。