當前位置：首頁 > 编程语言 > java >内容正文

java

java github_GitHub Research：超过50％的Java记录语句写错了

發布時間：2023/12/3 java 46 豆豆

生活随笔收集整理的這篇文章主要介紹了 java github_GitHub Research：超过50％的Java记录语句写错了小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

java github

為什么生產日志無法幫助您找到錯誤的真正根本原因？

詢問您是否使用日志文件監視您的應用程序幾乎就像詢問…您是否喝水。我們都使用日志，但是我們如何使用它們則是一個完全不同的問題。

在下面的文章中，我們將對日志進行更深入的研究，并了解日志的使用方式和寫入的內容。我們走吧。

我們的研發團隊對Aviv Danziger表示了極大的幫助，感謝他為我們提供和處理數據的巨大幫助。

基礎

我們尋求答案需要大量數據，因此我們選擇了Google BigQuery。幾個月前，我們首次使用它來查看GitHub的頂級Java項目如何使用logs 。

對于我們當前的帖子，我們在GitHub上排名前40萬的Java存儲庫中，按它們在2016年獲得的星級排名進行排名。在這些存儲庫中，我們過濾掉了Android，示例項目和簡單的測試器，從而為我們提供了15797個存儲庫。

然后，我們提取了包含100多個日志記錄語句的存儲庫，這給我們留下了1,463個存儲庫。現在，是時候為所有使我們徹夜難眠的問題找到答案的時候了。

TL; DR：主要要點

如果您不喜歡餅圖，柱形圖或條形圖，并且想跳過主要課程而直接進入甜點，那么以下是我們了解的關于日志記錄及其實際操作的5個關鍵點：

1.日志實際上并沒有我們想像的那么多，即使它們每天最多可以增加數百GB。超過50％的語句沒有有關應用程序可變狀態的信息
2.在生產中，禁用了全部日志記錄語句的64％
3.達到生產狀態的日志記錄語句的變量比平均開發水平的日志記錄語句少35％ 4. “永遠不要發生” 5.有一種更好的方法來解決生產中的錯誤

現在，讓我們用一些數據備份這些點。

1.多少個記錄語句實際上包含變量？

我們要檢查的第一件事是每個語句中發出了多少個變量。我們選擇在每個存儲庫中按從0個變量到5個及以上的比例對數據進行切片。然后，我們對總數進行了統計，并對研究中所有項目的平均細分情況有所了解。

按變量數計算的平均Java項目

如您所見，普通的Java項目不會在其日志記錄語句的50％以上記錄任何變量。我們還可以看到，只有0.95％的日志記錄語句發出5個或更多變量。

這意味著日志所捕獲的有關應用程序的信息有限，而找出實際發生的情況可能就像在日志文件中搜索針頭一樣。

2.生產中激活了多少個記錄語句？

開發和生產環境有所不同，原因有很多，其中之一就是它們與日志記錄的關系。在開發中，所有日志級別均已激活。但是，在生產中僅會激活ERROR和WARN。讓我們看看這種故障的樣子。

生產與開發日志

該圖表顯示，普通的Java應用程序具有35.5％的唯一日志記錄語句，這些語句有可能在生產中被激活（ERROR，WARN），以及64.5％的語句僅在開發中被激活（TRACE，INFO，DEBUG）。

大多數信息丟失。哎喲。

3.每個日志級別的平均變量數是多少？

因此，開發人員不僅會跳過語句中的變量，而且普通的Java應用程序首先不會向生產日志發送那么多的語句。

現在，我們決定分別查看每個日志級別，并計算相應語句中變量的平均數量。

每個記錄語句的平均變量數

平均值表明，TRACE，DEBUG和INFO語句比WARN和ERROR包含更多的變量。考慮到前三個變量的平均數量為0.78，后兩個變量為0.5，“更多”是一個禮貌的單詞。

這意味著生產日志記錄語句所包含的變量比開發日志記錄語句所包含的變量少35％。另外，正如我們前面所看到的，它們的總數也要低得多。

如果要在日志中搜索有關您的應用程序發生了什么的線索，但空白處–這就是為什么它發生的原因。不用擔心，有更好的方法。

通過OverOps ，您可以查看任何異常，記錄的錯誤或警告背后的變量，而不必依賴實際記錄的信息。您將能夠在事件的整個調用堆棧中查看完整的源代碼和變量狀態。即使未將其打印到日志文件中。 OverOps還會向您顯示在錯誤之前在生產中記錄的250個DEBUG，TRACE和INFO級別的語句，即使它們已關閉并且從未到達日志文件。

