小談日志與其實踐

netmou 發(fā)布于2019-06-28 13:39 / 3176人閱讀

摘要：對于日志級別的分類，有以下參考表示需要立即被處理的系統(tǒng)級錯誤。注意日志的切片設(shè)置，以免文件過大不方便操作。過期的日志定期清理。

本文首發(fā)于泊浮目的專欄：https://segmentfault.com/blog...

前言

前陣子在論壇上看到一個問題，大致的意思就是日志該怎么打？或者說是，我們應(yīng)該在日志中打印出哪些內(nèi)容？

看了該問題，筆者真是有所感慨：從實習(xí)到現(xiàn)在，從接的外包小項目到企業(yè)級應(yīng)用，從覺得日志沒什么軟用到在客戶的環(huán)境中排bug在日志中看到蛛絲馬跡。不得不說，日志真是太重要了。

什么是日志

日志文件是用于記錄系統(tǒng)操作事件的記錄文件或文件集合，是一個軟件系統(tǒng)的重要組成部分。一般良好的日志可以幫助我們：

了解項目的運行狀態(tài)

發(fā)現(xiàn)潛在的性能問題

快速定位故障所在

價值化（大數(shù)據(jù)分析等）

.....

日志的分類

就功能來說，我們一般分為診斷日志、審計日志、統(tǒng)計日志。

診斷日志

一般診斷日志包含的信息最為全面，包括但不限于：

Request && Response

系統(tǒng)操作行為：讀寫文件、定時任務(wù)等

異常行為：不可容錯與容錯行為

第三方服務(wù)的調(diào)用

審計日志

記錄賬戶對資源的操作行為。比起診斷日志，可能更加方便普通人的閱讀，運營、運維同志們的福利。

統(tǒng)計日志

用戶訪問統(tǒng)計：瀏覽、日活、IP、上傳下載的數(shù)據(jù)量

計費日志（常見于公有、私有云中）

日志中該記錄什么

先來看看一段ZStack中的日志

2017-09-04 13:37:45,509 TRACE [CloudBusImpl2] {} [msg send]: {"org.zstack.header.host.APIDeleteHostMsg":{"uuid":"e36525b2fbe9429093450b72a4552656","deleteMode":"Permissive","session":{"uuid":"a7c068a7d3fd41388994e4b413cf4f7d"},"timeout":-1,"headers":{"correlationId":"f1ad7d11a73f472ca5dc2ea003f16006","replyTo":"zstack.message.cloudbus.bbaaa63f1b4d4b0cb96e452bf68eaccf","noReply":"false","schema":{},"task-context":{}},"id":"f1ad7d11a73f472ca5dc2ea003f16006","serviceId":"api.portal","createdTime":1504417065507}}

我們可以看到精確的時間，以及日志級別，日志調(diào)用者及其行為，以及參數(shù)。其中correlationId就是我們常說的RequestID。

RequestID:我們通常用RequestID來對請求進行唯一的標記，目的是可以通過RequestID將一個請求在系統(tǒng)中的執(zhí)行過程串聯(lián)起來，這在分布式系統(tǒng)中的威力是巨大的。該RequestID通常會隨著響應(yīng)返回給調(diào)用者，如果調(diào)用出現(xiàn)問題，調(diào)用者也可以通過提供RequestID幫助服務(wù)提供者定位問題。以Java為例，生成方法可以考慮如下：

public static String getUuid() {
      return UUID.randomUUID().toString().replace("-", "");
}

ps:去掉-是為了更方便的copy-paste。

這樣我們便可以利用這個線索在日志中快速的找出問題啦。同時，我們也可以根據(jù)自己的需求來放入時間戳、業(yè)務(wù)屬性等來組成RequestID。

除之前提到的該記錄的日志：

Request && Response

系統(tǒng)操作行為：讀寫文件、定時任務(wù)等

異常行為：不可容錯與容錯行為（比如分布式系統(tǒng)中的心跳機制，請記錄嘗試的次數(shù)）

第三方服務(wù)的調(diào)用

還有：

很少出現(xiàn)的else情況

非預(yù)期執(zhí)行

批量插入操作記錄

服務(wù)狀態(tài)變化（盡有可能記錄線索）

我們也要去掉那些多余的日志，比如：

明明可以一條輸出卻多條輸出（無論從閱讀還是性能上來看都不是較為好的選擇）

為調(diào)試而添加的臨時日志

