從上一篇提到的《軟件學報》上的綜述文章開始，這段時間順著引用又陸續(xù)看了一些日志管理方面的論文。這里摘錄一些論文的數(shù)據(jù)和結(jié)論，還都挺有意思的。

---

Examining the stability of logging statements?pdfs.semanticscholar.org

分析了activemq、cloudstack等4個著名的apache開源項目。發(fā)現(xiàn)：

20%-45%的打日志代碼，后續(xù)變更過；且初次變更的時間點一般在代碼添加以后的17天內(nèi)；

在選取的14個特征值中，對打日志代碼是否會變更，影響較大的特征值主要是：開發(fā)人員的經(jīng)驗、源文件長度、日志語句占源文件的比例。

top3的開發(fā)人員，負責了全部打日志代碼的50%以上。而且這3個人寫的打日志代碼，70%以上后續(xù)不用再修改。

如果一個源文件里75%以上內(nèi)容是同一個開發(fā)人員寫的，那他寫的打日志代碼后續(xù)基本不會再改了。

不過，這篇論文的出發(fā)點，是建立一個分類預測模型，哪些日志代碼后續(xù)不會改的，讓日志分析工具只關(guān)注這些日志的解析處理，減輕運維人員頻繁變更提取規(guī)則的工作量——這個設想是否成立，我個人持懷疑態(tài)度。

---

Studying the characteristics of logging practices in mobile apps: a case study on F-Droid?users.encs.concordia.ca

分析了F-Droid平臺上的1444個開源安卓應用代碼，發(fā)現(xiàn)：

平均每479行代碼里有一行是打日志，這個比例遠低于服務端程序的情況。

34%的日志是Debug級別，27%是Error級別。這個比例遠高于服務端程序的情況。

35.4%的日志，其輸出級別和原理含義并不相符——這段似乎是采用調(diào)研而非源碼分析的情況。

---

Studying and detecting log-related issues?das.encs.concordia.ca

分析了HDFS、YARN等大型開源軟件的jira情況，發(fā)現(xiàn)：

78%的情況下，修復打日志代碼的人不是原先寫這行代碼或這段函數(shù)方法的人；

平均一個錯誤的打日志代碼被報bug需要320天，但是修復只需要5天。

此外，論文還利用日志文本的香農(nóng)熵等做了一個log checker，給出是否level合適、log合適等建議。

---

Characterizing logging practices in Java-based open source software projects – a replication study in Apache Software Foundation?www.eecs.yorku.ca

分析了21個java開源程序，也都來自apache基金會。發(fā)現(xiàn)和過去針對C/C++開源程序的論文相比，有一些不同：

出于意料的，報bug時帶了原始日志的平均花17天修復，報bug時沒帶原始日志的反而平均只花14天修復。——如果按類型區(qū)分，服務端程序情況更明顯，客戶端程序還是帶日志的更快點。

帶有日志修改的變更，占代碼變更的比例，服務端程序高達27.3%，客戶端大概18.1%。

---

Log Clustering based Problem Identification for Online Service Systems?www.microsoft.com

從微軟PB級日志環(huán)境得到的幾個特點總結(jié)：

大規(guī)模IT環(huán)境下，因為容錯機制的存在，即使在正常運行狀態(tài)下，也會有大量的kill和fail關(guān)鍵字日志輸出。

相比傳統(tǒng)環(huán)境，互聯(lián)網(wǎng)設施上，相同錯誤會海量重復觸發(fā)(restart優(yōu)先、集群環(huán)境等)。

導致同一種故障的執(zhí)行路徑有很多種。中間會混雜很多正常時期也輸出的日志。

利用日志聚類，在測試環(huán)境得到日志執(zhí)行序列集合，然后和生產(chǎn)環(huán)境的做對比，只關(guān)注有變化的部分，能節(jié)省大概86%~97%的查閱量。2016年的本文，在原先的2013年的方法的基礎上，再加上了Check Recurrence，對已經(jīng)發(fā)生和標記過的故障路徑，可以直接利用。

最后結(jié)果，微軟的一個實例，1kw原始日志，通過關(guān)鍵字搜索命中20w條，通過聚類得到40個序列。

---