我們很樂意向您展示其工作原理，請點擊此處安排演示。

4.這永遠不會發生

由于我們已經掌握了所有這些記錄語句的信息，因此我們決定從中獲得一些樂趣。我們發現有58條提及“這絕不應該發生”。

我們只能說，如果它永遠不會發生，則至少要有一個體面才能打印出一個變量或2，因此您將能夠看到它為什么仍會發生＆＃55357;＆＃56898;

我們是如何做到的？

正如我們提到的，要獲取此數據，我們首先必須過濾掉無關的Java存儲庫，并專注于擁有100多個日志記錄語句的存儲庫，這給我們留下了1,463個可以減少使用的存儲庫。

然后，我們添加了一些正則表達式魔術，并拔出了所有日志行：

現在我們有了數據，我們開始對其進行切片。首先，我們篩選出每個日志級別的變量數量：

SELECT sample_repo_name,log_level,CASE WHEN parametersCount + concatenationCount = 0 THEN "0"WHEN parametersCount + concatenationCount = 1 THEN "1"WHEN parametersCount + concatenationCount = 2 THEN "2"WHEN parametersCount + concatenationCount = 3 THEN "3"WHEN parametersCount + concatenationCount = 4 THEN "4"WHEN parametersCount + concatenationCount >= 5 THEN "5+"END total_params_tier,SUM(parametersCount + concatenationCount) total_params,SUM(CASE WHEN parametersCount > 0 THEN 1 ELSE 0 END) has_parameters,SUM(CASE WHEN concatenationCount > 0 THEN 1 ELSE 0 END) has_concatenation,SUM(CASE WHEN parametersCount = 0 AND concatenationCount = 0 THEN 1 ELSE 0 END) has_none,SUM(CASE WHEN parametersCount > 0 AND concatenationCount > 0 THEN 1 ELSE 0 END) has_both,COUNT(1) logging_statements,SUM(parametersCount) parameters_count,SUM(concatenationCount) concatenation_count,SUM(CASE WHEN isComment = true THEN 1 ELSE 0 END) comment_count,SUM(CASE WHEN shouldNeverHappen = true THEN 1 ELSE 0 END) should_never_happen_countFROM [java-log-levels-usage:java_log_level_usage.top_repos_java_log_lines_no_android_no_arduino_attributes] GROUP BY sample_repo_name,log_level,total_params_tier

然后計算每個層的平均使用量。這就是我們獲得總存儲庫語句的平均百分比的方式。

SELECT total_params_tier,AVG(logging_statements / total_repo_logging_statements) percent_out_of_total_repo_statements,SUM(total_params) total_params,SUM(logging_statements) logging_statements,SUM(has_parameters) has_parameters,SUM(has_concatenation) has_concatenation,SUM(has_none) has_none,SUM(has_both) has_both,SUM(parameters_count) parameters_count,SUM(concatenation_count) concatenation_count,SUM(comment_count) comment_count,SUM(should_never_happen_count) should_never_happen_countFROM (SELECT sample_repo_name,total_params_tier,SUM(total_params) total_params,SUM(logging_statements) logging_statements,SUM(logging_statements) OVER (PARTITION BY sample_repo_name) total_repo_logging_statements,SUM(has_parameters) has_parameters,SUM(has_concatenation) has_concatenation,SUM(has_none) has_none,SUM(has_both) has_both,SUM(parameters_count) parameters_count,SUM(concatenation_count) concatenation_count,SUM(comment_count) comment_count,SUM(should_never_happen_count) should_never_happen_countFROM [java-log-levels-usage:java_log_level_usage.top_repos_java_log_lines_no_android_no_arduino_attributes_counters_with_params_count]GROUP BY sample_repo_name,total_params_tier)WHERE total_repo_logging_statements >= 100GROUP BY total_params_tierORDER BY 1,2

您可以在我們的原始數據文件中查看計算結果。

最后的想法

我們都使用日志文件，但是似乎大多數人都認為它們是理所當然的。有了眾多的日志管理工具，我們忘記了控制我們自己的代碼-并使它對于我們理解，調試和修復很有意義。

翻譯自: https://www.javacodegeeks.com/2017/02/github-research-50-java-logging-statements-written-wrong.html