ClickHouse 的管理与运维(十九)

​ 本文来源: ( https://www.cnblogs.com/traditional/tag/ClickHouse:一款速度快到让人发指的列式存储数据库/ )


楔子

下面来说一下 ClickHouse 管理和运维相关的知识,该部分可以让 ClickHouse 变得更加安全与健壮。在前面演示的案例中,为了方便,我们一直使用默认的 default 用户,并且没有配置密码,这显然不符合生产环境的要求。所以接下来,我们就来介绍 ClickHouse 的权限、熔断机制、数据备份和服务监控等知识。

用户配置

users.xml 配置文件默认位于 /etc/clickhouse-server 路径下,ClickHouse 用它来定义用户相关的配置项,包括系统参数的设定、用户的定义、权限以及熔断机制等。

用户的角色配置(profile)

在 users.xml 中有一个 profiles 标签,在该标签中我们可以定义用户角色,先看看默认配置:

img

这是 ClickHouse 的默认配置,显然默认有两个角色,分别是 default 和 readonly。需要注意的是,这里的 default 和 readonly 指的是角色,每一个用户都具有一个角色。我们可以在 CLI 中直接切换到想要的角色:

1
SET profile = '角色名'

我们可以测试一下,首先我们默认使用的是 default 用户,该用户对应的角色默认也是 default。然后还有一个 readonly 角色,从名字上也能看出该角色只能读数据,无法写数据,因为内部的 readonly 属性为 1,默认为 0。

img

当 default 用户具有 default 角色时,写数据一切正常,但是将 default 用户的角色切换为 readonly 时则被告知:Cannot execute query in readonly mode。当然,如果我们在 default 角色对应配置中也加上 1,那么具有该角色的用户同样也会无法写数据。

在所有的角色配置(profile)中,名称为 default 的 profile 将作为默认的配置被加载,所以它必须存在。如果缺失名为 default 的 profile,那么 ClickHouse Server 会启动失败:

1
Application: DB::Exception: Settings profile`default`not found

profile 还支持继承,实现继承的方式是在定义中引用其他的 profile 名称,例如:

1
2
3
4
5
<my_role>
<profile>default</profile>
<!-- <profile>default2</profile> 可以继承多个-->
<distributed_product_mode>deny</distributed_product_mode>
</my_role>

相当于新建了一个名为 my_role 的角色,然后在对应的 profile 中继承了 default 的所有配置项,并且使用新的参数值覆盖了 default 中原有的 distributed_product_mode 配置项。

配置约束

constraints 标签可以设置一组约束条件,以保障 profile 内的参数值不会被随意修改,约束条件有如下三种规则:

  • min:最小值约束,在设置相应参数的时候,取值不能小于该阈值
  • max:最小值约束,在设置相应参数的时候,取值不能大于该阈值
  • readonly:只读约束,该参数值不能被修改

下面举例说明:

img

从上面的配置定义中可以看出,在 default 默认的 profile 内,给两组参数设置了约束。首先为 max_memory_usage 设置了 min 和 max 阈值;其次为 distributed_product_mode 设置了只读约束。然后重启 ClickHouse,并尝试修改 max_memory_usage 参数,将它改为 50:

img

可以看到最小值约束阻止了这次修改,接着继续修改 distributed_product_mode 的值:

img

同样配置约束成功阻止了预期外的修改。还有一点需要明确,在 default 中默认定义的 constraints 约束,将作为默认的全局约束,自动被其它 profile 继承。

用户

通过 profiles 标签可以为用户定义角色,那么可不可以定义用户呢?显然是可以的,通过 users 标签即可。如果打开配置文件,会发现 users 标签下已经有一个默认的 default 用户,我们之前使用的一直都是这个用户,而我们也可以定义一个新用户,但必须包含如下属性:

password

password 用于设置登录密码,支持明文、SHA256 加密和 double_sha1 加密三种形式,可以任选其中一种进行设置。现在分别介绍它们的使用方法。

1)明文密码:在使用明文密码的时候,直接通过 password 标签定义,例如下面的代码。

1
<password>123</password>

如果 password 为空,则表示免密码登录。

1
<password></password>

2)SHA256 加密:在使用 SHA256 加密算法的时候,需要通过 password_sha256_hex 标签定义密码,例如下面的代码。

