週二安安，今天進到了 SRE 方法論的第三條：監控系統，這裡是今天讀的原文出處：Introduction，話不多說，我們開始囉！

書中提到一個監控系統裡會有三類輸出：

• 緊急警報（Alert）
  • 收到警報的用戶需要立即處理，解決已發生或有可能發生的問題。
  • 例如：收到網站的 health check 不健康，意味著服務中斷，應該立即處理。
• 工單（Ticket）
  • 需要人力介入的操作，但不一定要立即處理。
  • 例如：部分使用者操作不慎，系統也沒有預想到這個狀況，於是跳出錯誤內容。
• 日誌（Logging）
  • 日誌詳細記錄所有資訊，通常會在 debug 或是事後分析的時候使用。
  • 這裡提到日誌記錄不需要主動去調閱，僅在有需要的時候才去翻閱。

復盤時間

如果對應到現今 GCP 提供的服務，會像下面這樣：

• Alert → 在 Monitoring 下的 Alerting
• Ticket → Error Reporting
• Logging → Logging

Alerting

在 Alerting 的部分，在 GCP 上我有兩個設置的方法，第一個是從 Alerting 的頁面去 Create Policy，裡面可以選擇各種 Metric 來當作標準。

第二種方法是透過 Logging 介面，先篩選出需要的 Log，並製作自定義的 Log-based Alerts

Error Reporting

目前對 Error Reporting 的使用還不多，不過目前的規劃是會希望把 Error Reporting 串接 ClickUp（我們的文件服務），觸發 ClickUp 的創建文件通知給開發團隊！讓開發團隊可以依照一張一張卡片去修復，並記錄相關事故報告。

由於 ClickUp 也有內建通知管道，只要修改或移動，也都能通知到團隊，真的很方便！

Logging

真心覺得 Logging 很好用！！！雖然上面提到如果沒有需要，其實可以不用特別去翻閱，不過由於現在我做的告警還沒有那麼完整，因此在 Logging 裡面瞎逛的時候，常常會有一些意外發現！

在使用的時候比較少直接使用上面那一個方框，雖然有提示詞可以使用很方便，不過由於這個專案的服務不算多，所以反而使用左側的選單會更快速的找到我想看的資料！

後記

今天加上了一些目前有使用到的功能，不過在翻閱資料的時候也迸發了一些新的想法，可能之後也會應用在系統上，接下來是應急事件的處理！那麼就明天見拉！掰噗！