前言

日志用來(lái)記錄用戶操作、系統(tǒng)運(yùn)行狀態(tài)等，是一個(gè)系統(tǒng)的重要組成部分。然而由于日志并非系統(tǒng)核心功能，通常情況下并不受團(tuán)隊(duì)的重視。在出現(xiàn)問(wèn)題需要通過(guò)日志來(lái)定位時(shí)，才發(fā)現(xiàn)日志還存在很多問(wèn)題。 日志記錄的好壞直接關(guān)系到系統(tǒng)出現(xiàn)問(wèn)題時(shí)定位的速度，同時(shí)可以通過(guò)對(duì)日志的觀察和分析，提前發(fā)現(xiàn)系統(tǒng)可能的風(fēng)險(xiǎn)，避免線上事故的發(fā)生。 我們?cè)陂_發(fā)和運(yùn)維NOS（網(wǎng)易對(duì)象存儲(chǔ)，Netease Object Storage）的過(guò)程中，對(duì)整個(gè)系統(tǒng)的日志進(jìn)行了分析優(yōu)化，積累出一些經(jīng)驗(yàn)，歸納如下。

相關(guān)問(wèn)題經(jīng)驗(yàn)整理

1. 關(guān)于日志級(jí)別

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

TRACE - The TRACE Level designates finer-grained informational events than the DEBUG 
DEBUG – The DEBUG Level designates fine-grained informational events that are most useful to debug an application. 
INFO - The INFO level designates informational messages that highlight the progress of the application at coarse-grained level. 
WARN - The WARN level designates potentially harmful situations. 
ERROR - The ERROR level designates error events that might still allow the application to continue running. 
FATAL - The FATAL level designates very severe error events that will presumably lead the application to abort. 

盡管log4j官方文檔對(duì)各個(gè)日志級(jí)別進(jìn)行了簡(jiǎn)單定義。然而在實(shí)踐中，究竟哪些操作需要記入日志，哪種錯(cuò)誤應(yīng)該記為WARN級(jí)別，而哪種錯(cuò)誤又為ERROR級(jí)別，還需要進(jìn)行進(jìn)一步討論。

關(guān)于該問(wèn)題，在StackOverflow上有一個(gè)討論貼進(jìn)行過(guò)討論。

此處對(duì)貼子中的一些觀點(diǎn)，加上我們?cè)谄綍r(shí)運(yùn)維過(guò)程中遇到的相關(guān)問(wèn)題進(jìn)行歸納：

• 一個(gè)項(xiàng)目各個(gè)log級(jí)別的定義應(yīng)該是清楚明確的，是每個(gè)開發(fā)人員所遵循的；
• 即使是TRACE或者DEBUG級(jí)別的日志，也應(yīng)該有一定的規(guī)范，要保證除了開發(fā)人員自己以外，包括測(cè)試人員和運(yùn)維人員都可以方便地通過(guò)日志定位問(wèn)題；
• 對(duì)于日志級(jí)別的分類，有以下參考：  

FATAL — 表示需要立即被處理的系統(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ù)；

