作為現代關係資料庫中，KingbaseES帶有許多用於微調的引數。需要考慮的領域之一是KingbaseES應該如何記錄其活動。日誌記錄在Kingbases資料庫管理中經常被忽略，如果不被忽略，通常會被錯誤地設定。發生這種情況是因為大多數情況下，日誌記錄的目的尚不清楚。當然，日誌記錄的根本原因是眾所周知的，但有時缺少的是對如何使用日誌的理解。

每個平臺的日誌記錄要求都是唯一的，因此KingbaseES日誌記錄的配置方式也將有所不同。政務服務機構需要在其資料庫日誌中捕獲的內容將與處理關鍵健康資訊的醫療公司需要記錄的內容不同。在某些情況下，它們也可以是相似的。

在本文中，將介紹一些基本實踐，以充分利用KingbaseES日誌。為了從中獲得最佳價值，我們需要思考如何使用他們的KingbaseES資料庫伺服器日誌：

• 需要捕獲特定資訊的語法合規性原因
• 需要存在特定事件詳細資訊的安全稽核
• 要記錄查詢及其引數的效能故障排除
• 日常運維支援，其中要監控一定數量的指標

說到這裡，就讓我們開始吧。

為KingbaseES使用單獨的日誌檔案

我建議在正常操作期間啟用KingbaseES的本機日誌記錄收集器。要啟用 KingbaseES 本機日誌記錄，請將以下引數設定為 on：

logging_collector = on

有兩個原因：

首先，在繁忙的系統中，作業系統可能無法在系統日誌中一致地記錄KingbaseES訊息（假設基於Linux的安裝），並且經常丟棄訊息。使用本機KingbaseES日誌記錄，一個單獨的守護程式負責記錄事件。當KingbaseES繁忙時，此過程將推遲對日誌檔案的寫入，以使查詢執行緒完成。這可能會阻止整個系統，直到寫入日誌事件。因此，在日誌中記錄不太詳細的訊息（我們稍後將看到）並使用縮短的日誌行字首是很有用的。

其次，正如我們稍後將看到的，應該使用日誌管理實用程式收集，解析，索引和分析日誌。讓KingbaseES在syslog中記錄其事件將意味著在日誌管理部分建立一個額外的過濾和模式匹配層，以過濾掉所有的“噪音訊息”。大多數工具可以輕鬆解析專用日誌檔案併為事件編制索引。

將日誌目標設定為 stderr

讓我們考慮“log_destination”引數。它可以有四個值：

log_destination = stderr | syslog | csv | eventlog

除非有充分的理由在 Windows 中以逗號分隔格式儲存日誌事件或事件日誌，否則我建議將此引數設定為 stderr。這是因為對於 CSV 檔案目標，自定義的“log_line_prefix”引數值不會產生任何影響，但是，字首可以設定為包含有價值的資訊。

另一方面，CSV日誌可以很容易地匯入到資料庫表中，然後使用標準SQL進行查詢。一些KingbaseES使用者發現它比處理原始日誌檔案更方便。正如我們稍後將看到的，現代日誌管理解決方案可以本機解析KingbaseES日誌，並自動從中建立有意義的見解。使用CSV，報告和視覺化必須由使用者手動完成。

最終，這取決於您的選擇。如果您願意建立自己的資料引入管道，以將 CSV 日誌載入到資料庫表中，清理和轉換資料，並建立適合您業務需求的自定義報告，請確保將“log_destination”設定為 CSV。

使用有意義的日誌檔名

當KingbaseES日誌檔案儲存在本地時，遵循命名風格似乎沒有必要。對於非 CSV 格式的日誌，預設檔名樣式為“kingbase-%Y-%m-%d_%H%M%S.log”，這在大多數情況下就足夠了。

當您將日誌檔案從多個伺服器儲存到一箇中心位置（如專用日誌伺服器、已掛載的 NFS 卷或 S3 儲存桶）時，命名變得非常重要。在這種情況下，我建議使用兩個引數：

log_directory = sys_log
log_filename = kingbase-%Y-%m-%d_%H%M%S.log

若要將來自多個例項的日誌檔案儲存在一個位置，請首先為每個例項建立單獨的目錄層次結構。這可以類似於以下內容：

/<Application_Name>/<Environment_Name>/<Instance_Name>

然後，每個KingbaseES例項的“log_directory”都可以指向其指定的資料夾。

然後，每個例項都可以使用相同的“log_filename”引數值。預設值將建立一個類似

