使用高级监控仪表板可以解决的常见问题

在生产环境中监控数据库系统不是可选项；为了预防或解决中断问题，必须概览部署的健康状况。

在 ClickHouse，我们非常了解这一点，因此 ClickHouse 默认配备了一组预定义的高级监控仪表板。高级仪表板是一个轻量级工具，旨在让您深入了解 ClickHouse 系统及其环境，帮助您提前发现性能瓶颈、系统故障和效率低下问题。

高级仪表板在 ClickHouse OSS（开源软件）和云版本中均可用。无论您是管理高查询负载的数据工程师，还是负责 ClickHouse 正常运行时间的 SRE 专业人员，高级仪表板都能让您有效地监控和排除问题。

高级仪表板开箱即用。根据您的环境，您可能需要启用 metric_log 和 asynchronous_metric_log 以填充默认的可视化图表。如果您在 ClickHouse Cloud 中运行，这些日志默认已启用，因此无需额外设置。

要启用这些日志，如全局设置文档中所述，请编辑服务器配置文件 /etc/clickhouse-server/config.d/metric_log.xml

<clickhouse>
    <metric_log>
        <database>system</database>
        <table>metric_log</table>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <collect_interval_milliseconds>1000</collect_interval_milliseconds>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
    </metric_log>
    <asynchronous_metric_log>
        <database>system</database>
        <table>asynchronous_metric_log</table>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <collect_interval_milliseconds>1000</collect_interval_milliseconds>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
    </asynchronous_metric_log>
</clickhouse>

一旦 ClickHouse 服务器运行，高级仪表板就可以在以下位置访问：

<your_clickhouse_url>/dashboard

默认情况下，您可以使用 default 用户登录来访问仪表板。但是，建议您为此目的设置特定的用户。

要运行默认可视化图表，用户需要读取权限才能访问：

• 表 system.dashboards：这是存储可视化定义的地方。
• 表 system.metric_log：包含来自表 system.metrics 和 system.events 的指标值的历史记录。
• 表 system.asynchronous_metric_log：包含 system.asynchronous_metrics 的历史值

访问用户还需要两个特殊授权：CREATE TEMPORARY TABLE ON *.*  和 REMOTE ON *.*

让我们为实验创建一个仪表板用户

  
1-- Create dashboard user
2CREATE USER dashboard_user IDENTIFIED BY ;
3
4-- Create dashboard role and assign to dashboard_user
5CREATE ROLE dashboard;
6GRANT dashboard TO dashboard_user;
7
8-- Grant rights to access advanced dashboards
9GRANT REMOTE ON *.* to dashboard;
10GRANT CREATE TEMPORARY TABLE on *.* to dashboard;
11GRANT SELECT ON system.metric_log to dashboard;
12GRANT SELECT ON system.asynchronous_metric_log to dashboard;
13GRANT SELECT ON system.dashboards to dashboard;

用户名可以作为 URL 参数提供：<your_clickhouse_url>/dashboard?user=dashboard。

输入您创建仪表板用户时使用的密码以登录。

您可以在顶部栏看到应用程序用于加载仪表板定义的 SQL 查询。

  
1-- Load dashboard definition
2SELECT title, query FROM system.dashboards WHERE dashboard = 'Overview'

仪表板字段中的查询过滤器设置为“Overview”。不同的仪表板集专为特定目的而设计。默认情况下，一个仪表板集用于本地部署（“Overview”），另一个用于云部署（“Cloud Overview”）。

高级仪表板中的默认图表旨在提供对 ClickHouse 系统的实时可见性。以下是每个图表的列表及其描述。它们分为三个类别，以帮助您浏览。

ClickHouse 特有:

这些指标是专门为监控 ClickHouse 实例的健康状况和性能而定制的。

• 每秒查询数：跟踪正在处理的查询速率。
• 每秒选择行数：指示查询正在读取的行数。
• 每秒插入行数：衡量数据摄取率。
• MergeTree Parts 总数：显示 MergeTree 表中活动部件的数量，帮助识别未批量插入。
• 每个分区的最大部件数：突出显示任何分区中的最大部件数。
• 正在运行的查询：显示当前正在执行的查询数。
• 每秒选择字节数：指示查询正在读取的数据量。

系统健康状况特定:

监控底层系统与监控 ClickHouse 本身同样重要。