1
<password_sha256_hexs>a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3</password_sha256_hexs>

至于计算的方式,可以通过如下命令,比如对 123 进行加密:

1
2
[root@satori ~]# echo -n 123 |openssl dgst -sha256
(stdin)= a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3

或者使用 Python:

1
2
3
4
>>> import hashlib
>>> hashlib.sha256(b"123").hexdigest()
'a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3'
>>>

3)double_sha1 加密:在使用 double_sha1 加密算法的时候,则需要通过 password_double_sha1_hex 标签定义密码,例如下面的代码。

1
<password_double_sha1_hex>23ae809ddacaf96af0fd78ed04b6a265e05aa257</password_double_sha1_hex>

至于计算的方式,可以通过如下命令,比如对 123 进行加密:

1
2
[root@satori ~]# echo -n 123 | openssl dgst -sha1 -binary | openssl dgst -sha1
(stdin)= 23ae809ddacaf96af0fd78ed04b6a265e05aa257

或者使用 Python:

1
2
3
4
5
>>> import hashlib
>>> _ = hashlib.sha1(b"123").digest()
>>> hashlib.sha1(_).hexdigest()
'23ae809ddacaf96af0fd78ed04b6a265e05aa257'
>>>

networks

networks 表示被允许登录的网络地址,用于限制用户登录的客户端地址,关于这方面的介绍将会在后续展开。

profile

用户所使用的角色,直接引用相应的名称即可,例如:

1
<profile>profile_1</profile>

该配置的语义表示:该用户使用了名为 profile_1 的角色。

quota

quota 用于设置该用户能够使用的资源限额,可以理解成一种熔断机制。关于这方面的介绍同样将会在后续展开。

下面我们就来定义一个完整的实例来定义三个用户,密码分别使用明文密码、sha256 加密、double sha1 加密:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<users>
<default> <!-- 默认用户 -->
...
</default>

<!-- 使用明文密码 -->
<user_plaintext>
<password>123</password>
<networks>
<ip>::/0</ip>
</networks>
<profile>default</profile>
<quota>default</quota>
</user_plaintext>

<!-- 使用 sha256 加密 -->
<user_sha256>
<password_sha256_hex>a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3</password_sha256_hex>
<networks>
<ip>::/0</ip>
</networks>
<profile>default</profile>
<quota>default</quota>
</user_sha256>

<!-- 使用 double sha1 加密 -->
<user_double_sha1>
<password_double_sha1_hex>23ae809ddacaf96af0fd78ed04b6a265e05aa257</password_double_sha1_hex>
<networks>
<ip>::/0</ip>
</networks>
<profile>default</profile>
<quota>default</quota>
</user_double_sha1>
</users>

由于配置了密码,那么以后使用指定用户登录时,就必须指定密码了,举个栗子:

img

–host 指定 IP,–port 指定端口,–user 指定用户,我们看到指定用户为 user_plaintext 进行登录的时候报错的,原因就是该用户设置了密码,但我们没有指定。而通过 –password 指定密码之后,便可登录成功了。

至于其它用户类似:

1
2
3
# 配置文件中写的是加密后的结果,但是登录时,密码还是使用加密前的结果,这里是 123
clickhouse-client --user user_sha256 --password 123
clickhouse-client --user user_double_sha1 --password 123

权限管理

权限管理是一个始终都绕不开的话题,ClickHouse 分别从访问、查询和数据等角度出发,层层递进,为我们提供了一个较为立体的权限体系。

访问权限

访问层控制是整个权限体系的第一层防护,它又可进一步细分成两类权限。

网络访问权限

网络访问权限使用 networks 标签设置,用于限制客户端登录的地址,限制方式可以通过 IP 地址、host 主机名称实现,两者选其一即可。

比如通过 IP 地址设置:

1
2
<!-- 只能通过 IP 为 127.0.0.1 的主机访问 -->
<ip>127.0.0.1</ip>

通过 host 主机名称设置:

1
2
<!-- 只能通过主机名为 satori 的主机访问,另外这里配置主机名的时候还可以使用正则 -->
<host>satori</host>

数据库与字典访问权限

