為什麼國產資料庫的日誌看了讓人上頭呢？

日誌分析是分析資料庫故障的重要手段，記得三十多年前剛剛開始學Oracle的時候，前輩告誡我做資料庫運維，遇到故障，ALERT LOG永遠是第一個要關注的要素。這麼多年的實踐也證明了，沒有遵循這個原則的時候往往會吃苦頭。有一次遇到一個十分棘手的問題，STATSPACK報告也分析了、各種指標、TOP SQL也看了，沒有發現問題。折騰了半天，快絕望的時候突然想起了看看alert log。一看嚇了一跳，資料庫不斷的在報ORA-00600[kcbgtcr_1]，每分鐘寫出幾個GB的日誌。這種故障以前遇到過幾次，一下子就明白咋回事了。

在資料庫國產化時代，我有點蒙圈了。各種資料庫的日誌檔案各異，格式也五花八門，因為對資料庫的原理知之甚少，因此看起來如看天書。這些資料庫日誌的唯一的相似點就是看著讓人蒙圈。有些資料庫系統都慢得快掛了，各種日誌檔案裡乾淨得很，找不到可以讓人參考的資訊。有些資料庫則是沒事都每個小時幾百個MB的日誌資訊，好像寫日誌對效能沒任何影響似的。最大的問題是日誌雖然多，但是沒有太多有用的東西，或者說讓人看得有些費解，有點像我們程式沒寫好，忘了把一些除錯資訊刪掉一樣。

就看日誌上頭的問題，我也與許多國產資料庫廠商的研發人員做過交流，他們回答的理由五花八門，不過有一點是相似的，那就是他們希望在日誌裡多輸出一些資訊，以便於故障時更為準確的定位。這個觀點讓我對國產資料庫日誌為什麼如此雜亂有了一個初步的認知，那就是國產資料庫的日誌實際上包含了兩部分內容：log和trace。大家可能知道，可觀測性的三大來源是metric、log和trace。有些朋友可能會混淆log和trace，把這二者混淆起來。Log是記錄事件的，讓運維人員知道某些資訊、告警、錯誤在某個時刻發生了,一般情況下，log可以只包含事件發生時的一些關鍵資料和資訊，但是不包含事件的詳情，比如詳細的堆疊，記憶體，訊息資訊等。而Trace是一種更為詳細記錄事件或者告警的機制，可以用於細緻分析和除錯跟蹤，因此Trace一般記錄了某個事件或者故障的詳細追蹤資訊，可以用於故障分析或者BUG定位。

在大多數資料庫中並沒有明確的將log和trace區分開來，而是統一輸出到日誌裡的。這樣就讓我們在檢視日誌的時候感到十分困惑。在上面的日誌中，我們看到一些unkwon的告警，但是我們無法對這些告警展開分析，因為缺乏trace的資訊，按理說在資料庫處於生產執行的時候，對於diag/info類的資訊可以不記錄日誌，只記錄一些十分關鍵的Info類資訊，比如日誌切換，檢查點發生等。而對於ERROR/FATAL/UNKOWN的錯誤，則要做詳細一些的記錄，比較嚴重的不能忽略的，要記錄trace資訊，這樣才便於跟蹤與定位問題，或者用於售後服務人員分析問題。

但是我們是不是願意看到這樣的日誌檔案呢?密密麻麻都是trace資訊。有心人可以一眼就看出這是Oceanbase的日誌檔案，為了便於跟蹤與定位問題，oceanbase資料庫在各類server的日誌中記錄了大量的這樣的資訊。實際上這些內容應該屬於trace資訊，對於原廠的運維人員定位與分析問題十分有用，但是對於甲方或者第三方的DBA來說，不亞於看天書一樣。

為此，Oceanbase的小夥伴還開發了一款用於OB日誌分析的工具-obdiag，藉助obdiag，DBA終於可以部分看懂這些天書了。

國產資料庫的日誌最大的問題是沒有仔細區分log和trace,並且沒有把寫log和trace的尺度掌握好。其實這方面我們已經有了一個很好的老師-Oracle。

Oracle很好的解決了我上面所說的國產資料庫日誌的問題，日誌和trace是完全分離的。Alert log是日誌，而trace則是*.trc。在alert log中十分乾淨整潔地按照時間順序記錄了相關的事件。如果某個事件產生了trace檔案，則記錄下trace檔案的檔名。根據alert log我們可以十分清晰的看到在某個事件區間裡發生了什麼。如果我們要了解某個事件的詳細資訊，則去trace裡檢視就可以了 。

比如在1月23號發生的某個事件需要做process state dump，我們沒必要把這個幾十MB的TRACE都寫入alert log，而是放在一個獨立的事件trace裡就可以了。如果我們的國產資料庫的日誌都這樣有條理，是不是對運維和原廠的售後服務很有幫助呢?