iT邦幫忙

2021 iThome 鐵人賽

DAY 3
0
DevOps

Dev's Ops 啟程系列 第 3

[Day 3] SRE - Log寫好一點,對團隊好一些

  • 分享至 

  • xImage
  •  

LogSeverity

有在寫Log的人都知道Log需要被分級,而分級對於問題的除錯,是很重要的,當問題發生時可以幫助工程師快速定位。

相信在寫go的人都對logrus不陌生

常見的分級為

  • INFO
  • DEBUG
  • WARN
  • ERROR

本篇文章為大家簡單介紹Google對於Logging文件導覽說明
以下圖表共分為九個等級,Severity越大代表影響越嚴重

NAME Severity 意義
DEFAULT 0 此Log沒被指定Level
DEBUG 100 除錯或者追蹤資訊
INFO 200 例行資訊,例如正在運行的狀態或性能
NOTICE 300 正常但是重要的,像是啟動, 關閉, 或者異動設定
WARNING 400 警告事件可能造成問題
ERROR 500 錯誤事件可能造成問題
CRITICAL 600 關鍵事件會導致更嚴重的問題或中斷
ALERT 700 有人必須立即採取行動
EMERGENCY 800 一個或多個系統已經無法使用

以我們團隊來說,我們透過ELK蒐集LOG監控服務撈並判斷WARNING等級以上的LOG設為警報,直接推送至警報器。

coding的人就要依照log的Level把相關的Log訂好,幫助大家在診斷問題時,提供重要的線索!
通常就是邊coding邊想,如果出問題時,哪些資訊要寫入Log能快速幫助自己找到問題。

再來就是怎麼樣算是好的Log?

  • Level分類明確
  • 訊息易懂
  • 夾帶在Log的訊息,方便Debug

ex: 如果發生程式執行過慢的時候

第一種Log範例

{
    "level":"WARNING",
    "message":"slow log",
    "now_time":"1631239155",
    "severity":400,
    "time":"2021-09-10T01:59:15.113403016Z"
}

第二種Log範例

{
    "level":"WARNING",
    "message":"ping db slow log",
    "api": "/api/ping",
    "func": "ping",
    "now_time":"1631239155",
    "severity":400,
    "time":"2021-09-10T01:59:15.113403016Z"
}

大家可以看一下這兩個Log案例,是不是下方的更讓人了解發生在哪呢?
所以説Log的撰寫也是蠻重要的一課,在幫助大家快速定位問題的時候,是個非常重要的資料。


上一篇
[Day 2] SRE - 你的服務死後不要讓人擔心嘛
下一篇
[Day 4] SRE - 保持精簡的監控
系列文
Dev's Ops 啟程30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言