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

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

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

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

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

了解項(xiàng)目的運(yùn)行狀態(tài)

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

快速定位故障所在

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

.....

就功能來(lái)說(shuō)，我們一般分為診斷日志、審計(jì)日志、統(tǒng)計(jì)日志。

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

Request && Response

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

異常行為：不可容錯(cuò)與容錯(cuò)行為

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

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

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

計(jì)費(fèi)日志（常見(jiàn)于公有、私有云中）

先來(lái)看看一段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}}

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

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

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

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

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

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

Request && Response

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

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

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

還有：

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

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

批量插入操作記錄

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

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

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

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

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

等...

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

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...。

對(duì)于日志級(jí)別的分類，有以下參考：

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

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

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

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

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

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

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

過(guò)期的日志定期清理。