在客户端连入服务之后,可以进一步限制某个用户数据库和字典的访问权限,它们分别通过 allow_databases 和 allow_dictionaries 标签进行设置。如果不进行定义,则表示不进行限制。

1
2
3
4
5
6
7
8
9
10
11
12
<user_plaintext>
<password>123</password>
...

<allow_databases>
<database>default</database>
<database>kagura_nana</database>
</allow_databases>
<allow_dictionaries>
<dictionary>test_dict</dictionary>
</allow_dictionaries>
</user_plaintext>

通过上述操作,该用户在登录之后,将只能看到为其开放了访问权限的数据库和字典。

查询权限

查询权限是整个权限体系的第二层防护,设置在 profile 中,它决定了拥有此角色的用户能够执行的查询语句,查询权限可以分为以下四类:

  • 读权限:包括 SELECT、EXISTS、SHOW 和 DESCRIBE 查询
  • 写权限:包括 INSERT 和 OPTIMIZE 查询
  • 设置权限:包括 SET 查询
  • DDL 权限:包括 CREATE、DROP、ALTER、RENAME、ATTACH、DETACH 和 TRUNCATE 查询
  • 其它权限:包括 KILL 和 USE 查询,任何用户都可以执行这些查询

上述权限,可以通过以下两项配置标签控制:

  • 1)readonly:读权限、写权限和设置权限均由此标签控制,它有三种取值:
    • 当取值为 0 时,表示不进行任何限制(默认值)
    • 当取值为 1 时,表示只拥有读权限,即只能执行 SELECT 、EXISTS、SHOW 和 DESCRIBE
    • 当取值为 2 时,表示拥有读权限和设置权限,相当于在读权限的基础上增加了 SET 查询
  • 2)allow_ddl:DDL 权限由此标签控制,它有两种取值:
    • 当取值为 0 时,不允许 DDL 查询
    • 当取值为 1 时,允许 DDL 查询(默认值)

举个栗子,我们增加一个角色。

1
2
3
4
5
6
7
8
9
<profiles>
<default>...</default>
<readonly>...</readonly>

<profile_test>
<readonly>1</readonly>
<allow_ddl>0</allow_ddl>
</profile_test>
</profiles>

修改配置文件之后,重启 ClickHouse,然后连接:

img

我们看到切换角色之后,不再具有 DDL 执行权限。当然数据也是只读模式,此时写入数据是失败的。

至此,权限设置已然生效。

数据行级权限

数据权限是整个权限体系中的第三层防护,它决定了一个用户能够看到什么数据,说人话就是数据粒度更细了,可以只将一张表的部分数据暴露给用户。

而该权限使用 database 标签定义(位于 users 标签内部),database 通过定义用户级别的查询过滤器来实现数据的行级粒度权限,它的定义规则如下所示:

1
2
3
4
5
6
7
<databases>
<database_name> <!-- 数据库名称 -->
<table_name> <!-- 表名称 -->
<fileter>id > 10</fileter> <!-- 数据过滤条件,也可以写复杂的条件 -->
</table_name>
</database_name>
</databases>

我们以之前的 distributed_test_1 为例,测试一下,所以配置文件修改如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<user_test_2>  <!-- 新建一个角色 -->
<password>123</password>
<networks>
<ip>::/0</ip>
</networks>
<profile>default</profile>
<quota>default</quota>

<databases>
<default>
<distributed_test_1>
<filter>id > 10</filter>
</distributed_test_1>
</default>
</databases>
</user_test_2>

修改之后重启 ClickHouse:

img

整个过程还是很好理解的,那么 ClickHouse 底层是怎么做的呢?答案很简单,从配置文件中 filter 标签的内容也能看出来,就是追加了一个 WHERE 条件。

对于数据权限的使用有一点需要明确,在使用了这项功能之后,PREWHERE 优化将不再生效。所以是直接利用 ClickHouse 的内置过滤器,还是通过拼接 WHERE 查询条件的方式实现行级过滤,需要根据使用场景进行权衡。

熔断机制

熔断是限制资源被过度使用的一种自我保护机制,当使用的资源数量达到阈值时,那么正在进行的操作会被自动中断。而按照使用资源统计方式的不同,熔断机制可以分为两类。

根据时间周期的累积用量熔断

