問題

這兩天在整理現(xiàn)有模塊的日志格式規(guī)范畜挨，以便于自己團(tuán)隊和其它團(tuán)隊更好的分析目前的產(chǎn)品除盏】羁看了下味混，遺留的問題還真不少，問題主要集中在以下幾點：

日志級別不正確

不是請求粒度的日志打成了NOTICE诫惭，用于排查的日志打成了WARNING翁锡、甚至打成了FATAL。這對于線上模塊監(jiān)控很不利夕土，一方面很難從眾多的WARNING和FATAL日志中找到有價值的信息馆衔，另一方面這些日志多了，難免讓人產(chǎn)生“狼來了”的麻痹心理怨绣。

字段命名不統(tǒng)一

同樣一個參數(shù)角溃，比如說是請求ID，在不同的請求日志中篮撑，有logid减细、log_id、logId各種不同風(fēng)格的寫法赢笨，有的參數(shù)是用[]括起來的未蝌，有的則沒有。這些問題會給日志解析程序帶來很大的負(fù)擔(dān)茧妒。

字段含義不一致

不同請求日志中的參數(shù)A萧吠，在一種請求中表示一種含義（比如觸發(fā)出的商品數(shù)），在其它請求中則表示另一種含義（比如一頁展現(xiàn)的商品數(shù)）桐筏。

日志被公共Lib污染

自己的模塊依賴了其它公共lib纸型，但是公共lib中的日志級別比較隨意，結(jié)果污染了自身模塊日志。

日志信息不足

許多NOTICE日志只打印出了給上游的返回數(shù)據(jù)狰腌，請求數(shù)據(jù)卻不全除破。一些WARNING日志只能看出只在代碼的哪一行出了問題，請求參數(shù)是什么癌别、甚至請求ID皂岔，都沒有。線上出現(xiàn)了問題展姐，很難根據(jù)這條日志找到線索躁垛。

規(guī)范

因此，我們需要對現(xiàn)在的日志格式進(jìn)行專項整治圾笨，總結(jié)出一些合理的教馆、改動盡量小的日志規(guī)范。這兩天和同事討論了下擂达，整理出了一些：

統(tǒng)一字段命名

對于不同請求中的同一含義的字段土铺，只能有一個名字。

統(tǒng)一字段風(fēng)格

字段一律使用xxx_yyy的下劃線命名風(fēng)格板鬓。

統(tǒng)一日志層級風(fēng)格

日志中的信息均通過k=v形式表達(dá)悲敷，kv之間以,分割，表示第一層級俭令；如果v還有第二層級后德，則用_分割；第三層級用|分割抄腔。ex: k1=v111|v112_v21_v22,k2=v2

統(tǒng)一字段順序

統(tǒng)一使用請求ID/服務(wù)名/請求參數(shù)/響應(yīng)數(shù)據(jù)/響應(yīng)時間作為日志字段順序瓢湃。（當(dāng)然，一般公司都有自己的日志工具赫蛇，會將日志級別绵患、時間、線程ID悟耘、函數(shù)落蝙、行號這些打印在最前面。）

日志必須有請求ID

請求粒度的日志中暂幼，必須包含請求ID掘殴；工具類的lib中，對于功能較小的函數(shù)粟誓，無需打日志奏寨；功能點較多的函數(shù)，需將請求ID通過參數(shù)傳遞進(jìn)去鹰服。

只有請求粒度的日志病瞳，才能是NOTICE級別

其它公共lib中的代碼揽咕，需要打到單獨的日志文件中，不和本身模塊的日志混淆套菜。

日志實在是太重要了亲善，一方面反映了用戶的行為，另一方面也反映了模塊的指標(biāo)（召回率逗柴、響應(yīng)時間等）蛹头，怎么規(guī)范它估計都不為過。我們整理的這些規(guī)范也智能算是個迷你版本戏溺。

其實渣蜗，我們制定的這些規(guī)范（以及其它規(guī)范），并沒有誰一開始就能全部想到旷祸，正如TA一開始也想不到會有再上面的問題一樣耕拷。每個人都很自信的認(rèn)為其他人會和TA是一樣的代碼或者日志風(fēng)格，如果所有關(guān)于打印日志的代碼托享，都是由一個人來寫的話骚烧，風(fēng)格想必都是統(tǒng)一的，因為TA知道過去的代碼是什么樣的闰围，為什么需要改成現(xiàn)在這樣赃绊，哪些字段是后來因為什么原因而加上的。如果TA另外也負(fù)責(zé)對日志進(jìn)行解析和統(tǒng)計的話羡榴，那么日志風(fēng)格就會完全統(tǒng)一了碧查。 :P

規(guī)范的制定，從某種意義上講炕矮，也是一種被逼的結(jié)果，因為總會有人最終無法忍受由于種種問題而導(dǎo)致的心智負(fù)擔(dān)者冤，然后說道肤视，“受不了了，我們還是搞個規(guī)范吧涉枫！”

-- EOF --