預(yù)期會被正常處理的異常，卻打出堆棧

等...

關(guān)于日志級別

我們通常使用的日志庫，將日志基本分為以下幾類（從高到低）：

FATAL – The FATAL level designates very severe error events that will presumably lead the application to abort.

ERROR – The ERROR level designates error events that might still allow the application to continue running.

WARN – The WARN level designates potentially harmful situations.

INFO – The INFO level designates informational messages that highlight the progress of the application at coarse-grained level.

DEBUG – The DEBUG Level designates fine-grained informational events that are most useful to debug an application.

TRACE – The TRACE Level designates finer-grained informational events than the

參考帖子：https://stackoverflow.com/que...。

對于日志級別的分類，有以下參考：

FATAL

表示需要立即被處理的系統(tǒng)級錯誤。當該錯誤發(fā)生時，表示服務(wù)已經(jīng)出現(xiàn)了某種程度的不可用，系統(tǒng)管理員需要立即介入。這屬于最嚴重的日志級別，因此該日志級別必須慎用，如果這種級別的日志經(jīng)常出現(xiàn)，則該日志也失去了意義。通常情況下，一個進程的生命周期中應(yīng)該只記錄一次FATAL級別的日志，即該進程遇到無法恢復(fù)的錯誤而退出時。當然，如果某個系統(tǒng)的子系統(tǒng)遇到了不可恢復(fù)的錯誤，那該子系統(tǒng)的調(diào)用方也可以記入FATAL級別日志，以便通過日志報警提醒系統(tǒng)管理員修復(fù)；

ERROR

該級別的錯誤也需要馬上被處理，但是緊急程度要低于FATAL級別。當ERROR錯誤發(fā)生時，已經(jīng)影響了用戶的正常訪問。從該意義上來說，實際上ERROR錯誤和FATAL錯誤對用戶的影響是相當?shù)摹ATAL相當于服務(wù)已經(jīng)掛了，而ERROR相當于好死不如賴活著，然而活著卻無法提供正常的服務(wù)，只能不斷地打印ERROR日志。特別需要注意的是，ERROR和FATAL都屬于服務(wù)器自己的異常，是需要馬上得到人工介入并處理的。而對于用戶自己操作不當，如請求參數(shù)錯誤等等，是絕對不應(yīng)該記為ERROR日志的；

WARN

該日志表示系統(tǒng)可能出現(xiàn)問題，也可能沒有，這種情況如網(wǎng)絡(luò)的波動等。對于那些目前還不是錯誤，然而不及時處理也會變?yōu)殄e誤的情況，也可以記為WARN日志，例如一個存儲系統(tǒng)的磁盤使用量超過閥值，或者系統(tǒng)中某個用戶的存儲配額快用完等等。對于WARN級別的日志，雖然不需要系統(tǒng)管理員馬上處理，也是需要及時查看并處理的。因此此種級別的日志也不應(yīng)太多，能不打WARN級別的日志，就盡量不要打；

INFO

該種日志記錄系統(tǒng)的正常運行狀態(tài)，例如某個子系統(tǒng)的初始化，某個請求的成功執(zhí)行等等。通過查看INFO級別的日志，可以很快地對系統(tǒng)中出現(xiàn)的 WARN,ERROR,FATAL錯誤進行定位。INFO日志不宜過多，通常情況下，INFO級別的日志應(yīng)該不大于TRACE日志的10%；

DEBUG or TRACE

這兩種日志具體的規(guī)范應(yīng)該由項目組自己定義，該級別日志的主要作用是對系統(tǒng)每一步的運行狀態(tài)進行精確的記錄。通過該種日志，可以查看某一個操作每一步的執(zhí) 行過程，可以準確定位是何種操作，何種參數(shù)，何種順序?qū)е铝四撤N錯誤的發(fā)生。可以保證在不重現(xiàn)錯誤的情況下，也可以通過DEBUG（或TRACE）級別的日志對問題進行診斷。需要注意的是，DEBUG日志也需要規(guī)范日志格式，應(yīng)該保證除了記錄日志的開發(fā)人員自己外，其他的如運維，測試人員等也可以通過 DEBUG（或TRACE）日志來定位問題；

其他

注意制定規(guī)范，而不是讓開發(fā)者隨意打日志。對于日志的等級選擇也要注意。

注意日志的切片設(shè)置，以免文件過大不方便操作。

過期的日志定期清理。