KingbaseES_2020-08-25_2359.log

若要使用更有意義的名稱，請將“log_filename”設定為如下所示：

log_filename = "Kingbase_%A-%d-%B_%H%M"

然後，日誌檔案將命名為：

Kingbase_Saturday-23-August_2230

使用有意義的日誌行字首

KingbaseES日誌行字首可以包含除實際訊息本身之外最有價值的資訊。Kingbases 文件顯示了日誌事件字首配置的幾個轉義字元。這些轉義序列在執行時被替換為各種狀態值。某些應用程式（如 kbbadger）需要特定的日誌行字首。

我建議在字首中包含以下資訊：

• 事件的時間（不含毫秒）：%t
• 遠端客戶端名稱或 IP 地址： %h
• 使用者名稱： %u
• 訪問的資料庫： %d
• 應用程式名稱： %a
• 程序 ID： %p
• 終止非會話程序輸出：%q
• 每個會話或程序的日誌行號，從 1 開始：%l

要了解字首中每個欄位的內容，我們可以在欄位之前新增一個小的文字字串。因此，程序ID值可以以文字“PID=”開頭，資料庫名稱可以以“db=”為字首等。下面是一個示例：

log_line_prefix = 'time=%t, pid=%p %q db=%d, usr=%u, client=%h , app=%a, line=%l '

根據事件的來源，日誌行字首將顯示不同的值。後臺程序和使用者程序都將在日誌檔案中記錄其訊息。對於系統程序，我指定了 %q，它將禁止顯示程序 ID （%p） 後的任何文字。任何其他會話將顯示資料庫名稱、使用者名稱、客戶端地址、應用程式名稱以及每個事件的編號行。

此外，我在日誌行字首後包含一個空格。此空間將日誌事件字首與實際事件訊息分開。它不必是空格字元 - 可以使用雙冒號（:），連字元（-）或其他有意義的分隔符之類的任何東西。

此外，將“log_hostname”引數設定為 on：

log_hostname = on

否則，將僅顯示客戶端 IP 地址。在生產系統中，這通常是代理、負載平衡器或連線池程式的地址。除非您知道這些系統的IP地址，否則記錄其主機名可能是值得的。可以在hosts檔案中，建立本地DNS列表來轉換主機名，但是DNS 查詢還會為日誌記錄守護程式寫入檔案增加額外的時間。

另一個應與“log_line_prefix”一起設定的引數是“log_timezone”。將此設定為伺服器的本地時區將確保記錄的事件易於從其時間戳跟蹤，而不是首先轉換為本地時間。在下面的程式碼片段中，我們將log_timzeone設定為北京標準時區：

log_timezone = 'Asia/Beijing'

僅記錄連線

兩個引數控制KingbaseES如何記錄客戶端連線和斷開連線。預設情況下，這兩個引數都處於關閉狀態。根據組織的安全要求，您可能希望將其中一個設定為 on，將另一個設定為 off（除非您使用的是 kbbadger 等工具 – 稍後會詳細介紹）。

log_connections = on
log_disconnections = off

將log_connections設定為 on 將記錄所有授權連線以及嘗試的連線。這顯然有利於安全審計：可以從日誌中輕鬆識別暴力攻擊。但是，啟用此設定後，具有數千甚至數百個短期有效連線的繁忙 KingbaseES 環境可能會看到日誌檔案被淹沒。

但是，它還可以識別在其他方面可能不明顯的應用程式問題。來自許多不同有效客戶端地址的大量連線嘗試可能表示例項需要在其前面使用負載均衡器或連線池服務。來自單個客戶端地址的大量連線嘗試，可能會發現應用程式具有太多執行緒，需要某種形式的限制。

僅記錄 DDL 和 DML 操作

關於應該在Kingbases日誌中記錄什麼，存在很多爭論 - 即“log_statement”引數的值應該是什麼。它可以有三個值：

log_statement = 'off' | 'ddl' | 'mod' | 'all'

將此設定為“all”，以捕獲伺服器上執行的每個SQL語句，可能很誘人，但這在現實中可能並不總是一個好主意。

繁忙的生產系統主要執行 SELECT 語句，有時每小時執行數千個語句。例項可能執行良好，沒有任何效能問題。在這種情況下，將此引數設定為“all”會不必要地增加日誌記錄守護程式的負擔，因為它必須將所有這些語句寫入檔案。