在这种方式下,系统资源的用量是按照时间周期累积统计的,当累积量达到阚值,则直到下个计算周期开始之前,该用户将无法继续进行操作。这种方式通过 users.xml 内的 quotas 标签来定义资源配额,以默认的配置为例:

img

看图中最后一行,是 ,显然到此配置文件就结束了,所以 users.xml 中最外层是 yandex 标签,然后 yandex 标签里面有三个子标签,分别是 profiles、users、quotas,分别用于定义角色、定义用户、熔断限流,还是比较简单的,整个结构比较清晰。然后看看 quotas 标签里面的内容都代表什么含义吧。

  • default:自定义名称,全局唯一
  • duration:累积的时间周期,单位秒
  • queries:在周期内允许执行的查询次数,0 表示不限制
  • errors:在周期内允许发生异常的次数,0 表示不限制
  • result_row:在周期内允许查询返回的结果行数,0 表示不限制
  • read_row:在周期内,在分布式查询中,允许远端节点读取的数据行数,0 表示不限制
  • execution_time:周期内允许执行的查询时间,单位秒,0 表示不限制

我们来配置一下:

1
2
3
4
5
6
7
8
9
10
11
<!-- 在 quotas 标签中增加如下配置 -->
<limit_1>
<interval>
<duration>3600</duration>
<queries>2</queries>
<errors>0</errors>
<result_rows>0</result_rows>
<read_rows>0</read_rows>
<execution_time>0</execution_time>
</interval>
</limit_1>

在名为 limit_1 的配置中,1 个小时的周期内只允许最多 2 次查询,下面让其作用在 user_test_2 用户上。

1
2
3
4
5
<user_test_2> 
...
<quota>limit_1</quota> <!-- 其它部分不变,将 quota 的值从 default 改成 limit_1 -->
...
</user_test_2>

然后重启 ClickHouse,并以 user_test_2 用户启动。

img

执行两次查询之后,如果再执行的话就会报错,证明熔断机制确实已经生效。

根据单次查询的用量熔断

在这种方式下,系统资源的用量是按照单次查询统计的,而具体的熔断规则,则是由许多不同配置项组成的,这些配置项需要定义在用户 profile 中。如果某次查询使用的资源用量达到了阈值,则会被中断。以配置项 max memory_usage 为例,它限定了单次查询可以使用的内存用量,在默认的情况下其规定不得超过 10 GB,如果一次查询的内存用量超过 10 GB,则会得到异常。需要注意的是,在单次查询的用量统计中,ClickHouse 是以分区为最小单元进行统计的(不是数据行的粒度),这意味着单次查询的实际内存用量是有可能超过阈值的。

熔断相关的配置比较多,这里介绍几个常用的。

1)max_memory_usage:在单个 ClickHouse 服务进程中,运行一次查询限制使用的最大内存量,默认值为 10GB。

1
<max_memory_usage>10000000000</max_memory_usage>

2)max_memory_usage_for_user:在单个 ClickHouse 服务进程中,以用户为单位进行统计,单个用户在运行查询时限制使用的最大内存量,默认值为 0,即不做限制。

3)max_memory_usage_for_all_queries:在单个 ClickHouse 服务进程中,所有运行的查询累加在一起所限制使用的最大内存量,默认值为 0,即不做限制。

4)max_partitions_per_insert_block:在单次 INSERT 写入的时候,限制创建的最大分区个数,默认值为 100 个。如果超过这个阈值,将会出现异常。

1
Too many partitions for single INSERT block ······

5)max_rows_to_group_by:在执行 GROUP BY 聚合查询的时候,限制去重后的聚合 KEY 的最大个数,默认值为 0,不做限制。当超过阈值时,其处理方式由 group_by_overflow_mode 决定。

6)group_by_overflow_mode:当 max_rows_to_group_by 熔断规则触发时,group_by_overflow_mode 将会提供三种处理方式。

  • throw:抛出异常,此乃默认值
  • break:立即停止查询,并返回当前数据
  • any:仅根据当前已存在的聚合 KEY 继续完成聚合查询

7)max_bytes_before_external_group_by:在执行 GROUP BY 查询的时候,限制使用的最大内存量,默认值为 0,不做限制。当超过阈值时,聚合查询将会进一步借用本地磁盘。