• IO 等待： 跟踪 I/O 等待时间。
• CPU 等待：衡量由 CPU 资源争用引起的延迟
• 从磁盘读取：跟踪从磁盘或块设备读取的字节数
• 从文件系统读取：跟踪从文件系统读取的字节数，包括页面缓存。
• 内存（已跟踪，字节）：显示 ClickHouse 跟踪的进程的内存使用情况。
• 负载平均值（15 分钟）：报告系统当前的 15 分钟负载平均值
• OS CPU 使用率（用户空间）：运行用户空间代码的 CPU 使用率
• OS CPU 使用率（内核）：运行内核代码的 CPU 使用率

ClickHouse Cloud 特有:

ClickHouse Cloud 使用对象存储（S3 类型）存储数据。监控此接口可以帮助检测问题。

• S3 读取等待：衡量对 S3 的读取请求的延迟。
• 每秒 S3 读取错误数：跟踪读取错误率。 
• 从 S3 读取（字节/秒）：跟踪从 S3 存储读取数据的速率。
• 磁盘 S3 写入请求/秒： 监控对 S3 存储的写入操作频率。
• 磁盘 S3 读取请求/秒： 监控对 S3 存储的读取操作频率。
• 页面缓存命中率：页面缓存的命中率 
• 文件系统缓存命中率：文件系统缓存的命中率
• 文件系统缓存大小：文件系统缓存的当前大小
• 网络发送字节/秒：跟踪传入网络流量的当前速度
• 网络接收字节/秒：跟踪传出网络流量的当前速度
• 并发网络连接数：跟踪当前并发网络连接数

每个可视化图表都有一个与其关联的 SQL 查询，用于填充它。您可以通过单击笔图标来编辑此查询。

在那里，您可以编辑查询以满足您的需求。您还可以添加自己的图表。单击“添加图表”，并在新添加的图表中编辑查询。例如，让我们添加一个图表来跟踪主键使用的内存。以下是为可视化图表提供支持的 SQL 查询。

  
1SELECT toStartOfInterval(event_time, INTERVAL {rounding:UInt32} SECOND)::INT AS t, avg(value) FROM merge('system', '^asynchronous_metric_log') WHERE event_date >= toDate(now() - {seconds:UInt32}) AND event_time >= now() - {seconds:UInt32} AND metric = 'TotalPrimaryKeyBytesInMemory' GROUP BY t ORDER BY t WITH FILL STEP {rounding:UInt32}

请注意，通过 Web 应用程序添加的图表仅编码为查询参数，使其易于添加书签。

如果您想要更强大的方法，可以直接将新的可视化图表存储在 ClickHouse 中。

首先，创建一个与默认 system.dashboards 表具有相同模式的新表。

  
1-- Create a separate database
2CREATE DATABASE custom;
3
4-- Create the custom dashboard table
5CREATE TABLE custom.dashboards
6(
7    `dashboard` String,
8    `title` String,
9    `query` String
10) ORDER BY ()

然后在表中插入您的自定义可视化图表。

  
1-- Total size primary keys visualization query
2INSERT INTO custom.dashboards (dashboard, title, query)
3VALUES (
4    'Overview',
5    'Total primary keys size',
6    'SELECT toStartOfInterval(event_time, INTERVAL {rounding:UInt32} SECOND)::INT AS t, avg(value) FROM merge(\'system\', \'^asynchronous_metric_log\') WHERE event_date >= toDate(now() - {seconds:UInt32}) AND event_time >= now() - {seconds:UInt32} AND metric = \'TotalPrimaryKeyBytesInMemory\' GROUP BY t  ORDER BY t WITH FILL STEP  {rounding:UInt32}'
7);

使用此查询，您可以将自定义数据库中的仪表板定义与 Web 应用程序中的默认定义合并。

  
1SELECT title, query FROM merge(REGEXP('custom|system'),'dashboards') WHERE dashboard = 'Overview'

确保仪表板用户具有访问自定义数据库的正确授权。

实时查看 ClickHouse 服务的健康状况，极大地有助于在问题影响业务之前缓解问题或帮助解决问题。以下是您可以使用高级仪表板发现的一些问题。

如最佳实践文档中所述，建议始终将数据批量插入到 ClickHouse 中。

具有合理批处理大小的批量插入减少了数据摄取期间创建的部件数量，从而提高了磁盘写入效率并减少了合并操作。 

发现次优插入的关键指标是每秒插入行数和每个分区的最大部件数。

上面的示例显示了 13 点到 14 点之间每秒插入行数和每个分区的最大部件数的两个峰值。这表明我们以合理的速度摄取数据。

然后我们看到 16 点之后每个分区的最大部件数出现另一个大峰值，但每秒插入行数速度非常慢。创建了大量部件，但生成的数据很少，这表明部件的大小不是最优的。