但是，您要捕獲的是任何資料損壞，或導致某種型別問題的資料庫結構更改。與選擇資料相比，不需要或未經授權的資料庫更改，會導致更多的應用程式問題；這就是為什麼我建議將此引數設定為“mod”。使用此設定，KingbaseES將記錄所有DDL和DML對日誌檔案的更改。

如果您的 KingbaseES 例項處於中等繁忙狀態（每小時數十個查詢），請隨時將此引數設定為“all”。對執行緩慢的 SELECT 查詢進行故障排除或查詢未經授權的資料訪問時，還可以暫時將其設定為“all”。像kbbadger這樣的一些應用程式也希望你把它設定為“all”。

記錄“警告”訊息並啟動

如果 “log_statement” 引數決定將記錄哪種型別的語句，則以下兩個引數指示訊息的詳細程度：

log_min_messages = DEBUG5-1 | INFO | NOTICE | WARNING | ERROR | LOG | FATAL | PANIC
log_min_error_statement =  DEBUG5-1 | INFO | NOTICE | WARNING | ERROR | LOG | FATAL | PANIC

每個 KingbaseES 事件都有一個關聯的訊息級別。訊息級別可以是任何內容，從詳細的 DEBUG 到簡潔的 PANIC。級別越低，訊息越詳細。“log_min_messages”引數的預設值為“警告”。我建議將其保持在此級別，除非您也希望記錄資訊性訊息。

“log_min_error_statement”引數控制將記錄哪些 SQL 語句引發錯誤。與“log_min_message”一樣，將記錄錯誤嚴重性級別等於或高於“log_min_error_statement”中指定的值的任何 SQL 語句。預設值為“ERROR”，我建議保留預設值。

將日誌持續時間引數保留為預設值

然後我們有以下兩個引數：

log_duration = off
log_min_duration_statement = -1

“log_duration”引數採用布林值。當它設定為 on 時，將記錄每個已完成語句的持續時間。如果設定為 off，則不會記錄語句持續時間。這是預設值，我建議將其保留為 0，除非您正在解決效能問題。計算和記錄語句持續時間會使資料庫引擎執行額外的工作（無論多麼小），並且當它被外推到數百或數千個查詢時，可以節省大量成本。

最後，我們有“log_min_duration_statement”引數。設定此引數時（不帶任何單位，它以毫秒為單位），將記錄等於或長於引數值的任何語句的持續時間。將此引數值設定為 0 將記錄所有已完成語句的持續時間。將此值設定為 -1 將禁用語句持續時間日誌記錄。這是預設值，我建議保留它。

唯一要將此引數設定為 0 的時間是要為頻繁執行的查詢建立效能基線時。但請記住，如果設定了引數“log_statement”，則記錄的語句將不會在顯示持續時間的日誌訊息中重複。因此，您需要在資料庫表中載入日誌檔案，然後從日誌行字首聯接程序 ID 和會話 ID 值，以標識相關語句及其持續時間。

無論採用何種方式，一旦為每個頻繁執行的查詢設定了基線，就可以將 “log_min_duration_statement”引數設定為基線值中最高的一個。現在，任何執行時間超過最高基線值的查詢，都將是調優的候選項。

將錯誤訊息詳細程度保留為預設值

“log_error_verbosity”引數可以有三個可能的值：

log_error_verbosity = terse | standard | verbose

此引數控制 KingbaseES 將為日誌檔案中記錄的每個事件記錄的資訊量。除非除錯資料庫應用程式，否則此引數最好保持為“default”。當您需要捕獲生成錯誤的檔案或函式名稱以及行號時，詳細模式將非常有用。將此設定為“簡潔”將禁止記錄查詢，這可能也沒有用。

查詢適合您的使用案例的日誌輪換策略

我建議根據日誌檔案的大小或期限建立日誌輪換策略，但不要同時建立兩者。兩個 KingbaseES 配置引數指示如何存檔舊日誌和如何建立新日誌：

log_rotation_age = <number of minutes>
log_rotation_size = <number of kilobytes>

“log_rotration_age”的預設值為 24 小時，“log_rotation_size”的預設值為 10 MB。

在大多數情況下，使用檔案大小輪換策略，不能保證存檔日誌檔案中的最後一條日誌訊息，完整地包含在該檔案中。

如果將“log_rotation_age”保留為其預設值 24 小時，則可以輕鬆識別和單獨檢查每個檔案，因為每個檔案將包含一天的事件。但是，這也不能保證每個檔案，都是過去 24 小時的包含完整事務日誌單元。因為有時執行緩慢的查詢，可能需要 24 小時以上才能完成。當舊檔案關閉，並生成新檔案時，可能會發生事件。在夜間批處理作業期間可能就是這種情況，導致查詢的某些部分記錄在一個檔案中，其餘部分記錄在另一個檔案中。

