iT邦幫忙

2021 iThome 鐵人賽

DAY 5
1
DevOps

這個 site 就是遜啦 - SRE 30 天登大人之旅系列 第 5

Day 5:淺談警報 (alert) 的設計

前天使用 updown.io 架設了 status page,並且讓它可以在服務無法連上的時候,自動發通知到 slack 頻道。這便算是一種警報,告訴相關人員說,有一些警急狀況需要處理。

然而僅僅這樣是不夠的,畢竟在實際的環境中,可能會遇到各種狀況導致服務出問題,所以若是在意外發生之前,就能提供我們一些資訊的話,就有機會可以更快的解決問題(或是找出潛在的 bug,在他們實際影響到使用者之前就著手進行修復)。

舉個例子來說,以前 NOJ 曾經遇過一個挺蠢的問題,我們沙盒的 log 把硬碟撐爆了,因為當初 log 寫了太多沒用的資訊(像是這個案例就是把題目的 IO 都記錄下來),最終產生了好幾 GB 的 log 檔,加上沒有做 logrotate,導致整台機器掛掉。然而若是有在硬碟快被塞爆之前,就有發出警報的話,或許就可以避免這次悲劇了。

幾個原則

那麼究竟該怎麼判斷什麼時候該發出警報,這就是一個困難的議題,對於每個不同的專案,可能都會有些不同,但還是有些大方向是可以遵守的。

簡化

在實際運行的服務中,我們可能會監控各式各樣的數值,寫了各種規則去表示「某件事情發生了,需要人力介入處理」。然而若是規則太過於複雜的話,可能會造成它難以維護,複雜的規則通常代表著複雜的邏輯,而複雜的邏輯通常也是難以理解的,當服務本身的需求有變更以至於警報的規則要修改時,可能會是一場辛苦的戰鬥。

應當避免誤報

警報的出現意味著需要人力的處理,然而若是警報常常誤報,便會造成類似童話「狼來了」裡面的放羊的小孩一樣,形成警報疲勞,導致真正的問題發生的時候,被忽略掉而沒有處理造成損失。

所以當一個警報它並不需要立即的處理,或是說僅需要一些機械化的操作便可以解決,那麼我們就不應該浪費寶貴的人力去做這些事情,應該要嘗試使用自動化的方法解決它。

明確的處理流程

當一個警報是需要人工處理的,那麼它應當要有明確的處理流程,確保收到通知的當下,我們知道要如何應對。所以在這部分應當留下良好的文件,避免只有少數人清楚流程,而是讓團隊裡的每個人都知道怎麼做。

小結

這個章節我寫一寫才發現...好像應該先討論監控的,畢竟警報是基於監控得到的數值來設立規則的嘛,所以希望明天我有辦法寫一些有關監控系統的架設與設計指標 (metrics) 的討論。

不過這些主題對我來說就算是非常陌生的議題了,若是有不小心寫錯的地方還請各位多多包涵。


上一篇
Day 4:談談 docker 的 restart policy
下一篇
Day 6:監控系統的設計
系列文
這個 site 就是遜啦 - SRE 30 天登大人之旅30

尚未有邦友留言

立即登入留言