"Alerting"
- 4.0 服務端監控的分層：容器與程序的自檢、服務網路內的探測、元件指標、應用層訊號、告警規則與分送、告警鏈的監看與使用者路徑的合成監控
以每一層監控檢查的對象、看不到的範圍與接手的那一層，把服務端監控串成一條監控鏈，以及拿它盤點一個服務時怎麼判讀缺口的性質（檢查範圍、位置、讀取與訊號失真），涵蓋自架主機、Kubernetes 與雲端託管的情形；使用者路徑那一層另寫合成監控與真實使用者監測的差別，以及盤點時各種缺口的補法
- 4.0.1 監控鏈事前偵測不到的異常：業務結果、資料正確性、到期事件、排程與背景工作、備份、安全、第三方依賴與成本的監看
監控鏈各層都正常時仍會發生的幾類異常：業務停了而程式回應正常、資料寫錯、TLS 憑證與網域到期、排程工作與佇列消費端沒跑、備份還原不回來、以帳號正常操作進行的攻擊、第三方業者停掉與帳單失控，各自要先定義的預期、檢查它的規則與承接的專章
- 4.0.4 以監控鏈盤點交易撮合系統：觀察者讀數字的位置、沒有新委託時分辨市場安靜與路徑停住、分段量測延遲，以及委託序號、帳戶部位的對帳與其他監控鏈事前偵測不到的異常
把一個交易撮合系統的監控放進監控鏈的各層判讀缺口：撮合引擎單一執行緒時觀察者為什麼要從輸出日誌讀數字、沒有新委託時怎麼分辨市場安靜還是處理路徑停住、委託延遲怎麼依段量測與時鐘同步的前提、依序日誌多數節點與同一可用區的失效域，以及輸出序號的斷號、帳戶部位與行情資料的一致性這類監控鏈事前偵測不到的異常
- Rule engine 設計
條件 → 動作 → 模板的三段式規則結構 — 讓 collector 從被動儲存變成主動回應
- 服務掛了怎麼自動知道：從肉眼盯到主動告警
不想每次都手動 systemctl 檢查服務死活、想讓機器在 service 掛掉時主動推播通知、或擔心整台機器當掉沒人知道時回來讀
- ntfy：推送通知服務怎麼運作、公共站 vs 自架
用 ntfy 把機器的告警推到手機、想搞懂它是誰維護的開源服務、topic 的安全模型、以及該用公共站還是自架時回來讀
- 查詢消費模式
Debug / Alerting / 產品決策 / 安全審計 / 效能監控 — 五種查詢場景各需要什麼事件、什麼欄位、什麼查詢模式
- DevOps Dashboard 設計
Collector 和 SDK 是否健康 — 日常監控的服務狀態卡、吞吐量曲線、儲存用量，以及告警觸發後的排障視圖
- CloudWatch Alarms 與 Composite Alarms 操作實務
說明 CloudWatch Metric Alarm、Anomaly Detection alarm、Composite Alarm 設計、alarm actions、missing data 處理與 cost 考量
- 4.27 主機過載時的監控告警：可用與變慢分開判斷、依原因抑制、監控自身的等待
多個服務共用一台主機而主機過載時，各服務的探測與告警會一起失敗：可用性與延遲分成兩個判斷的寫法、間歇的條件怎麼持續成立、以主機飽和抑制各服務變慢的規則與它的取捨、以合成告警驗證抑制、抑制藏起各服務受影響程度的差別、探測與 Prometheus 自己也在等 CPU 時的訊號，以及讓監控不比服務先失效的資源隔離；以一次開發環境的過載為例
- 4.29 值班的例行檢查：接班檢查與每週營運會議讀的訊號、交班紀錄的內容，以及例行檢查項目改寫成告警規則的條件
告警刻意不呼叫值班的訊號由值班定時讀：接班時讀上一班的交班紀錄、生效中的告警靜音、只送通知的 warning、error budget 的走向、排程工作與心跳檢查項目、到期事件、容量走向、近期變更與客服單量，各自防的是哪一種情形；交班紀錄要寫的內容；每週營運會議讀的告警雜訊、值班負擔與重複出現的客服回報；以及一個檢查項目什麼時候該改寫成告警規則
- Alert Inhibition（告警抑制）
同一個原因觸發一串症狀告警、值班人員被淹沒，或要在 Alertmanager 寫 inhibit_rules 時，查抑制做什麼、它和分組與靜音的差別、哪些症狀適合被抑制，以及它安靜失效的幾種條件
- Alert Silence（告警靜音）
維護期間要暫停某些告警的通知、或懷疑告警該響而沒響時，查 Alertmanager 的 silence 做什麼、它與抑制及週期性靜音時段的差別、它過期之前會藏住什麼，以及怎麼列出與監看還沒過期的靜音