我們建議找到適合您的用例的日誌輪換週期。檢查兩個連續的最低活動時間段（例如，一個星期六到下一個星期六之間的時間差）。然後，您可以將“log_rotation_age”值設定為該時差，並在其中一個時間段內重新啟動KingbaseES服務。這樣，KingbaseES將在下一個停頓期發生時輪換當前日誌檔案。但是，如果您需要在這些時間段之間重新啟動服務，日誌輪換將再次傾斜。然後，您將不得不重複此過程。但就像KingbaseES中的許多其他事情一樣，反覆試驗將決定最佳價值。此外，如果您使用的是日誌管理實用程式，則日誌輪換期限或大小無關緊要，因為日誌管理器代理程式將在新增檔案時從檔案中引入每個事件。

讓後臺程序明顯區分不同的KingbaseES服務

設定控制伺服器程序的程序標題，可以直白的說明程序的歸屬和分組。程序標題通常可以用ps或者 Windows 上的程序瀏覽器等程式來檢視。

cluster_name = <string_name>
update_process_title = on | off

在一個伺服器中，可以同時執行多個數據庫叢集(例項)。雖然有多種方法來區分這些服務的主程序，比如服務埠、庫的路徑等，但仍不夠簡明直觀。通過設定“cluster_name” 引數，可以標識這個資料庫叢集(例項)的名稱，此叢集名稱出現在該叢集中所有伺服器程序的程序標題中。

通過設定“update_process_title” 引數，可以啟用程序標題更新，每次伺服器接收到一個新的 SQL 命令時都更新程序標題。在大部分平臺上這個設定預設為on，但是由於 Windows 上更新程序標題的開銷更大，所以在 Windows 這個設定預設為off。

使用像kbbadger這樣的工具

kbbadger是一個功能強大的KingbaseES日誌分析器，可以從KingbasesES日誌檔案中,建立非常有用的報告。它是一個用Perl編寫的開源工具，在執行它的機器中佔用的空間非常小。該工具從命令列執行，並帶有大量選項。它將採用一個或多個日誌作為其輸入，並且可以生成一個HTML報告，其中包含以下方面的詳細統計資訊：

• 最常等待查詢。
• 生成大多數臨時檔案或最大臨時檔案的查詢
• 執行最慢的查詢
• 平均查詢持續時間
• 最常執行查詢
• 查詢中最常見的錯誤
• 執行查詢的使用者和應用程式
• 檢查點統計資訊。
• 自動真空和自動分析統計資訊。
• 鎖定統計資訊
• 錯誤事件（宕機、致命、錯誤和警告）。
• 連線和會話配置檔案（按資料庫、使用者、應用程式）
• 會話配置檔案
• 查詢配置檔案（查詢型別、按資料庫/應用程式進行的查詢）
• I/O 統計資訊
• 等。

如前所述，必須啟用一些與日誌相關的配置引數才能捕獲所有日誌事件，以便 kbbadger 可以有效地分析這些日誌。由於這可能會生成包含許多事件的大型日誌檔案，因此 kbbadger 應僅用於建立基準測試或解決效能問題。生成詳細日誌後，可以將配置引數更改回其原始值。對於連續的日誌分析，最好使用專用的日誌管理應用程式。

如果您更習慣於在命令提示符下執行操作並使用系統檢視，則需要使用sys_stat_statements。實際上，這應該在任何生產KingbaseES安裝中啟用。

sys_stat_statements是KingbaseES擴充套件，現在預設安裝。若要啟用它，“shared_preload_libraries”配置引數應具有sys_stat_statements作為其值之一。然後可以使用“CREATE EXTENSION”命令像任何其他擴充套件一樣安裝它。該擴充套件建立sys_stat_statement檢視，該檢視提供與查詢相關的有價值資訊。

最後的話

如果配置得當，KingbaseES伺服器日誌可以成為資訊的金礦。訣竅是確定要記錄的內容和記錄的內容，更重要的是，測試日誌是否可以在需要時提供正確的資訊。這將是一個反覆試驗的問題，但我今天在這裡討論的內容應該有一個相當不錯的開端。正如我在開始時所說，我非常樂意聽到您配置KingbaseES日誌記錄以獲得最佳結果的經驗。