数据备份

在之前的系列中,我们已经知道了数据副本的使用方法,那么问题来了:既然已经有了数据副本,那么还需要数据备份吗?显然数据备份是需要的,因为数据副本并不能处理误删数据这类行为。ClickHouse自身提供了多种备份数据的方法,根据数据规模的不同,可以选择不同的形式。

导出文件备份

如果数据的体量较小,可以通过 dump 形式将数据导出为本地文件,语句如下:

1
clickhouse-client --query="SELECT * FROM table_name" > table_name.tsv

如果想将备份数据导入的话,可以这么做:

1
cat table_name.csv | clickhouse-client --query="INSERT INTO table_name FORMAT TSV"

上述这种 dump 形式的优势在于,可以利用 SELECT 查询并筛选数据,然后按需备份。如果是备份整个表的数据,也可以直接复制它的整个目录文件。

通过快照表备份

快照表实质上就是普通的数据表,它通常按照业务规定的备份频率创建,例如按天或者按周创建。所以首先需要建立一张与原表结构相同的数据表,然后再使用 INSERT INTO SELECT句式,点对点地将数据从原表写人备份表。假设数据表 table_name 需要按日进行备份,现在为它创建当天的备份表:

1
CREATE TABLE table_name_bak AS table_name

有了备份表之后就可以点对点地备份数据了。

1
INSERT INTO table_name_bak SELECT * FROM table_name

如果考虑到容灾问题,也可以将备份表放在不同的 ClickHouse 节点上,此时需要将 SQL 语句改成远程查询的形式:

1
INSERT INTO table_name_bak SELECT * FROM remote('xx.xx.xx.xx:9000', 'default', 'table_name', 'default')

按分区备份

基于数据分区的备份,ClickHouse 目前提供了 FREEZE 和 FETCH 两种方式,现在分别介绍它们的使用方法。

使用 FREEZE 备份

FREEZE 的完整语法如下所示:

1
ALTER TABLE table_name FREEZE PARTITION partition_expr

分区在被备份之后,会被统一保存到 ClickHouse 根路径 /shadow/N 子目录下。其中 N 是一个自增长的整数,它的含义是备份的次数(FREEZE 执行过多少次),具体次数由 shadow 子目录下的 increment.txt 文件负责记录。而分区备份实质上是对原始目录文件进行硬链接操作,所以并不会导致额外的存储空间。整个备份的目录会一直向上追溯至 data 根路径的整个链路:

img

上面对 partition_test_v1 表的 202008 分区进行了备份,然后我们进入 shadow 子目录,便可看到之前备份的分区目录。

img

如果想还原分区,则需要借助于 ATTACH 装载分区的方式实现,我们需要先将 shadow 子目录下的分区文件复制到相应数据表的 detached 目录下,然后再使用 ATTACH 语句装载。

使用 FETCH 备份

FETCH 只支持 ReplicatedMergeTree 系列的表引擎,其完整语法如下所示:

1
ALTER TABLE table_name FETCH PARTITION partition_id FROM zk_path

其工作原理与 ReplicatedMergeTree 同步数据的原理类似,FETCH 通过指定的 zk_path 找到 ReplicatedMergeTree 的所有副本实例,然后从中选择一个最合适的副本,并下载相应的分区数据。例如执行如下语句:

1
ALTER TABLE test_fetch FETCH PARTITION 202009 FROM '/clickhouse/tables/02/test_fetch'

表示将 test_fetch 的 201909 分区下载到本地,并保存到对应数据表的 detached 目录下,目录如下所示:

1
data/default/test_fetch/detached/202009_0_0_0

与 FREEZE 一样,对于备份分区的还原操作,也需要借助 ATTACH 装载分区来实现。 另外 FREEZE 和 FETCH 虽然都能实现对分区文件的备份,但是它们并不会备份数据表的元数据。所以说如果想做到万无一失的备份,还需要对数据表的元数据进行备份,它们是 /data/metadata 目录下的 [table].sql 文件,目前这些元数据需要用户通过复制的形式单独备份。

服务监控

基于原生功能对 ClickHouse 进行监控,可以从两方面入手:系统表和查询日志,接下来分别介绍它们的使用方法。

