前言

只有光頭才能變強。

文本已收錄至我的GitHub倉庫，歡迎Star：https://github.com/ZhongFuCheng3y/3y

記得之前寫過一篇：《阿里巴巴 Java開發手冊》讀后感，之前自學時由于沒怎么接觸過打“日志”，所以《手冊》中的“日志規約”我就先放一邊去了。

而之前寫了一篇：在公司做的項目和自己在學校做的有什么區別？中就有提到：公司的項目不會有e.printStackTrace();這種代碼的存在。因為這打印出來的錯誤信息沒有日期、等級等等，分析起來不方便。

在工作中去服務器上查日志又是一個非常非常常見的操作，所以當初我又寫了一篇 工作中常用到的Linux命令，里邊就談到了查日志時常用的Linux命令。

想著，既然接觸日志也有一段時間了，不妨在回看《手冊》，看看有什么要注意的地方，于是就有了這篇筆記。

一、Java打日志的基礎

以前自己自學的時候，排查問題只會寫下面的代碼：

try?{
???//?doSomething
}?catch?(Exception?e)?{
????e.printStackTrace();
}
----------
//?查看某個數據的值時：
System.out.println(xxxx);

去到公司就發現上面的代碼全不見了，剩下的是：

LOGGER.info("begin?to?run?Java3y:{}",?id);
----
LOGGER.error("excepiton?occurs?when?run?Java3y?{},?exception{}",?id,?e.toString());

如果使用e.printStackTrace();的話，打印在控制的信息分析不方便：

打印在控制的信息分析不方便

而我們將信息分等級和時間記錄在服務器的磁盤上，有問題了就可以根據對應的信息去查找相關的日志(這樣排查起來是十分方便的)：

服務器上的日志信息

我們再來看一下一般的日志長什么樣的：

日志長的是什么樣的

例如：現在有人來反饋某某某用戶好像收不到短信，給出發送時間和用戶ID，我們就可以在日志上找出該用戶在我們系統的發送狀態(例如圖上的：state:81，我們就認為是發送成功狀態)

那么，問題來了，我們在哪打日志？《手冊》上其實已經給出了答案：

謹慎地記錄日志。生產環境禁止輸出 debug 日志；有選擇地輸出 info 日志；如果使

用 warn 來記錄剛上線時的業務行為信息，一定要注意日志輸出量的問題，避免把服務器磁盤

撐爆，并記得及時刪除這些觀察日志。

大量地輸出無效日志，不利于系統性能提升，也不利于快速定位錯誤點。記錄日志時請思考：這些

日志真的有人看嗎？看到這條日志你能做什么？能不能給問題排查帶來好處？

1.1什么叫做 打點 ？

打日志最常見的就是用來打印出程序執行時的相關信息，用于快速定位問題和排查問題。我一開始也是這么理解的，但是其實還可以延伸一下。

我現在搞的那個系統，我們還使用日志在系統的執行鏈路上打點。比如說，我現在要推送一條通知消息，通知消息其實就是下面這種：

這就是通知消息

這個過程大概是如此的：

• 首先別人調用我的RPC提供的接口(或者我自己調用自己的接口)，發現這是一個通知消息。于是我組裝成對應的Task，異步放到消息隊列中

• 另一個系統從消息隊列中取出Task，對這個Task進行業務的處理(比如說是否夜間屏蔽，是否強制發送等等)，然后調用HTTP接口把這個Task交給下游

• 下游做的事其實也很多，整塊鏈路很長(比如要調用SDK的庫，Android和IOS又做不同的處理)

整塊鏈路

而我們又希望在推送完了之后能統計出一些指標(曝光量，點擊率，轉化率)等等。于是乎，就需要在一些關鍵的位置上打一個日志(專業點叫做打點)

在整塊鏈路都打通了以后，將這些點位(日志)收集起來，放到實時流式處理平臺(storm/flink)上清洗/過濾。如果是實時需要用到的放到Redis，離線的放在Hive。

二、手冊規范

2.1 使用門面模式的日志框架

【強制】應用中不可直接使用日志系統(Log4j、Logback)中的 API，而應依賴使用日志框架

SLF4J 中的 API，使用門面模式的日志框架，有利于維護和各個類的日志處理方式統一。

門面模式我之前也寫過一篇筆記：三分鐘學會門面模式！

其實說白了就是希望抽象出一層API，能夠在切換具體日志框架的時候不需要大面積更改。

這個我們可以按學JDBC的時候去理解：

無論我是接入MySQL、Oracle還是SQL Server，但我的接口永遠都是那一套，切換數據庫時不需要更改我的Java API

看了一下公司的項目，采用的是SLF4J+Logback

2.2 調用RPC接口使用Throwable類攔截

【強制】在調用 RPC、二方包、或動態生成類的相關方法時，捕捉異常必須使用 Throwable

類來進行攔截。

之前在排查問題的時候，有個問題死活排不出來，DeBug的時候一直沒進catch模塊。后來我學長就說：“要不你改成Throwable試試？

try?{

}?catch?(Throwable?e)?{

}

我就很疑問，說：“為啥要改成Throwable呢？我們用Exception不就可以捕獲所有的異常了么，Exception是Throwable的一個子類，但Exception已經是包含所有的Java異常了呀”

眾所周知，Throwable有兩個子類：

• Error(一般我們都會把這個忽略掉…一般情況下出現了Error程序都運行不起來)

• Exception

The??Throwable?class?is?the?superclass?of?all?errors?and?exceptions?in?the?Java?language

在《手冊》上也有對上面的規則進行說明：

說明：通過反射機制來調用方法，如果找不到方法，拋出 NoSuchMethodException。什么情況會拋出

NoSuchMethodError 呢？二方包在類沖突時，仲裁機制可能導致引入非預期的版本使類的方法簽名不匹

配，或者在字節碼修改框架(比如：ASM)動態創建或修改類時，修改了相應的方法簽名。這些情況，即

使代碼編譯期是正確的，但在代碼運行期時，會拋出 NoSuchMethodError。

大概的意思就是說：調用 RPC、二方包、或動態生成類的相關方法時，可能直接拋出的是Error，而catch Exception是無法捕獲得到的。

想看例子的同學可以看看這篇文章：

• https://zhuanlan.zhihu.com/p/57950399

最后

這篇文章好像有點短…

參考資料(阿里巴巴開發手冊下載地址)：

• https://github.com/alibaba/p3c

查閱資料時發現的好文：

• https://www.cnblogs.com/chenhongliang/p/5312517.html

• https://www.cnblogs.com/crazyacking/p/5456347.html

推薦閱讀：

• 記一次愚蠢的操作--線程安全問題

• 最近學到的前后端分離知識

• 在工作中常用到的SQL

• Github上有哪些Java面試/學習相關的倉庫推薦?

• 工作中常用到的Linux命令

• 在公司做的項目和自己在學校做的有什么區別？

• 目錄|Java3y最全目錄

200多篇原創技術文章海量視頻資源精美腦圖面試題

長按掃碼可關注獲取?

歡迎關注點個再看

總結

以上是生活随笔為你收集整理的sqlserver 事务日志 异常增长原因排查_小白入门学习打日志的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。