iT邦幫忙

2021 iThome 鐵人賽

DAY 4
0
DevOps

Dev's Ops 啟程系列 第 4

[Day 4] SRE - 保持精簡的監控

  • 分享至 

  • twitterImage
  •  

監控

今天來介紹監控的四個黃金訊號、如何簡化以及如何維護。

四個黃金訊號

  • 延遲
  • 流量
  • 錯誤
  • 飽和度

延遲

請求的結果分兩種
成功的請求與失敗的請求
「慢」的錯比「快」的錯還要糟糕。


流量

  • 以Web Server來說,此監控訊號通常主要為同時請求數量。

  • 以串流服務來說,可以能為網路速度或同時連線數。

  • 而以DB來說可能次每秒寫入量或每秒讀取量。


錯誤

請求失敗率有分

  • 顯式失敗 ex: http code 500

    顯式失敗通常可以直接在負載平衡器上監控得到。

  • 隱式失敗 ex: http code 200,但有回錯誤內容

    隱式失敗需要服務寫log或者有log收集機制 ex: stackdriver, ELK ... 才能完全偵測得到。
    而策略因素所致的失敗率搜集監控也可與隱式失敗同樣的做法。

  • 策略因素所致的失敗 ex: 超過3秒內就算請求失敗的請求失敗


飽和度

自己服務系統的飽和度代表依照目前你的硬體以及設定的環境參數等,還可以承受多少。換句話說以現在疫情來說一家餐飲店的內用人數要符合規定又可以正常服務客人的人數可以多少,就代表那一家店的目前飽和度有多少。

如果設定監控的這四個指標在服務異常時,都沒有觸發異常警報的話,就需要全面檢討是否在哪個監控設定的指標內需要重新思考。

簡化

在監控系統時簡化是非常重要的,監控系統可能會變得越來越複雜,最後導致難以變更不好維護。
要記住下列原則:

  • 可預測性強,可靠性高

  • 不常用的資料或設定要定時清除

  • 只收集訊息,但沒在監控儀表板上,發送警報的規則,應該要定時清除。

依照以上的原則

維護

監控系統應該要與你的硬體、軟體、整個環境一同改變,當警報觸發,就應該要去查找根源解決問題,
如果無法完全根除,那麼這個警報的處理就要列SOP並嘗試著自動化。

大家可以慢慢體會,監控的重點在於訊號、簡化、以及維護。/images/emoticon/emoticon07.gif


上一篇
[Day 3] SRE - Log寫好一點,對團隊好一些
下一篇
[Day 5] SRE - 發動測試左移之術,預視未來的機制
系列文
Dev's Ops 啟程30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言