ClickHouse 的管理与运维
ClickHouse 管理和运维相关的知识，该部分可以让 ClickHouse 变得更加安全与健壮。在前面演示的案例中，为了方便，我们一直使用默认的 default 用户，并且没有配置密码，这显然不符合生产环境的要求。

接下来，我们就来介绍 ClickHouse 的权限、熔断机制、数据备份和服务监控等知识。

docker start docker-clickhouse
docker exec -it docker-clickhouse /bin/bash
clickhouse-client
clickhouse-client --host 地址 --port 端口 --user 用户 --password 密码
clickhouse-client --user default --password bigdata

1 用户配置

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

1.1 用户的角色配置(profile)

在users.xml中有一个profiles标签，在该标签中我们可以定义用户角色。

一、默认配置：

<!-- Profiles of settings. -->
<profiles>
     <!-- Default settings. -->
     <default>
         <!-- Maximum memory usage for processing single query, in bytes. -->
          <!-- 处理单个查询的最大内存使用量,大概10G -->
         <max_memory_usage>10000000000</max_memory_usage>

         <!-- How to choose between replicas during distributed query processing.
         如何在分布式查询处理过程中选择副本。
         (1)random
         (2)nearest_hostname
         (3)in_order
         (4)first_or_random
         -->
         <load_balancing>random</load_balancing>
     </default>

     <!-- Profile that allows only read queries. -->
     <readonly>
         <readonly>1</readonly>
     </readonly>
 </profiles>

(1)random - choose random replica from set of replicas with minimum number of errors.
随机-从具有最小错误数的副本集中选择随机副本。
(2)nearest_hostname - from set of replicas with minimum number of errors, choose replica with minimum number of different symbols between replica’s hostname and local hostname (Hamming distance).
从具有最小错误数的副本集中选择副本，复制副本的主机名和本地主机名之间具有最小数量的不同符号（汉明距离）。
(3)in_order - first live replica is chosen in specified order.
按指定顺序选择第一个活动副本。
(4)first_or_random - if first replica one has higher number of errors, pick a random one from replicas with minimum number of errors.
如果第一个副本的错误数较高，请从错误数最少的副本中选择一个随机副本。

这是 ClickHouse 的默认配置，显然默认有两个角色，分别是 default 和 readonly。需要注意的是，这里的 default 和 readonly 指的是角色，每一个用户都具有一个角色。

二、切换角色
我们可以在 CLI 中直接切换到想要的角色：

SET profile = '角色名'

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

(1)默认为default角色，读写正常
insert into t1 values('lucy',[1,2]);
select * from t1;
┌─title─┬─value─┐
│ lucy  │ [1,2] │
└───────┴───────┘
(2)将角色切换为readonly
set profile = 'readonly';

(3)写入数据失败，查询成功
insert into t1 values('lily',[3,4]);
DB::Exception: 
default: Cannot execute query in readonly mode. (READONLY)

当default用户具有default角色时，写数据一切正常，但是将default用户的角色切换为readonly时则被告知：Cannot execute query in readonly mode。

如果我们在default角色对应配置中也加上 
<readonly>1</readonly>
那么具有该角色的用户同样也会无法写数据。

在所有的角色配置（profile）中，名称为default的profile将作为默认的配置被加载，所以它必须存在。如果缺失名为 default 的 profile，那么 ClickHouse Server 会启动失败： Application: DB::Exception: Settings profile default not found。

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

<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 配置项。

1.2 配置约束

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

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

下面举例说明：

<!-- Profiles of settings. -->
<profiles>
     <!-- Default settings. -->
     <default>
         <!-- Maximum memory usage for processing single query, in bytes. -->
          <!-- 处理单个查询的最大内存使用量,大概10G -->
         <max_memory_usage>10000000000</max_memory_usage>

         <!-- How to choose between replicas during distributed query processing.
         如何在分布式查询处理过程中选择副本。
         (1)random
         (2)nearest_hostname
         (3)in_order
         (4)first_or_random
         -->
         <load_balancing>random</load_balancing>
         <!-- 给default角色设置约束，以后角色为default的用户都会受到此约束-->
         <constraints>
         	<!--最大值和最小值的约束-->
         	<max_memory_usage>
         		<min>5000000000</min>
         		<max>20000000000</max>
         	</max_memory_usage>
         	<!--属性不可修改-->
         	<distributed_product_mode>
         		<readonly/>
         	</distributed_product_mode>
         </constraints>
     </default>

     <!-- Profile that allows only read queries. -->
     <readonly>
         <readonly>1</readonly>
     </readonly>
 </profiles>

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

set max_memory_usage = 50;
报错
DB::Exception: Setting max_memory_usage shouldn't be 
less than 5000000000. (SETTING_CONSTRAINT_VIOLATION)

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

set distributed_product_mode = 'allow';
报错
DB::Exception: Setting distributed_product_mode 
should not be changed. (SETTING_CONSTRAINT_VIOLATION)

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

1.3 用户

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

