如何充分利用KingbaseES日志

作为现代关系数据库中，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日志记录以获得最佳结果的经验。