系统表

在众多的 SYSTEM 系统表中,主要由以下三张表支撑了对 ClickHouse 运行指标的查询,它们分别是 metrics、events 和 asynchronous_metrics。

1)metrics

metrics 表用于统计 ClickHouse 服务在运行时,当前正在执行的高层次的概要信息,包括正在执行的查询总次数、正在发生合并的操作总次数等。

img

events

events 表用于统计 ClickHouse 服务在运行过程中,已经执行过的高层次的累积概要信息,包括总的查询次数、总的 SELECT 查询次数等。

img

asynchronous_metrics

asynchronous_metrics 表用于统计 ClickHouse 服务在运行过程中,当前后台正在异步运行的高层次的概要信息,包括当前分配的内存、执行队列中的任务数量等。

img

查询日志

查询日志目前主要有 6 种类型,它们分别从不同角度记录了 ClickHouse 的操作行为。所有查询日志在默认配置下都是关闭状态,需要在 config.xml 配置中进行更改,接下来分别介绍它们的开启方法。在配置被开启之后,ClickHouse 会为每种类型的查询日志自动生成相应的系统表以供查询。

1. query_log

query_log 是最常用的查询日志,它记录了 ClickHouse 服务中所有已经执行的查询记录,它的全局定义方式如下所示:

1
2
3
4
5
6
7
<query_log>
<database>system</database>
<table>query_log</table>
<partition_by>toYYYYMM(event_date)</partition_by>
<!-- 刷新周期 -->
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_log>

如果只希望具有某些角色用户才能开启 query_log,那么可以在 users.xml 的用户 profile 中增加一个标签:1。

query_log 开启后,即可通过相应的系统表对记录进行查询。

1
SELECT * FROM system.query_log

返回的日志信息十分完善,涵盖了查询语句、执行时间、返回的数据量和执行用户等。

2. query_thread_log

query_thread_log 记录了所有线程的执行查询的信息,它的全局定义方式如下所示:

1
2
3
4
5
6
7
<query_thread_log>
<database>system</database>
<table>query_thread_log</table>
<partition_by>toYYYYMM(event_date)</partition_by>
<!-- 刷新周期 -->
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_thread_log>

如果只希望具有某些角色用户才能开启 query_log,那么可以在 users.xml 的用户 profile 中增加一个标签:1。

log_query_thread 开启后,即可通过相应的系统表对记录进行查询。

1
SELECT * FROM system.log_query_thread

返回的日志信息十分完善,涵盖了线程名称、查询语句、执行时间、和内存使用量等。

3. part_log

part_log 记录了 MergeTree 系列表引擎的分区操作日志,其全局定义方式如下:

1
2
3
4
5
<part_log>
<database>system</database>
<table>part_log</table>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
</part_log>

part_log 开启后,即可通过相应的系统表对记录进行查询。

1
SELECT * FROM system.part_log

返回的日志信息十分完善,涵盖了操纵类型、表名称、分区信息和执行时间等。

4. text_log

text_log 日志记录了 ClickHouse 运行过程中产生的一系列打印日志,包括 INFO、DEBUG 和 TRACE,它的全局定义方式如下:

1
2
3
4
5
<text_log>
<database>system</database>
<table>text_log</table>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
</text_log>

text_log 开启后,即可通过相应的系统表对记录进行查询。

1
SELECT * FROM system.text_log

返回的日志信息十分完善,涵盖了线程名称、日志对象、日志信息和执行时间等等。

5. metric_log

metric_log 日志用于将 system.metrics 和 system.events 中的数据汇聚到一起,它的全局定义方式如下所示:

1
2
3
4
5
6
7
<metric_log>
<database>system</database>
<table>metric_log</table>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
<!-- 收集 metrics 和 event 的时间 -->
<collect_interval_milliseconds>1000</collect_interval_milliseconds>
</metric_log>

metric_log 开启后,即可通过相应的系统表对记录进行查询。

1
SELECT * FROM system.metric_log

以上就是几种查询日志,当然,除了这些自身的查询日志之外,ClickHouse 还能够与众多的第三方系统集成,比如 Prometheus。当然监控系统又是一个比较大的话题了,这里就不再展开了,有兴趣可以去调研一下。