<!-- Users and ACL. -->
<users>
    <!-- If user name was not specified, 'default' user is used. -->
    <default>
        <!-- See also the files in users.d directory where the password can be overridden.-->
        <password>bigdata</password>

        <!-- List of networks with open access.
             To open access from everywhere, specify:
                <ip>::/0</ip>
             To open access only from localhost, specify:
                <ip>::1</ip>
                <ip>127.0.0.1</ip>
        -->
        <networks>
            <ip>::/0</ip>
        </networks>

        <!-- Settings profile for user. -->
        <profile>default</profile>

        <!-- Quota for user. -->
        <quota>default</quota>

        <!-- User can create other users and grant rights to them. -->
        <!-- <access_management>1</access_management> -->
    </default>
</users>

1.3.1 password

password 用于设置登录密码，支持明文(plaintext)、SHA256(in hex format)加密和 double_sha1 加密三种形式，可以任选其中一种进行设置。
Password could be specified in or in SHA256
(1)明文密码
在使用明文密码的时候，直接通过password标签定义，例如下面的代码。

<password>123</password>
如果 password 为空，则表示免密码登录。
<password></password>

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

<password_sha256_hexs>a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3</password_sha256_hexs>

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

# echo -n 123 |openssl dgst -sha256
(stdin)= a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3

或者使用 Python：

>>> import hashlib
>>> hashlib.sha256(b"123").hexdigest()
'a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3'
>>>

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

<password_double_sha1_hex>23ae809ddacaf96af0fd78ed04b6a265e05aa257</password_double_sha1_hex>

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

# echo -n 123 | openssl dgst -sha1 -binary | openssl dgst -sha1
(stdin)= 23ae809ddacaf96af0fd78ed04b6a265e05aa257

或者使用 Python：

>>> import hashlib
>>> _ = hashlib.sha1(b"123").digest()
>>> hashlib.sha1(_).hexdigest()
'23ae809ddacaf96af0fd78ed04b6a265e05aa257'

1.3.2 networks

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

1.3.3 profile

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

<profile>profile_1</profile>

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

1.3.4 quota

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

1.3.5 举例

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

<users>
    <default>  <!-- 默认用户 -->
        ...
    </default>
    
    <!-- 使用明文密码 -->
    <user1_plaintext>
        <password>123</password>
        <networks>
            <ip>::/0</ip>
        </networks>
        <profile>default</profile>
        <quota>default</quota>
    </user1_plaintext>
    
    <!-- 使用 sha256 加密 -->
    <user2_sha256>
        <password_sha256_hex>a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3</password_sha256_hex>
        <networks>
            <ip>::/0</ip>
        </networks>
        <profile>default</profile>
        <quota>default</quota>
    </user2_sha256>
    
    <!-- 使用 double sha1 加密 -->
    <user3_double_sha1>
        <password_double_sha1_hex>23ae809ddacaf96af0fd78ed04b6a265e05aa257</password_double_sha1_hex>
        <networks>
            <ip>::/0</ip>
        </networks>
        <profile>default</profile>
        <quota>default</quota>
    </user3_double_sha1>    
</users>

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

clickhouse-client --user user1_plaintext --password 123
配置文件中写的是加密后的结果，但是登录时，密码还是使用加密前的结果，这里是123
clickhouse-client --user user2_sha256 --password 123
clickhouse-client --user user3_double_sha1 --password 123

2 权限管理

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

2.1 访问权限

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

2.1.1 网络访问权限

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

比如通过 IP 地址设置：

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

通过 host 主机名称设置：

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

2.1.2 数据库与字典访问权限

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

<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>

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

2.2 查询权限

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

(1)读权限：包括SELECT、EXISTS、SHOW和DESCRIBE查询。
(2)写权限：包括INSERT和OPTIMIZE查询。
(3)设置权限：包括SET查询。
(4)DDL权限：包括CREATE、DROP、ALTER、RENAME、ATTACH、DETACH和TRUNCATE查询。
(5)其它权限：包括KILL和USE查询，任何用户都可以执行这些查询。

上述权限，可以通过以下两项配置标签控制：
(1)readonly：读权限、写权限和设置权限均由此标签控制，它有三种取值：
当取值为0时，表示不进行任何限制（默认值）
当取值为1时，表示只拥有读权限，即只能执行 SELECT 、EXISTS、SHOW 和 DESCRIBE
当取值为2时，表示拥有读权限和设置权限，相当于在读权限的基础上增加了 SET 查询
(2)allow_ddl：DDL 权限由此标签控制，它有两种取值：
当取值为 0 时，不允许 DDL 查询
当取值为 1 时，允许 DDL 查询（默认值）
举个栗子，我们增加一个角色。

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

修改配置文件之后，重启 ClickHouse，然后连接：

create database test;
set profile = 'profile_test';
drop database test;

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

2.3 数据行级权限

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

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

<databases>
    <database_name>  <!-- 数据库名称 -->
        <table_name> <!-- 表名称 -->
            <fileter>id > 10</fileter>  <!-- 数据过滤条件，也可以写复杂的条件 -->
        </table_name>
    </database_name>
