打日誌的注意事項

打日誌的方法

• 日誌級別 日誌級別

  • error: 表示程序運行出現了錯誤，這種日誌打出來之後，須要開發或運維人員進行處理的。特別的這裏特指是本身寫的程序出現錯誤，若是是別人傳參傳錯了這種，不該該報error，記錄下來就能夠了。由於一來這不是程序自己出現了問題，二來着也會致使日誌過多。能夠試想一個場景，若是有error報出來，運維就須要去檢查，那麼這個問題自己應該給運維馬上去檢查嗎，這能夠做爲衡量的一個標準。
  • warn: 程序出現了錯誤，可是這個錯誤自己不影響正常運行。好比超時，網絡緣由，以及上面提到的參數錯誤。當warn不少的時候，就須要開發人員去檢查。這裏傳參錯誤我也推薦打warn，若是大量出現這宗錯誤，那麼開發人員就須要進行檢查。
  • info: 其實應該理解到，info並非重要的日誌。它的做用不是告訴你程序運行出現了什麼問題，而是告知你程序運行的信息，好比某個關鍵節點的成功，某些特殊數據。它是用來在出現問題時候進行輔助判斷的日誌，或者你能夠用它來做爲程序出現問題甩鍋的依據。
  • debug: 開發時候須要打的各類信息，通常線上不會打這個級別的日誌，個人debug日誌基本上是開發的時候想怎麼打怎麼打，後續會大量刪除，保留一部分關鍵的debug日誌，當線上出現問題須要更進一步細節的話，能夠嘗試把debug打開看一看。
  • trace：跟蹤程序的推動，我以爲能夠不用打這個級別的日誌，方法就是。。。忘記這個日誌級別。。。

• 日誌的可追溯性

  • 用logid追蹤，logid能夠是外部傳過來的，若是不傳，能夠本身生成。作上下文關聯用的，就是串聯一次請求日誌的惟一標誌，timestamp其實就能夠。在分佈式環境下各個併發的日誌混雜在一塊兒，若是不達標記，日誌可讀性就比較差了。
  • 也有callid，remoteaddress等等。

• 日誌的內容

  • 日誌的內容要看能不能經過這條日誌看出來這一步作了什麼事情，包括但不限於：上下文日誌的關係（是否能夠追溯）logid，對應哪一個請求，關鍵參數是什麼，錯誤信息，關鍵結果的記錄（能夠打在info裏面），程序運行成功失敗的標記，運行狀態：包括一些簡單的計時記錄。咱們要認識到，未來分析日誌的時候可能須要經過這些標記進行頻率，正確率，tps，qps等數據的統計。
  • 性價比問題，日誌若是某個信息方便打出來，信息量比較大，幫助比較大的話，就應該添加上去；相對的，好比說圖片的base64，完整的request等等打出來就要慎重，由於它實在太大了，不適合放在日誌裏面
  • 日誌格式的一致性，可讀性。要注意到分析日誌的時候在一大堆日誌裏面找須要的東西，很容易看花眼，因此格式要固定，要易讀。另外應該爲一些字段放置一些標誌，這能夠幫助在後期使用grep命令來分析。另外，大小寫一致，還有我發現用[]來包圍變量，可讀性明顯好一點。
  • 日誌打在了哪一個函數哪一個文件時間等等，應該用日誌模塊自動生成。本身的經驗來看，手動標記極其容易犯錯。不可靠。

• 打日誌的位置

  • 這裏提一點，當函數出現錯誤的時候，錯誤日誌其實能夠打在裏層也能夠打在函數外層等等。能夠以這個日誌打在哪一層可以獲取更多信息來決定打在哪裏，有的時候日誌打在外層可以獲取到更多的環境信息，由於有些環境數據無法傳遞到下層函數當中去。 

• 日誌校驗

  • 內容：須要脫離代碼來看日誌，看看這個日提供的信息量是否足夠，特別是在分佈式環境下是否是有意義。
  • 格式：仍是要脫離代碼看日誌，由於實際打印出來的日誌和你經過代碼閱讀想象出來的樣子可能徹底就是不同的。

• 其餘的，須要經驗和不斷完善。很難在開發時候就徹底把日誌打好，有些要踩了坑才知道這個地方要打。我以爲除了一些注意點之外，也沒有肯定的法則，靠經驗積累慢慢養成習慣和風格吧。