剛剛咱們組的產品經理和法務部的同事找我,說公司正在和某個客戶打官司。爲了反駁客戶的某一些說辭,須要我幫忙找一找某個客戶的某一份合同文件的操做日誌。也就是:java
須要肯定就是這個客戶在某一天的某個時間進入咱們的某個系統進行了「合同簽署」這個操做程序員
過後我想了一下,裏面確實有不少咱們平時設計系統,實現系統功能時須要注意的一些點,因此我基於我目前的眼界和經驗,總結一下,但願對你們有所幫助,爭取不浪費讀者朋友們的寶貴的時間。框架
我覺的最基本的可是也是最重要的事情就是日誌的輸出。由於沒有日誌輸出也就沒有下面要說的「存儲收集」和「查詢展現」了。性能
我不肯定讀者所在的格式是否有日誌規範,我覺的有一份好的日誌規範仍是很重要的,可是最重要的仍是有效的執行下去。線程
Java裏存在衆多的開源日誌框架,好比:slf4j, logback, log4j, JCL(Apache Common Logging), JUL(JDK自帶的java.util.logging)
。設計
我通常都採用SLF4J這個框架,由於它的API很簡潔。其實它並不包含日誌的實現,而僅僅是提供了衆多的適配器來適配其餘全部開源的日誌框架,這就使得咱們在代碼中只須要面對SLF4J的API,而後能夠任意的切換實現。代理
也許大家並不須要切換日誌框架的實現這個功能,但每每咱們的項目都會依賴不少的第三方的開源框架,而這些第三方的開源框架有可能採用不一樣的日誌框架,而不一樣的日誌框架可能須要的配置也不盡相同,不一樣的配置又可能致使日誌輸出到不一樣的位置,這就很不方便咱們後續的日誌收集和管理。調試
爲了方便咱們將日誌統一收集和管理起來,咱們可使用slf4j的適配器將第三方庫中各類日誌的實現接管,接管以後就能夠統一配置這些第三方庫中使用的日誌了。日誌
而logback的性能又很是的好,因此我就選擇了logback做爲個人日誌實現了。code
日誌有:TRACE, DEBUG, INFO, WARN, ERROR, FATAL
這幾個隔離級別。
必定要用好日誌級別。個人習慣和理解以下:
統必定義日誌文件的名稱,日誌內容的格式,能夠極大的方便後續日誌的收集和解析工做。
大的指導原則是:
根據系統使用場景不一樣,對日誌的側重點就不同。致使這些不一樣側重點的緣由可能有:
好比咱們作兩個系統,一個是「權限管理系統」,另一個是「信息通知系統」,幹一些發郵件,短信等的消息。前者咱們須要詳細的操做日誌,記錄「誰在某年某月某日爲某人分配了什麼權限」,由於審計部門須要。然後者即使發送出錯了,重試或者忽略均可以考慮,甚至都不須要記錄任何的日誌。
系統可能有點大,系統中的一些模塊、重要接口對日誌的要求也很高,好比我文章開頭舉得例子,代理商說合同我沒有簽定,死不認可。這個時候怎麼辦呢,只能找當時的系統日誌來講了。假設當時系統沒有輸出日誌,或者輸出的日誌信息對於打官司一點用都沒有,那麼就比較尷尬了。
我不肯定你們是否遇到過下面的狀況:*排查問題時,發現那塊出現錯誤的地方有日誌輸出,可是輸出的日誌對於排查問題一點用都沒有**,每當出現這種狀況的時候我都想罵人。
好的日誌須要有哪些內容呢?
重要API,系統間交互等地方是加日誌,監控的重點位置
臨時想到一個,就是日誌輸出時,儘可能輸出一些「不可變的或者惟一」的信息。舉個例子:
爲了在日誌中記錄某個用戶的行爲,可是用戶的身份能夠用本身生成的userId,手機號,身份證號,暱稱等。
考慮到暱稱和手機號可能會變化,因此使用這兩個來在日誌中表示用戶身份可能就不合適了。也許查詢一年前的日誌是,可是記錄的手機號已經不屬於這個用戶了。
關於日誌的存儲方式,不管是使用MySQL,Elasticsearch,HDFS等,都已經頗有多的文章和教程了,我就不詳細提了。
主要須要注意點是:日誌的存儲時須要瞭解清楚日誌存儲的做用,而後按照某些維度來組織,好比時間,好比操做人等,方便後續聚合、查詢,分析等。
另外還須要注意的是日誌的存儲時間,若是大家的日誌是永久存儲的話,當我沒說哈。通常公司會爲了節省存儲空間成本,會按期刪除一些日誌,這個時候須要根據日誌的重要性肯定是否永久存儲,或者按期刪除的時間長短。