</databases>

我们以之前的表t1 为例，测试一下，所以配置文件修改如下：

<user_test_2>  <!-- 新建一个用户 -->
    <password>123</password>
    <networks>
        <ip>::/0</ip>
    </networks>
    <profile>default</profile>
    <quota>default</quota>
    
    <databases>
        <default>  
            <t1> 
                <filter>id >2</filter>  
            </t1>
        </default>
    </databases>
</user_test_2>

修改配置文件之后，重启 ClickHouse，然后连接：

clickhouse-client --user default --password bigdata

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

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

3 熔断机制

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

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

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

<!-- Quotas. -->
<quotas>
    <!-- Name of quota. -->
    <default>
        <!-- Limits for time interval. You could specify many intervals with different limits. -->
        <interval>
            <!-- Length of interval. -->
            <duration>3600</duration>

            <!-- No limits. Just calculate resource usage for time interval. -->
            <queries>0</queries>
            <errors>0</errors>
            <result_rows>0</result_rows>
            <read_rows>0</read_rows>
            <execution_time>0</execution_time>
        </interval>
    </default>
</quotas>
</clickhouse>

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

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

我们来配置一下：

<!-- 在 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 用户上。

<user_test_2> 
    ...
    <quota>limit_1</quota> <!-- 其它部分不变，将 quota 的值从 default 改成 limit_1 -->
    ...
</user_test_2>

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

clickhouse-client --user user_test_2 --password 123
报错
Code: 201. DB::Exception: Received from localhost:9000.
 DB::Exception: Quota for user `user_test_2` for 3600s 
 has been exceeded: queries = 4/2. 
 Interval will end at 2022-11-19 05:00:00. 
 Name of quota template: `limit_1`. (QUOTA_EXPIRED)

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

3.2 根据单次查询的用量熔断

在这种方式下，系统资源的用量是按照单次查询统计的，而具体的熔断规则，则是由许多不同配置项组成的，这些配置项需要定义在用户 profile 中。如果某次查询使用的资源用量达到了阈值，则会被中断。以配置项 max memory_usage 为例，它限定了单次查询可以使用的内存用量，在默认的情况下其规定不得超过 10 GB，如果一次查询的内存用量超过 10 GB，则会得到异常。

需要注意的是，在单次查询的用量统计中，ClickHouse 是以分区为最小单元进行统计的（不是数据行的粒度），这意味着单次查询的实际内存用量是有可能超过阈值的。

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

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

<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 个。如果超过这个阈值，将会出现异常。

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，不做限制。当超过阈值时，聚合查询将会进一步借用本地磁盘。

4 数据备份

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

4.1 导出文件备份

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

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

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

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

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

4.2 通过快照表备份

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

CREATE TABLE table_name_bak AS table_name

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

INSERT INTO table_name_bak SELECT * FROM table_name

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

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

4.3 按分区备份

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

5 服务监控

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

5.1 系统表

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

5.1.1 metrics

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

select * from system.metrics limit 5;

metric         |value|description                                    |
---------------+-----+-----------------------------------------------+
Query          |    0|Number of executing queries                    |
Merge          |    0|Number of executing background merges          |
PartMutation   |    0|Number of mutations (ALTER DELETE/UPDATE)      |
ReplicatedFetch|    0|Number of data parts being fetched from replica|
ReplicatedSend |    0|Number of data parts being sent to replicas    |

5.1.2 events

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

select event,value from system.events limit 5;

event                |value|
---------------------+-----+
Query                |    9|
SelectQuery          |    8|
FailedQuery          |    3|
FailedSelectQuery    |    2|
QueryTimeMicroseconds|11061|

5.1.3 asynchronous_metrics

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

select * from system.asynchronous_metrics limit 5;

metric                          |value    |
--------------------------------+---------+
jemalloc.arenas.all.muzzy_purged|5077730.0|
BlockDiscardBytes_dm-0          |      0.0|
jemalloc.arenas.all.dirty_purged|5303889.0|
BlockDiscardBytes_sda           |      0.0|
jemalloc.arenas.all.pdirty      |   2253.0|

5.2 查询日志

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

5.2.1 query_log

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

<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 中增加一个标签：<log_queries>1</log_querie>。
query_log 开启后，即可通过相应的系统表对记录进行查询。

SELECT * FROM system.query_log

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

5.2.2 query_thread_log

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

<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 中增加一个标签：<log_query_thread>1</log_query_thread>。
log_query_thread 开启后，即可通过相应的系统表对记录进行查询。

SELECT * FROM system.log_query_thread

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

5.2.3 part_log

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

<part_log>
    <database>system</database>
    <table>part_log</table>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</part_log>

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

SELECT * FROM system.part_log

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

5.2.4 text_log

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

<text_log>
    <database>system</database>
    <table>text_log</table>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</text_log>

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

SELECT * FROM system.text_log

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

5.2.5 metric_log

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

<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 开启后，即可通过相应的系统表对记录进行查询。

SELECT * FROM system.metric_log

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