ERROR — 該級(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ù)?。FATAL相當(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日志的；

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

INFO — 該種日志記錄系統(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%；

DEBUG or TRACE — 這兩種日志具體的規(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ā)生?？梢员ＷC在不重現(xiàn)錯(cuò)誤的情況下，也可以通過(guò)DEBUG（或TRACE）級(jí)別的日志對(duì)問(wèn)題進(jìn)行診斷。需要注意的是，DEBUG日志也需要規(guī)范日志格式，應(yīng)該保證除了記錄日志的開發(fā)人員自己外，其他的如運(yùn)維，測(cè)試人員等也可以通過(guò)DEBUG（或TRACE）日志來(lái)定位問(wèn)題；

Rule 1：整個(gè)團(tuán)隊(duì)（包括運(yùn)維人員）需要對(duì)日志級(jí)別有明確的規(guī)定，什么日志記入什么級(jí)別的日志，什么級(jí)別的錯(cuò)誤出現(xiàn)要如何處理等。

2. 對(duì)記錄的日志要進(jìn)行更新維護(hù)

由于DEBUG（或TRACE）級(jí)別的日志對(duì)于定位問(wèn)題至關(guān)重要，因此該種日志記錄是否完備且不冗余、格式是否規(guī)范等也需要花費(fèi)大量精力來(lái)優(yōu)化。此處有以下幾個(gè)比較好的實(shí)踐：

• 定義好整個(gè)團(tuán)隊(duì)記錄DEBUG（或TRACE）日志的規(guī)范，保證每個(gè)開發(fā)記錄的日志格式統(tǒng)一；
• 整個(gè)團(tuán)隊(duì)（包括開發(fā)，運(yùn)維和測(cè)試）定期對(duì)記錄的日志內(nèi)容進(jìn)行Review；
• 開發(fā)做運(yùn)維，通過(guò)在查問(wèn)題的過(guò)程來(lái)優(yōu)化日志記錄的方式；
• 運(yùn)維或測(cè)試在日志中發(fā)現(xiàn)的問(wèn)題，都需要及時(shí)向開發(fā)人員反映；

Rule 2：需要定期對(duì)日志內(nèi)容進(jìn)行優(yōu)化更新，目的就是通過(guò)日志快速準(zhǔn)確的定位問(wèn)題

3. 關(guān)于日志分類

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

診斷日志， 典型的有：

• 請(qǐng)求入口和出口
• 外部服務(wù)調(diào)用和返回
• 資源消耗操作: 打開文件等
• 容錯(cuò)行為： 譬如云硬盤的副本修復(fù)操作
• 程序異常： 譬如數(shù)據(jù)庫(kù)無(wú)法連接
• 后臺(tái)操作：清理程序
• 啟動(dòng)、關(guān)閉、配置加載
• 拋出異常時(shí)，不記錄日志

統(tǒng)計(jì)日志：

• 用戶訪問(wèn)統(tǒng)計(jì)
• 計(jì)費(fèi)日志（如記錄用戶使用的網(wǎng)絡(luò)資源或磁盤占用，格式較為嚴(yán)格，便于統(tǒng)計(jì)）

審計(jì)日志：

• 管理操作

將不同需求的日志記入到不同的日志文件中，可以方便相關(guān)問(wèn)題（管理平臺(tái)操作審計(jì)，用戶操作計(jì)費(fèi)等）的處理。針對(duì)每一種需求，需要對(duì)日志的格式，日志記錄的內(nèi)容等進(jìn)行特別的記錄。

Rule 3：要明確不同日志的用途，對(duì)日志內(nèi)容進(jìn)行分類

4. 日志中不要記錄無(wú)用信息

在很多應(yīng)用中，用戶都需要通過(guò)Fuse方式來(lái)掛載使用NOS。

POSIX標(biāo)準(zhǔn)中文件系統(tǒng)接口不允許文件 /a 與目錄 /a/ 同時(shí)存在，而NOS作為對(duì)象存儲(chǔ)系統(tǒng)，/a 和 /a/ 是不同的對(duì)象，是能夠同時(shí)存在的，一般地，NOS 中我們會(huì)規(guī)定 /a/ 是目錄，/a 是文件，目錄對(duì)象大小為0。

POSIX標(biāo)準(zhǔn)對(duì)文件的getattr操作，無(wú)論是 /a 還是 /a/，對(duì)應(yīng)的請(qǐng)求都是 /a。為了避免遺漏，需分別向 NOS 請(qǐng)求 HeadObject(“/a“)和 HeadObject(“/a/“)。如果命中/a，說(shuō)明 /a 是一個(gè)文件，不用再請(qǐng)求 getattr(“/a/“)。

因此當(dāng)用戶訪問(wèn) */a/b/c.txt* 時(shí)，實(shí)際上向NOS發(fā)送了以下請(qǐng)求：

# HeadObject(“/a”) 
# HeadObject(“/a/”) 
# HeadObject(“/a/b”) 
# HeadObject(“/a/b/”) 
# HeadObject(“/a/b/c.txt”) 

對(duì)于上面的請(qǐng)求，實(shí)際上HeadObject(“/a”)和HeadObject(“/a/b”)都會(huì)返回NoSuchKey錯(cuò)誤，而Fuse正是該錯(cuò)誤來(lái)判斷該文件不存在，而可能是個(gè)目錄的。

然而對(duì)于NOS來(lái)說(shuō)，這將導(dǎo)致產(chǎn)生大量無(wú)意義的NoSuchKey日志（整個(gè)日志文件的80%都是該錯(cuò)誤日志）。這些日志對(duì)于開發(fā)人員進(jìn)行日志觀察，運(yùn)維人員定位問(wèn)題，日志監(jiān)控等都造成了困難。

Rule 4: 絕不要打印沒有用的日志，防止無(wú)用日志淹沒重要信息

解決辦法：Fuse請(qǐng)求時(shí)，在Http頭部加入 User-Agent 字段，當(dāng)NOS發(fā)現(xiàn)請(qǐng)求是 Fuse發(fā)過(guò)來(lái)的且為HeadObject操作且為NoSuchKey錯(cuò)誤時(shí)，則不打印錯(cuò)誤日志。

5. 日志記錄信息要完整

問(wèn)題描述：

NOS提供分塊上傳的接口，用戶可以通過(guò)以下的調(diào)用序列，來(lái)實(shí)現(xiàn)一次分塊上傳的流程：

• InitMultiUpload（生成一個(gè)UploadID）
• UploadPart
• UploadPart
•  ……
• UploadPart
• CompleteMultiUpload（AbortMultiUpload）

之前在某個(gè)產(chǎn)品上線初期，由于其開發(fā)人員對(duì)NOS的熟悉程度不夠等原因。出現(xiàn)過(guò)如下問(wèn)題：客戶端常常會(huì)收到NoSuchUpload的錯(cuò)誤。該錯(cuò)誤出現(xiàn)的原因是，用戶在未調(diào)用InitMultiUpload之前，或者在調(diào)用了CompleteMultiUpload（AbortMultiUpload）之后再次調(diào)用UploadPart。

然而當(dāng)我們查日志，希望可以看到該UploadPart請(qǐng)求對(duì)哪個(gè)UploadID進(jìn)行操作，該UploadID又對(duì)應(yīng)哪些操作時(shí)，卻發(fā)現(xiàn)我們的日志中沒有記錄UploadPart請(qǐng)求對(duì)應(yīng)的UploadID。

類似的問(wèn)題還有很多，很多針對(duì)特定請(qǐng)求的日志缺失，導(dǎo)致很多問(wèn)題無(wú)法定位。

因此，需要進(jìn)一步對(duì)日志中需要記錄哪些內(nèi)容進(jìn)行規(guī)定，此處推薦的需要在日志中記錄的內(nèi)容有：

• 在系統(tǒng)啟動(dòng)或初始化時(shí)記錄重要的系統(tǒng)初始化參數(shù)
• 記錄系統(tǒng)運(yùn)行過(guò)程中的所有的錯(cuò)誤
• 記錄系統(tǒng)運(yùn)行過(guò)程中的所有的警告
• 在持久化數(shù)據(jù)修改時(shí)記錄修改前和修改后的值
• 記錄系統(tǒng)各主要模塊之間的請(qǐng)求和響應(yīng)（如在NOS中的視頻處理模塊在接收到請(qǐng)求和發(fā)送應(yīng)答時(shí)，或者向客戶端發(fā)送回調(diào)請(qǐng)求時(shí)）
• 重要的狀態(tài)變化（如NOS中對(duì)系統(tǒng)白名單的修改等）
• 系統(tǒng)中一些長(zhǎng)期執(zhí)行的任務(wù)的執(zhí)行進(jìn)度

而不推薦記錄日志的內(nèi)容有：

• 函數(shù)入口信息 —— 除非該函數(shù)入口表示了一個(gè)重要事件的開始，或者將該信息記入DEBUG級(jí)別日志
• 文件內(nèi)容或者一大段消息的內(nèi)容 —— 如果實(shí)在需要記錄，則可以截取其中一些重要的信息來(lái)記入日志
• “良性”錯(cuò)誤 —— 有時(shí)候雖然出現(xiàn)了錯(cuò)誤，然而錯(cuò)誤處理的流程可以正確解決這種情況，例如插入數(shù)據(jù)庫(kù)時(shí)有重復(fù)的記錄，盡管是個(gè)錯(cuò)誤，然而錯(cuò)誤處理流程可以對(duì)這種情況進(jìn)行處理

Rule 5：日志信息要準(zhǔn)確全面，能做到僅憑日志就可以定位問(wèn)題

解決辦法：整理所有的請(qǐng)求處理流程，針對(duì)每一個(gè)操作（去重，分塊上傳……）打印特定的日志。

6. 測(cè)試的日志

測(cè)試代碼（單元測(cè)試，接口測(cè)試……）的日志同樣重要。特別是，當(dāng)一個(gè)測(cè)試失敗時(shí)，可以通過(guò)日志很快確定是測(cè)試代碼有問(wèn)題，還是系統(tǒng)出現(xiàn)了故障，如果做不到這一點(diǎn)，那就需要優(yōu)化測(cè)試的日志了。

測(cè)試日志應(yīng)該包含以下內(nèi)容：

• 測(cè)試執(zhí)行的環(huán)境
• 測(cè)試執(zhí)行前的初始狀態(tài)
• 測(cè)試的詳細(xì)步驟
• 測(cè)試和系統(tǒng)的交互信息
• 測(cè)試期望的返回結(jié)果
• 測(cè)試實(shí)際的返回結(jié)果

Rule 6：要以同樣嚴(yán)格的要求對(duì)待測(cè)試程序的日志

7. 從問(wèn)題中完善日志

在線上出現(xiàn)問(wèn)題的時(shí)候，需要盡快發(fā)現(xiàn)問(wèn)題并解決，而同時(shí)，需要借此機(jī)會(huì)好好思考一下當(dāng)前系統(tǒng)的日志是否合理。需要考慮以下問(wèn)題：

• 如果定位問(wèn)題花費(fèi)了很長(zhǎng)時(shí)間，那就說(shuō)明系統(tǒng)日志還存在問(wèn)題，需要進(jìn)一步完善和優(yōu)化
• 需要思考是否可以通過(guò)優(yōu)化日志，來(lái)提前預(yù)判該問(wèn)題是否可能發(fā)生（如某種資源耗盡而導(dǎo)致的錯(cuò)誤，可以對(duì)資源的使用情況進(jìn)行記錄）

通過(guò)系統(tǒng)出現(xiàn)的問(wèn)題來(lái)優(yōu)化日志，應(yīng)該是一項(xiàng)長(zhǎng)期的實(shí)踐，不斷地從日志發(fā)現(xiàn)系統(tǒng)的問(wèn)題，不斷地從系統(tǒng)異常發(fā)現(xiàn)日志的問(wèn)題。

Rule 7：日志的優(yōu)化是一件持續(xù)不斷需要投入精力的事，需要不斷從錯(cuò)誤中學(xué)習(xí)

8. 關(guān)于RequestID

RequestID的生成：

如今NOS有8臺(tái)機(jī)器，共40個(gè)tomcat對(duì)外提供服務(wù)。通常用戶在請(qǐng)求出錯(cuò)的時(shí)候，我們都希望用戶告訴我們請(qǐng)求的RequestID，以此我們可以確定請(qǐng)求是在哪臺(tái)機(jī)器上進(jìn)行處理的。

NOS通過(guò)以下信息生成一個(gè)請(qǐng)求的RequestID：

• 收到請(qǐng)求的時(shí)間
• 處理請(qǐng)求的服務(wù)器ip地址
• 隨機(jī)數(shù)

因此我們可以通過(guò)一個(gè)簡(jiǎn)單的程序從RequestID中得到該請(qǐng)求的處理時(shí)間和處理請(qǐng)求的服務(wù)器地址，更方便的去查看日志：

 ./decode.sh 4b2c009a0a7800000142789f42b8ca96
 Thu Nov 21 11:06:12 CST 2013
 10.120.202.150
 4b2c009a

Rule 8：在RequestID中盡量編碼更多的信息

用RequestID將請(qǐng)求的處理流程關(guān)聯(lián)起來(lái)：

在NOS性能測(cè)試中，之前存在的一個(gè)問(wèn)題是，由于在打印錯(cuò)誤堆棧的地方，并沒有打印請(qǐng)求的RequestID，因此當(dāng)一個(gè)請(qǐng)求出現(xiàn)錯(cuò)誤時(shí)，很難（日志量太大）將該請(qǐng)求的錯(cuò)誤堆棧和具體的請(qǐng)求關(guān)聯(lián)起來(lái)。

另一個(gè)問(wèn)題是，NOS后端有視頻服務(wù)器集群和圖片處理服務(wù)器集群。因此我們可能會(huì)有以下需求：當(dāng)用戶視頻截圖失敗時(shí)，用戶會(huì)告訴我們請(qǐng)求的RequestID，由于NOS并沒有將該RequestID轉(zhuǎn)發(fā)到后端的圖片處理服務(wù)器，因此無(wú)法利用該信息去查看視頻處理服務(wù)器上的日志，而需要通過(guò)用戶請(qǐng)求的URL進(jìn)行查找。同時(shí)，由于我們無(wú)法知道該請(qǐng)求是在哪個(gè)具體的視頻處理的worker上進(jìn)行，進(jìn)一步導(dǎo)致查找日志的困難。

還有一個(gè)潛在的問(wèn)題是：如果NOS將所有的日志收集起來(lái)（tomcat，圖片處理集群，視頻處理集群……），我們無(wú)法做到通過(guò)requestID來(lái)查找一個(gè)請(qǐng)求的處理流程。

Rule 9：將一個(gè)請(qǐng)求的整個(gè)處理流程和唯一的requestID關(guān)聯(lián)起來(lái)

9. 關(guān)于線上機(jī)器的日志級(jí)別

問(wèn)題描述：

NOS的DEBUG日志非常詳細(xì)的記錄了請(qǐng)求處理相關(guān)信息，然而由于DEBUG日志量太大，因此通常線上只開INFO級(jí)別日志。然而INFO級(jí)別的日志卻有可能導(dǎo)致部分問(wèn)題無(wú)法定位。NOS線上一個(gè)請(qǐng)求可能隨機(jī)地分發(fā)到4臺(tái)機(jī)器進(jìn)行處理，因此如果某一種錯(cuò)誤在一段時(shí)間內(nèi)多次出現(xiàn)，它也會(huì)在4臺(tái)服務(wù)器上都出現(xiàn)。

因此我們推薦的做法是，選擇一臺(tái)機(jī)器開啟DEBUG級(jí)別的日志，方便定位問(wèn)題。其實(shí)該做法背后的目的是，在線上任何問(wèn)題的時(shí)候，都可以通過(guò)日志最快的找到問(wèn)題的根源。

Rule 10：讓一臺(tái)機(jī)器開啟DEBUG日志

10. 上線后的日志觀察

隨著NOS開始服務(wù)越來(lái)越多的產(chǎn)品，NOS每次版本升級(jí)之后，通過(guò)對(duì)日志的觀察來(lái)確定服務(wù)是否正常變得至關(guān)重要。同時(shí)在上線新功能時(shí)，來(lái)發(fā)人員需要通過(guò)觀察一些特定的日志，來(lái)確定新功能是否工作正常。

舉例來(lái)說(shuō)：

NOS在實(shí)現(xiàn)了桶表緩存的功能之后，首先上線一臺(tái)服務(wù)器，并對(duì)該功能是否工作正常進(jìn)行觀察。通過(guò)將桶緩存的所有操作（如插入，查找，過(guò)期刪除等）以及桶緩存的狀態(tài)（如緩存桶數(shù)量）都記錄在DEBUG級(jí)別的日志中。將新上線的機(jī)器的日志級(jí)別調(diào)為DEBUG，并對(duì)桶緩存的相關(guān)操作是否正確，緩存桶數(shù)量等信息進(jìn)行觀察，確認(rèn)一切正常之后再上線其他機(jī)器。

Rule 11：新上線服務(wù)器后一定要對(duì)日志進(jìn)行觀察，特別地，開發(fā)人員可以通過(guò)觀察日志來(lái)確認(rèn)新功能是否工作正常

11. 慢操作日志

NOS在接收到一個(gè)請(qǐng)求的時(shí)候，會(huì)記錄請(qǐng)求的接收時(shí)間（T1），在請(qǐng)求處理完成待發(fā)送的時(shí)候，會(huì)記錄請(qǐng)求發(fā)送時(shí)間（T2），通常一個(gè)請(qǐng)求的日志都記為INFO級(jí)別，然而當(dāng)出現(xiàn)請(qǐng)求處理時(shí)間（T2-T1）超過(guò)一定時(shí)間（如10s）時(shí)，會(huì)將該日志提升為WARN級(jí)別。通過(guò)該方法，可以預(yù)先發(fā)現(xiàn)系統(tǒng)可能存在的一些問(wèn)題。

同樣的慢操作日志還可以用來(lái)記錄系統(tǒng)一些外部依賴的處理時(shí)間，如NOS依賴外部認(rèn)證服務(wù)器來(lái)進(jìn)行認(rèn)證。我們會(huì)記錄每個(gè)請(qǐng)求的認(rèn)證時(shí)間，如果認(rèn)證時(shí)間超過(guò)某個(gè)值，也需要將該事件的日志級(jí)別進(jìn)行提升，這樣我們可以盡早發(fā)現(xiàn)認(rèn)證服務(wù)器是不是需要擴(kuò)容等問(wèn)題。

慢日志的時(shí)間閥值應(yīng)該是可以動(dòng)態(tài)調(diào)整的，這樣在進(jìn)行系統(tǒng)優(yōu)化時(shí)，可以將該報(bào)警時(shí)間閥值逐漸調(diào)小，不斷地對(duì)系統(tǒng)進(jìn)行優(yōu)化。

Rule 12：通過(guò)日志級(jí)別的提升來(lái)發(fā)現(xiàn)潛在問(wèn)題

12. 日志報(bào)警

錯(cuò)誤日志報(bào)警：

NOS通過(guò)[運(yùn)維平臺(tái)|https://m.hz.netease.com/]設(shè)置了日志監(jiān)控報(bào)警，周期性的（1分鐘，5分鐘）對(duì)服務(wù)器新產(chǎn)生的日志進(jìn)行監(jiān)控，如果發(fā)現(xiàn)錯(cuò)誤數(shù)超過(guò)某個(gè)閥值，則進(jìn)行報(bào)警。這類報(bào)警通常不一定是我們服務(wù)本身的問(wèn)題，也有可能是用戶使用NOS不當(dāng)造成的。

此處需要注意的問(wèn)題是，日志報(bào)警相當(dāng)于grep操作，如果日志量過(guò)大，或者匹配規(guī)則過(guò)多，可能對(duì)線上的服務(wù)產(chǎn)生影響。因此在設(shè)置好日志報(bào)警后，需要周期性的關(guān)注每次日志掃描的時(shí)間，評(píng)估日志監(jiān)控是否對(duì)服務(wù)產(chǎn)生影響。

Rule 13：對(duì)日志進(jìn)行監(jiān)控報(bào)警，比客戶先發(fā)現(xiàn)系統(tǒng)問(wèn)題

關(guān)鍵字報(bào)警：

NOS為每個(gè)用戶分配了一定量的存儲(chǔ)配額，當(dāng)用戶容量超限時(shí)，會(huì)限制用戶的上傳操作。通過(guò)在日志中記錄關(guān)鍵字，如“Quota Warning”等，可以及時(shí)提醒用戶進(jìn)行擴(kuò)容，避免用戶服務(wù)中斷。

類似的關(guān)鍵字報(bào)警還有很多：如對(duì)InternalError的數(shù)量進(jìn)行監(jiān)控，對(duì)緩存的桶數(shù)量進(jìn)行監(jiān)控等等。

Rule 14：通過(guò)日志中的關(guān)鍵字來(lái)確定系統(tǒng)的運(yùn)行狀態(tài)

13. 關(guān)于日志格式

日志格式一定要統(tǒng)一，不能任由開發(fā)人員的喜好來(lái)。舉例來(lái)說(shuō)，對(duì)于NOS視頻截圖超時(shí)的ERROR日志，有以下幾種方式打印：

***種：

logger.error(“Gearman timeout exception for request ” + getRequestID() + ” value: ” + value, e); 

第二種：

logger.error(“RequestID: ” + getRequestID() + “, Error Message: Gearman timeout exception: ” + e); 

第三種：

logger.error(getErrorMessage(getRequestID(), getErrorMessage(), e)); 

***種方式打印日志即是開發(fā)人員按照自己的喜好來(lái)的，這種方法帶來(lái)的問(wèn)題是：

• 系統(tǒng)中日志格式不統(tǒng)一，不利于自動(dòng)化處理
• 有些日志可能只有開發(fā)人員自己才能看懂
• 代碼規(guī)范性不好

而第三種方式，通過(guò)一個(gè)函數(shù)來(lái)規(guī)范日志格式，所有開發(fā)人員便可以通過(guò)該接口實(shí)現(xiàn)統(tǒng)一的日志。

Rule 15：日志格式要統(tǒng)一規(guī)范

14. 錯(cuò)誤日志輸出到不同文件

在性能測(cè)試中遇到的另一個(gè)問(wèn)題是，當(dāng)并發(fā)量很大時(shí)，可能會(huì)有一些請(qǐng)求處理失?。ㄈ?.5%），為了對(duì)這些錯(cuò)誤進(jìn)行分析，需要去查這些錯(cuò)誤請(qǐng)求的日志。而由于這種情況下并發(fā)量很大，使得對(duì)錯(cuò)誤日志的分析變得困難。

這種情況下可以將所有的錯(cuò)誤日志同時(shí)輸出到一個(gè)單獨(dú)的文件之中。

Rule 16：將錯(cuò)誤日志輸出到一個(gè)單獨(dú)的文件中進(jìn)行分析

15. 關(guān)于日志文件大小

日志文件不宜過(guò)大，過(guò)大的日志文件對(duì)于日志監(jiān)控，問(wèn)題定位等都會(huì)帶來(lái)不便。因此需要進(jìn)行日志文件的切分，日志文件的切分可以通過(guò)log4j等日志工具來(lái)配置，日志文件應(yīng)該按天來(lái)分割，還是按照小時(shí)來(lái)分割，應(yīng)該根據(jù)日志量來(lái)決定，原則就是方便開發(fā)或運(yùn)維人員能快速查找日志。

為了防止日志文件將整個(gè)磁盤空間占滿，需要定期對(duì)日志文件進(jìn)行刪除。例如，在收到磁盤報(bào)警時(shí)，可以將兩個(gè)月以前的日志文件刪除。此處比較好的實(shí)踐是：

• 將所有日志文件收集起來(lái)，這樣即使在記錄日志的機(jī)器上刪除，也可以通過(guò)收集的日志對(duì)之前的問(wèn)題進(jìn)行定位；
• 每天通過(guò)定時(shí)任務(wù)來(lái)刪除過(guò)期日志，如每天在凌晨4點(diǎn)刪除60天前的日志

log4j關(guān)于日志切分的相關(guān)配置，可以參考這篇文章。

Rule 17：要把日志的大小，如何切分，如何刪除等作為規(guī)范建立起來(lái)

經(jīng)驗(yàn)匯總

此處對(duì)以上總結(jié)的所有經(jīng)驗(yàn)進(jìn)行匯總：

• 整個(gè)團(tuán)隊(duì)（包括運(yùn)維人員）需要對(duì)日志級(jí)別有明確的規(guī)定，什么日志記入什么級(jí)別的日志，什么級(jí)別的錯(cuò)誤出現(xiàn)要如何處理等
• 需要定期對(duì)日志內(nèi)容進(jìn)行優(yōu)化更新，目的就是通過(guò)日志快速準(zhǔn)確的定位問(wèn)題
• 要明確不同日志的用途，對(duì)日志內(nèi)容進(jìn)行分類
• 絕不要打印沒有用的日志，防止無(wú)用日志淹沒重要信息
• 日志信息要準(zhǔn)確全面，努力做到僅憑日志就可以定位問(wèn)題
• 要以同樣嚴(yán)格的要求對(duì)待測(cè)試程序的日志
• 日志的優(yōu)化是一件持續(xù)不斷需要投入精力的事，需要不斷從錯(cuò)誤中學(xué)習(xí)
• 在RequestID中盡量編碼更多的信息
• 將一個(gè)請(qǐng)求的整個(gè)處理流程和唯一的requestID關(guān)聯(lián)起來(lái)
• 讓一臺(tái)機(jī)器開啟DEBUG日志
• 新上線服務(wù)器后一定要對(duì)日志進(jìn)行觀察，特別地，開發(fā)人員可以通過(guò)觀察日志來(lái)確認(rèn)新功能是否工作正常
• 通過(guò)日志級(jí)別的提升來(lái)發(fā)現(xiàn)潛在問(wèn)題
• 對(duì)日志進(jìn)行監(jiān)控報(bào)警，比客戶先發(fā)現(xiàn)系統(tǒng)問(wèn)題
• 通過(guò)日志中的關(guān)鍵字來(lái)確定系統(tǒng)的運(yùn)行狀態(tài)
• 日志格式要統(tǒng)一規(guī)范
• 將錯(cuò)誤日志輸出到一個(gè)單獨(dú)的文件中進(jìn)行分析
• 要把日志的大小，如何切分，如何刪除等作為規(guī)范建立起來(lái)

參考文獻(xiàn)

[1]  ”Optimal Logging” Anthony Vallone from Google

http://googletesting.blogspot.jp/2013/06/optimal-logging.html 

原文鏈接：http://www.bitstech.net/2014/01/07/log-best-practice/