Characterizing and Detecting Anti-patterns in the Logging Code?nemo9cby.github.io

分析activemq、hadoop、maven的源碼，找出不合理的日志代碼。并以此模型工具，向top10的開源項目提交了學習出來的問題，有72%被最終接受了（其中，jEdit作者否決了所有問題，表示別拿你們的工具結(jié)論來打擾我）。

之前多數(shù)分析日志代碼優(yōu)化的，都集中在在what、where to log，本文研究的是how to log。首先要基于how的目的，人工分析日志代碼的變更分類，得到如下總結(jié)：

基于這個人工總結(jié)，設計了一個工具做自動分析，能分析源碼中的5類日志代碼bug：

引用了可能為null的參數(shù)

可能出錯的類型顯式轉(zhuǎn)換

和內(nèi)容文本不符合的日志等級，比如文案寫debug，級別卻是INFO。

日志代碼壞味道，包括：相同目的用更長名字的方法、明明有本地變量了還再調(diào)用一次方法等

畸形輸出，比如缺少tostring等。

---

Log2: A Cost-Aware Logging Mechanism for Performance Diagnosis?www.microsoft.com

Log2是微軟做的一個類似logger或者說log4j一樣的庫，解決whether to log問題。不過優(yōu)化的方向只專注在一個場景，就是為了check某個函數(shù)的處理性能，大家經(jīng)常在調(diào)用這個函數(shù)之前寫一行begin日志，之后寫一行end日志。

同樣有性能監(jiān)控目的，文中提及谷歌在2010的Dapper論文中一個數(shù)據(jù)：當打開全部日志輸出時，谷歌搜索引擎服務的響應時間增加了16.3%，吞吐量下降了1.48%。

微軟亞研為了這個項目，還提前做了一次內(nèi)部的問卷，其實針對IT運維方向的問卷調(diào)查法還挺有意義的。運維關(guān)注的服務質(zhì)量管理本身就有一部分管理學性質(zhì)（雖然管理學領(lǐng)域的服務質(zhì)量管理偏向純服務業(yè)）。

log2的原理其實就是在庫內(nèi)部維護兩層可以動態(tài)調(diào)整的filter。

第一層是針對每個函數(shù)的，根據(jù)歷史數(shù)據(jù)評估這個函數(shù)的end-begin時間大致范圍（主要就是是平均值方差了，這塊量大，要高效），如果新執(zhí)行的情況屬于正常的，其實就可以不記錄日志了。

第二層是總的緩沖隊列，根據(jù)隊列狀況(預定義閾值，比如1s鐘最多刷1KB)，決定flush哪些日志到磁盤（使用增強學習算法做打分，判斷隊列里哪些日志對函數(shù)性能影響大，優(yōu)先打哪些），以及給第一層過濾器發(fā)信號開啟過濾。

其實在有eventid/functionname和duration的前提下，即使不用庫，而是ETL方式，應該也可以運用這套原理。

---

Characterizing the Natural Language Descriptions in Software Logging Statements?pinjiahe.github.io

本文采用自然語言處理技術(shù)研究日志代碼的固定描述文案部分。發(fā)現(xiàn)：

相比于普通的英文文章，日志文案更容易被預測；

但是不同項目之間的N-gram模型是不通用的；

甚至相同項目中，不同源代碼文件之間的N-gram模型大多也是不同的。

---

DLFinder: Characterizing and Detecting Duplicate Logging Code Smells?petertsehsun.github.io

本文分析了Hadoop、CloudStack、ElasticSearch 和 Cassandra 源碼。專門針對重復日志現(xiàn)象。

話說，ES的日志代碼比例還真是偏少啊。

重復日志現(xiàn)象分為5類：

同一個try里不同catch打了一模一樣的日志文案

相同函數(shù)背景和相同文案，用了不同變量

內(nèi)容和函數(shù)不統(tǒng)一

相似場景下，用了不同級別

相同方法的不同實現(xiàn)，用了重復日志。

可以看到，主要就是第3和第5種bug比較多。說白了，就是研發(fā)寫代碼的時候，從別處復制過來，忘了對應改細節(jié)的情況……

總結(jié)

以上是生活随笔為你收集整理的maven的日志在哪里看_日志管理领域研究现状(2)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。