Set up docs MCP在生产环境中监控数据库系统，对于了解部署的健康状况至关重要， 这样您才能预防或解决服务中断。
高级仪表板是一款轻量级工具，旨在帮助您深入了解 ClickHouse 系统及其运行环境，让您能够提前发现并应对 性能瓶颈、系统故障和低效问题。
高级仪表板在 ClickHouse OSS (开源软件) 和 Cloud 中均可用。本文将向您展示如何在 Cloud 中使用高级仪表板。
访问高级仪表板
可通过以下路径访问高级仪表板：
- 左侧面板
Monitoring→Advanced dashboard
访问原生高级仪表板
可通过以下路径访问原生高级仪表板：
- 左侧面板
Monitoring→Advanced dashboard- 点击
You can still access the native advanced dashboard.
这会在新标签页中打开原生高级仪表板。您需要先完成 身份验证才能访问该仪表板。
每个可视化都关联了一个用于填充数据的 SQL 查询。您可以 点击铅笔图标编辑该查询。
开箱即用的可视化
高级仪表板中的默认图表旨在让您实时了解 ClickHouse 系统的运行状况。下面列出了每个图表及其说明。 为便于查看，这些图表分为三类。
ClickHouse 特有
这些指标专用于监控您的 ClickHouse 实例的健康状况和性能。
| 指标 | 说明 |
|---|---|
| 每秒查询数 | 跟踪查询处理速率 |
| 每秒选中行数 | 表示查询每秒读取的行数 |
| 每秒插入行数 | 衡量数据摄取速率 |
| MergeTree parts 总数 | 显示 MergeTree 表中活跃 parts 的数量，有助于识别未分批的插入操作 |
| 任一分区的最大 parts 数 | 突出显示任一分区中的最大 parts 数量 |
| 运行中的查询数 | 显示当前正在执行的查询数量 |
| 每秒读取字节数 | 表示查询每秒读取的数据量 |
系统健康状况相关
监控底层系统与监控 ClickHouse 本身同样重要。
| 指标 | 说明 |
|---|---|
| IO Wait | 跟踪 I/O 等待时间 |
| CPU Wait | 衡量 CPU 资源争用导致的延迟 |
| Read From Disk | 跟踪从磁盘或块设备读取的字节数 |
| Read From Filesystem | 跟踪从文件系统读取的字节数，包括页缓存 |
| Memory (tracked, bytes) | 显示 ClickHouse 跟踪的进程的内存使用量 |
| Load Average (15 minutes) | 报告系统当前 15 分钟的平均负载 |
| OS CPU Usage (Userspace) | 运行用户态代码时的 CPU 使用率 |
| OS CPU Usage (Kernel) | 运行内核代码时的 CPU 使用率 |
ClickHouse Cloud 特定指标
ClickHouse Cloud 使用对象存储 (S3 类型) 来存储数据。监控该 接口有助于发现问题。
| Metric | Description |
|---|---|
| S3 读取等待 | 衡量发往 S3 的读取请求延迟 |
| S3 每秒读取错误数 | 跟踪读取错误率 |
| 从 S3 读取 (字节/秒) | 跟踪从 S3 存储读取数据的速率 |
| Disk S3 write req/sec | 监控向 S3 存储执行写入操作的频率 |
| Disk S3 read req/sec | 监控从 S3 存储执行读取操作的频率 |
| 页缓存命中率 | 页缓存的命中率 |
| 文件系统缓存命中率 | 文件系统缓存的命中率 |
| 文件系统缓存大小 | 文件系统缓存的当前大小 |
| Network send bytes/sec | 跟踪当前入站网络流量的速度 |
| Network receive bytes/sec | 跟踪当前出站网络流量的速度 |
| 并发网络连接数 | 跟踪当前并发网络连接的数量 |
使用高级仪表板识别问题
通过这种对 ClickHouse 服务健康状况的实时视图，您可以在问题影响业务之前大幅降低其影响，或更快地排查并解决问题。下面列出了一些您可以借助高级仪表板发现的问题。
非批量插入
如最佳实践文档中所述，如果能够以同步方式执行，建议始终将数据批量插入 ClickHouse。
采用合理批次大小的批量插入，可以减少摄取期间创建的 parts 数量， 从而提高磁盘写入效率并减少合并 操作。
用于识别插入未充分优化问题的关键指标是 Inserted Rows/sec 和 Max Parts for Partition
上面的示例显示，在 13h 到 14h 之间，Inserted Rows/sec 和 Max Parts for Partition 都出现了两次峰值。这表明我们正在以合理的速度摄取数据。
随后我们看到，16h 之后 Max Parts for Partition 又出现了一次明显的峰值，但 Inserted Rows/sec speed 却非常低。系统创建了大量 parts， 但生成的数据却很少，这说明这些 parts 的大小 并不理想。
资源密集型查询
运行会消耗大量资源 (如 CPU 或内存) 的 SQL 查询很常见。不过，监控这些查询并了解它们对部署整体性能的影响非常重要。
如果资源消耗突然变化，而查询吞吐量没有变化，则可能表明正在执行开销更高的查询。具体是否属于预期情况取决于您运行的查询类型，但通过高级仪表板识别出这类查询仍然很有帮助。
下面是一个示例：CPU 使用率出现峰值，而每秒执行的查询数量并未明显变化。
糟糕的主键设计
你还可以通过高级仪表板发现另一个问题：主键设计不佳。 如“ClickHouse 主索引实用入门”中所述， 选择最适合自身使用场景的主键，可以通过减少 ClickHouse 在执行查询时需要读取的行数， 显著提升性能。
你可以用来发现主键潜在优化空间的指标之一 是 每秒选中行数。选中行数突然出现峰值， 既可能表明整体查询吞吐量有所上升，也可能意味着某些查询 为执行而选中了大量行。
你可以使用时间戳作为过滤器，在表 system.query_log 中
找出峰值出现时执行的查询。
例如，可以运行一条查询，显示某一天上午 11 点到上午 11 点之间执行的所有查询， 以了解哪些查询读取了过多的行：
SELECT
type,
event_time,
query_duration_ms,
query,
read_rows,
tables
FROM system.query_log
WHERE has(databases, 'default') AND (event_time >= '2024-12-23 11:20:00') AND (event_time <= '2024-12-23 11:30:00') AND (type = 'QueryFinish')
ORDER BY query_duration_ms DESC
LIMIT 5
FORMAT VERTICALRow 1:
──────
type: QueryFinish
event_time: 2024-12-23 11:22:55
query_duration_ms: 37407
query: SELECT
toStartOfMonth(review_date) AS month,
any(product_title),
avg(star_rating) AS avg_stars
FROM amazon_reviews_no_pk
WHERE
product_category = 'Home'
GROUP BY
month,
product_id
ORDER BY
month DESC,
product_id ASC
LIMIT 20
read_rows: 150957260
tables: ['default.amazon_reviews_no_pk']
Row 2:
──────
type: QueryFinish
event_time: 2024-12-23 11:26:50
query_duration_ms: 7325
query: SELECT
toStartOfMonth(review_date) AS month,
any(product_title),
avg(star_rating) AS avg_stars
FROM amazon_reviews_no_pk
WHERE
product_category = 'Home'
GROUP BY
month,
product_id
ORDER BY
month DESC,
product_id ASC
LIMIT 20
read_rows: 150957260
tables: ['default.amazon_reviews_no_pk']
Row 3:
──────
type: QueryFinish
event_time: 2024-12-23 11:24:10
query_duration_ms: 3270
query: SELECT
toStartOfMonth(review_date) AS month,
any(product_title),
avg(star_rating) AS avg_stars
FROM amazon_reviews_pk
WHERE
product_category = 'Home'
GROUP BY
month,
product_id
ORDER BY
month DESC,
product_id ASC
LIMIT 20
read_rows: 6242304
tables: ['default.amazon_reviews_pk']
Row 4:
──────
type: QueryFinish
event_time: 2024-12-23 11:28:10
query_duration_ms: 2786
query: SELECT
toStartOfMonth(review_date) AS month,
any(product_title),
avg(star_rating) AS avg_stars
FROM amazon_reviews_pk
WHERE
product_category = 'Home'
GROUP BY
month,
product_id
ORDER BY
month DESC,
product_id ASC
LIMIT 20
read_rows: 6242304
tables: ['default.amazon_reviews_pk']在这个示例中，我们可以看到同一条查询被执行在两个
表 amazon_reviews_no_pk 和 amazon_reviews_pk 上。由此可以推断，
有人正在为表 amazon_reviews 测试主键选项。