2019-03 服務日志級別調(diào)研

一、日志分級的定義（摘錄）

1. 文林福寫的wiki中提到

log的主要目的：便于觀察線上服務是否正常冀膝、數(shù)據(jù)統(tǒng)計窝剖、問題跟進。
log打印的基本原則：簡明扼要疙描。在能清楚表達所要打印的信息的情況下起胰，越短越好。主要是log打印太多會提高存儲火俄、傳輸和分析的代價

log分級：

  debug：用于調(diào)試時打印的信息，上線時需要關(guān)閉玻熙，如果是前期需要觀察線上數(shù)據(jù)，可以臨時打開一段時間枚尼，一個請求可以打多條記錄

  INFO：記錄非常重要的信息，一個請求可以打印1-3條（一般開始1條盯质，結(jié)束一條），能合并的盡量合并朵逝。記錄請求的id、請求類型晋辆，做了什么事情瓶佳、結(jié)果、狀態(tài)厚脉、時間等（根據(jù)自己需要）。log合并的好處是在數(shù)據(jù)分析和統(tǒng)計的時候可以在1條log中獲取所有的信息鸯匹，而信息打印在不同的log記錄中，需要做合并操作科雳，會非常麻煩。此外無論請求成功了還是失敗了尿赚，都需要打一條INFO log，用狀態(tài)碼區(qū)分就行

  WARN：警告日志冰寻，出現(xiàn)了預期之外的信息，但是程序不影響程序運行的划乖。比如：傳遞過來的圖片解碼失敗

  FATAL: 致命錯誤日志：類似磁盤空間不夠了，分配內(nèi)存和端口失敗這種

2. 王健的知乎專欄：最佳日志實踐

FATAL — 表示需要立即被處理的系統(tǒng)級錯誤。這屬于最嚴重的日志級別（必須慎用）庆寺，通常一個進程的生命周期中應該只記錄一次FATAL級別的日志这橙，即該進程遇到無法恢復的錯誤而退出時。
ERROR — 當ERROR錯誤發(fā)生時鹰晨，需要立即處理——表示已經(jīng)影響了用戶的正常訪問，但服務沒有掛掉忍疾。這種級別的日志屬于服務錯誤，而不是用戶自己操作不當，請求參數(shù)錯誤等等士复。
WARN — 該日志表示系統(tǒng)可能出現(xiàn)潛在問題。這個級別表明不需要立即處理澄峰，但也是需要查看并處理的绸硕。因此此種級別的日志也不應太多出嘹。
INFO — 該種日志記錄系統(tǒng)的正常運行狀態(tài)烦秩，例如某個子系統(tǒng)的初始化，某個請求的成功執(zhí)行等等抛寝。通過查看INFO級別的日志，可以很快地對系統(tǒng)中出現(xiàn)的 WARN,ERROR,FATAL錯誤進行定位钻趋。INFO日志不宜過多，通常情況下土至，INFO級別的日志應該不大于TRACE日志的10%垂蜗；
DEBUG or TRACE — 作用是對系統(tǒng)每一步的運行狀態(tài)進行精確的記錄烘苹。可以保證在不重現(xiàn)錯誤的情況下廊鸥，也可以通過DEBUG（或TRACE）級別的日志對問題進行診斷。

3. stackoverflow回答 - Hansaka perera

Trace - Only when I would be "tracing" the code and trying to find one part of a function specifically.

Info - Generally useful information to log (service start/stop, configuration assumptions, etc). Info I want to always have available but usually don't care about under normal circumstances. This is my out-of-the-box config level.

Warn - Anything that can potentially cause application oddities, but for which I am** automatically recovering**. (Such as switching from a primary to backup server, retrying an operation, missing secondary data, etc.)

Error - Any error which is fatal to the operation, but not the service or application (can't open a required file, missing data, etc.). These errors will force user (administrator, or direct user) intervention. These are usually reserved (in my apps) for incorrect connection strings, missing services, etc.

Fatal - Any error that is forcing a shutdown of the service or application to prevent data loss (or further data loss). I reserve these only for the most heinous errors and situations where there is guaranteed to have been data corruption or loss.

4. stackoverflow回答 - Peter Mortensen

Would you want the message to get a system administrator out of bed in the middle of the night?

yes -> error

no -> warn

+ 引用

文林福 涉及公司內(nèi)容啦吧，鏈接隱去

王健 - https://zhuanlan.zhihu.com/p/27363484

stackoverflow問題

二顾犹、正確的對待日志的方式

1. 不斷優(yōu)化日志

源自 - 王健

好的日志就像好的文章一樣，絕不是一遍就可以寫好的，而需要在實際的運維過程中顾彰，結(jié)合線上問題的定位，不斷地進行優(yōu)化厕隧。最關(guān)鍵的一點是，團隊要重視日志優(yōu)化這件事情，不要讓日志的質(zhì)量持續(xù)降低翎朱。

好的實踐：

在定位問題的過程中完善日志，如果定位問題花費了很長時間，那就說明系統(tǒng)日志還存在問題蕉汪，需要進一步完善和優(yōu)化；
需要思考是否可以通過優(yōu)化日志驹马，來提前預判該問題是否可能發(fā)生;
定義好整個團隊記錄日志的規(guī)范，保證每個開發(fā)記錄的日志格式統(tǒng)一；定期對日志內(nèi)容進行Review胖秒；

2. 對現(xiàn)狀做一個個人評價

根據(jù)上述的一些結(jié)論，發(fā)現(xiàn)team的代碼：

fatal級別：基本上API服務的處理較好，panic俯邓、runtime-errorr這類問題并不會直接服務重啟，而是會被中間代碼兜住并打出一個error級日志朦蕴，符合預期赴恨；RPC服務未確認雨饺，似乎大多數(shù)沒有做很好的兜底饺窿，也沒有導致服務崩潰時的fatal日志。
error：現(xiàn)狀是非常隨意，一些不會引發(fā)接口錯誤糠排、次要的字段、無需立即處理的問題乾闰，往往不合預期就被打上一條error日志。使tce上線時經(jīng)常上得驚心動魄，提示出現(xiàn)嚴重錯誤硫朦，很不友好。
warn：基本符合預期，對非重要功能的調(diào)用失敗祷舀、參數(shù)錯誤箕宙、打上warning
info：有一些意義不明的內(nèi)容打上了info（到底是想要作為業(yè)務warn還是一條trace哟忍？）
trace：用得較少，可以通過CtxPushNotice把鍵值對塞進這個級別中爆安，用于追蹤請求細節(jié)咖耘。

總結(jié)來說版保，還有不少進步空間。

- 引用