运行消耗大量资源（如 CPU 或内存）的 SQL 查询是很常见的。但是，监控这些查询并了解它们对部署整体性能的影响非常重要。

在查询吞吐量没有变化的情况下，资源消耗突然变化可能表明正在执行更昂贵的查询。根据您正在运行的查询类型，这可能是预期的，但从高级仪表板中发现它们是很有好处的。 

以下是 CPU 使用率达到峰值但每秒执行的查询数没有显着变化的示例。

您可以使用高级仪表板发现的另一个问题是不良的主键设计。如文档中所述，选择最适合您用例的主键将通过减少 ClickHouse 执行查询需要读取的行数来大大提高性能。

您可以跟踪以发现主键潜在改进的指标之一是每秒选择行数。选择行数突然达到峰值可能表明整体查询吞吐量普遍增加，以及查询选择大量行来执行其查询。

使用时间戳作为过滤器，您可以在表 system.query_log 中找到峰值时执行的查询。

让我们运行一个查询，显示 11:20 上午到 11:30 上午之间执行的所有查询，以了解哪些查询读取了太多行。 

  
1SELECT
2    type,
3    event_time,
4    query_duration_ms,
5    query,
6    read_rows,
7    tables
8FROM system.query_log
9WHERE has(databases, 'default') AND (event_time >= '2024-12-23 11:20:00') AND (event_time <= '2024-12-23 11:30:00') AND (type = 'QueryFinish')
10ORDER BY query_duration_ms DESC
11LIMIT 5
12FORMAT VERTICAL
13
14Row 1:
15──────
16type:              QueryFinish
17event_time:        2024-12-23 11:22:55
18query_duration_ms: 37407
19query:             SELECT
20    toStartOfMonth(review_date) AS month,
21    any(product_title),
22    avg(star_rating) AS avg_stars
23FROM amazon_reviews_no_pk
24WHERE
25    product_category = 'Home'
26GROUP BY
27    month,
28    product_id
29ORDER BY
30    month DESC,
31    product_id ASC
32LIMIT 20
33read_rows:         150957260
34tables:            ['default.amazon_reviews_no_pk']
35
36Row 2:
37──────
38type:              QueryFinish
39event_time:        2024-12-23 11:26:50
40query_duration_ms: 7325
41query:             SELECT
42    toStartOfMonth(review_date) AS month,
43    any(product_title),
44    avg(star_rating) AS avg_stars
45FROM amazon_reviews_no_pk
46WHERE
47    product_category = 'Home'
48GROUP BY
49    month,
50    product_id
51ORDER BY
52    month DESC,
53    product_id ASC
54LIMIT 20
55read_rows:         150957260
56tables:            ['default.amazon_reviews_no_pk']
57
58Row 3:
59──────
60type:              QueryFinish
61event_time:        2024-12-23 11:24:10
62query_duration_ms: 3270
63query:             SELECT
64    toStartOfMonth(review_date) AS month,
65    any(product_title),
66    avg(star_rating) AS avg_stars
67FROM amazon_reviews_pk
68WHERE
69    product_category = 'Home'
70GROUP BY
71    month,
72    product_id
73ORDER BY
74    month DESC,
75    product_id ASC
76LIMIT 20
77read_rows:         6242304
78tables:            ['default.amazon_reviews_pk']
79
80Row 4:
81──────
82type:              QueryFinish
83event_time:        2024-12-23 11:28:10
84query_duration_ms: 2786
85query:             SELECT
86    toStartOfMonth(review_date) AS month,
87    any(product_title),
88    avg(star_rating) AS avg_stars
89FROM amazon_reviews_pk
90WHERE
91    product_category = 'Home'
92GROUP BY
93    month,
94    product_id
95ORDER BY
96    month DESC,
97    product_id ASC
98LIMIT 20
99read_rows:         6242304
100tables:            ['default.amazon_reviews_pk']

在我们的示例中，我们可以看到针对两个表 amazon_reviews_no_pk 和 amazon_reviews_pk 执行了相同的查询。我们可以假设有人正在测试表 amazon_reviews 的主键选项。

在这篇博文中，我们了解了 ClickHouse 中的高级仪表板功能，如何开始使用它以及我们可以使用它解决或检测到的一些常见问题。

无论您的部署选项如何，此轻量级监控工具都可与 ClickHouse 开箱即用。

话虽如此，如果您希望使用您首选的监控工具监控 ClickHouse，我们鼓励您使用文档示例进行操作，包括 Promotheus。

最后，您还可以探索新的 ClickHouse Cloud 独有的仪表板功能，该功能允许您创建更丰富的可视化效果。