ClickHouse系统表和监控指标、监控工具和平台

目录

1. 系统表和监控指标

1.1 如何查看服务状态

1.2 ClickHouse系统表

1.2.1 system.tables表

1.2.2 system.columns表

1.2.3 system.databases表

1.2.4 system.metrics表

1.2.5 system.events表

1.2.6 system.processes表

1.2.7 system.asynchronous_metrics表

1.3 ClickHouse系统日志表

1.3.1 metric_log表

1.3.2 system.query_log表

1.3.3 system.query_thread_log表

1.3.4 system.trace_log表

1.3.5 system.part_log表

1.3.6 system.crash_log表

1.3.7 system.text_log表

1.4 ClickHouse常用的监控指标

2. 监控工具和平台

2.1 监控工具和平台-常用监控工具简介

2.2 集成第三方监控平台（如Grafana、Zabbix等）

2.2.1 如何使用Grafana监控ClickHouse

2.2.2 如何安装并配置Grafana

2.2.3 如何安装ClickHouse插件

2.2.4 如何配置数据源

2.2.5 如何创建仪表盘

2.2.6 如何使用Zabbix监控ClickHouse？

2.2.7 如何安装Zabbix

2.2.8 如何配置Zabbix来监控ClickHouse

2.2.9 如何导入Zabbix模板

2.2.10 Zabbix能监控ClickHouse哪些指标

2.2.11 如何查看Zabbix监控结果

2.2.12 如何使用Datadog监控ClickHouse

2.2.13 如何安装Datadog

2.2.14 如何查看Datadog监控结果

---

1. 系统表和监控指标

ClickHouse提供了一些系统表，可以用来查看服务器的状态、进程以及环境，以及服务器的内部进程。这些系统表存储在`system`数据库中，仅提供数据读取功能。大多数系统表将其数据存储在RAM中，而系统日志表（如`metric_log`, `query_log`, `query_thread_log`, `trace_log`, `part_log`, `crash_log`和`text_log`）默认采用MergeTree引擎并将其数据存储在文件系统中。

1.1 如何查看服务状态

可以通过多种方式查看ClickHouse服务器的状态。例如，可以通过观察服务器日志来跟踪服务器事件。此外，ClickHouse服务本身具有用于自我状态监视的指标，可以在`system.metrics`，`system.events`以及`system.asynchronous_metrics`等系统表中查看所有的指标项。

还可以通过HTTP API监视服务器可用性，例如将HTTP GET请求发送到/ping。如果服务器可用，它将以200 OK响应。

要查看ClickHouse服务器的状态，您可以使用以下命令：`sudo systemctl status clickhouse-server`。这将显示有关ClickHouse服务器进程的信息，包括其运行状态和最近的日志条目。

此外，您还可以通过查询系统表`system.processes`来查看后台进程。要执行此操作，您可以使用ClickHouse客户端或任何支持SQL查询的工具连接到ClickHouse服务器，并运行以下查询：`SELECT * FROM system.processes`。这将返回有关当前正在运行的查询的信息，包括它们的用户、查询ID、查询文本、持续时间和内存使用情况。

1.2 ClickHouse系统表

ClickHouse有许多有用的系统表，它们提供有关服务器状态、进程和环境以及服务器内部进程的信息。这些系统表位于system数据库中，仅可用于读取数据，不能删除或更改，但可以分离。

- system.tables：包含服务器知道的每个表的元数据。
- system.columns：包含每个表中每个列的元数据。
- system.databases：包含每个数据库的元数据。

此外，还有一些系统日志表，如metric_log、query_log、query_thread_log、trace_log、part_log、crash_log和text_log。它们由MergeTree表引擎提供服务，并默认将其数据存储在文件系统中。

1.2.1 system.tables表

ClickHouse的system.tables表包含服务器知道的每个表的元数据。它包含以下列:

- database (String) - 表所在的数据库名称。
- name (String) - 表名。
- engine (String) - 表引擎名称（不带参数）。
- is_temporary (UInt8) - 指示表是否为临时表的标志。
- data_paths (Array(String)) - 文件系统中表数据的路径。
- metadata_path (String) - 文件系统中表元数据的路径。
- metadata_modification_time (DateTime) - 表元数据最近修改时间。
- create_table_query (String) - 用于创建表的查询。
- engine_full (String) - 表引擎的参数。

1.2.2 system.columns表

ClickHouse的system.columns表包含所有表中列的信息。你可以使用这个表来获得类似于DESCRIBE TABLE查询的信息，但是可以同时获得多个表的信息。临时表中的列只在创建它们的会话中的system.columns中才可见，并且它们的database字段显示为空。

system.columns表包含以下列:

- database (String) - 数据库名称。
- table (String) - 表名。
- name (String) - 列名。
- type (String) - 列类型。
- position (UInt64) - 表中列的序号，从1开始。
- default_kind (String) - 默认值的表达式类型（DEFAULT、MATERIALIZED、ALIAS），如果未定义，则为空字符串。
- default_expression (String) - 默认值的表达式，如果未定义，则为空字符串。

例如，你可以使用以下查询来查看system.numbers表中所有列的名称和类型：

SELECT name, type FROM system.columns WHERE table = 'numbers'

这将返回以下结果：

┌─name────┬─type───┐
│ number  │ UInt64 │
└─────────┴────────┘

1.2.3 system.databases表

 ClickHouse的system.databases表包含当前用户可用的数据库的信息。它包含以下列:

- name (String) - 数据库名称。
- engine (String) - 数据库引擎。
- data_path (String) - 数据路径。
- metadata_path (String) - 元数据路径。

例如，你可以使用以下查询来查看当前用户可用的所有数据库：

SELECT * FROM system.databases

这将返回类似于以下的结果：

┌─name────────────┬─engine───┬─data_path────────────────────┬─metadata_path──────────────────────────────┐
│ default         │ Ordinary │ /var/lib/clickhouse/data/    │ /var/lib/clickhouse/metadata/default.sql   │
│ system          │ Ordinary │ /var/lib/clickhouse/data/    │ /var/lib/clickhouse/metadata/system.sql    │
│ _temporary_and_external_tables│ Ordinary │ /var/lib/clickhouse/data/    │                                            │
└─────────────────┴──────────┴─────────────────────────────┴

1.2.4 system.metrics表

`system.metrics`表包含可以即时计算或具有当前值的指标。例如，同时处理的查询数量或当前的复制延迟。它的列包括：

- `metric` (String) - 指标名称。
- `value` (Int64) - 指标的值。
- `description` (String) - 指标的描述。

查看指标名称：

SELECT metric FROM system.metrics

查看同时处理的查询数量：

`SELECT value FROM system.metrics WHERE metric = 'Query'`

这将返回一个值，表示当前正在处理的查询数量。

1.2.5 system.events表

`system.events`表包含有关系统中发生的事件数量的信息。它的列包括：

- `event` (String) - 事件名称。
- `value` (UInt64) - 发生的事件数量。
- `description` (String) - 事件描述。

仅查看SELECT查询事件的数量：

SELECT value FROM system.events WHERE event = 'SelectQuery'

1.2.6 system.processes表

ClickHouse的system.processes表用于实现SHOW PROCESSLIST查询¹。它包含以下列:

- user (String) - 发出查询的用户。请注意，对于分布式处理，查询在默认用户下发送到远程服务器。该字段包含特定查询的用户名，而不是该查询启动的查询的用户名。
- address (String) - 请求发出的IP地址。对于分布式处理也是如此。要跟踪分布式查询最初从哪里发出，请在查询请求服务器上查看system.processes。
- elapsed (Float64) - 自请求执行开始以来经过的时间（以秒为单位）。
- rows_read (UInt64) - 从表中读取的行数。对于分布式处理，在请求服务器上，这是所有远程服务器的总和。
- bytes_read (UInt64) - 从表中读取的未压缩字节数。对于分布式处理，在请求服务器上，这是所有远程服务器的总和。
- total_rows_approx (UInt64) - 应读取的行总数的近似值。对于分布式处理，在请求服务器上，这是所有远程服务器的总和。在请求处理期间，当新的要处理的源变得已知时，它可以更新。
- memory_usage (UInt64) - 请求使用的RAM量。它可能不包括某些类型的专用内存。请参阅max_memory_usage设置。
- query (String) - 查询文本。对于INSERT，它不包括要插入的数据。
- query_id (String) - 查询ID（如果定义）。
- is_cancelled (Int8) - 查询是否已取消。
- is_all_data_sent (Int8) - 是否将所有数据发送给客户端（换句话说，查询已在服务器上完成）。

1.2.7 system.asynchronous_metrics表

 ClickHouse的system.asynchronous_metrics表包含在后台定期计算的指标，例如正在使用的RAM数量。

system.asynchronous_metrics表包含以下列:

- metric (String) - 指标名称。
- value (Float64) - 指标值。

例如，你可以使用以下查询来查看当前使用的RAM数量：

SELECT value FROM system.asynchronous_metrics WHERE metric = 'MemoryTracking'

这将返回类似于以下的结果：

┌──────value─┐
│ 1234567890 │
└────────────┘

1.3 ClickHouse系统日志表

1.3.1 metric_log表

`system.metric_log`表包含了`system.metrics`和`system.events`表中度量值的历史记录，定期刷新到磁盘。它的列包括：

- `event_date` (Date) - 事件发生的日期。
- `event_time` (DateTime) - 事件发生的时间。
- `milliseconds` (UInt64) - 事件发生的时间（以毫秒为单位）。
- `ProfileEvent_Query` (UInt64) - 查询事件的数量。
- `ProfileEvent_SelectQuery` (UInt64) - SELECT查询事件的数量。
- `ProfileEvent_InsertQuery` (UInt64) - INSERT查询事件的数量。
- `ProfileEvent_FileOpen` (UInt64) - 文件打开事件的数量。
- `ProfileEvent_Seek` (UInt64) - 文件查找事件的数量。
- `ProfileEvent_ReadBufferFromFileDescriptorRead` (UInt64) - 从文件描述符读取缓冲区事件的数量。
- `ProfileEvent_ReadBufferFromFileDescriptorReadFailed` (UInt64) - 从文件描述符读取缓冲区失败事件的数量。
- `ProfileEvent_ReadBufferFromFileDescriptorReadBytes` (UInt64) - 从文件描述符读取缓冲区字节数。
- `ProfileEvent_WriteBufferFromFileDescriptorWrite` (UInt64) - 向文件描述符写入缓冲区事件的数量。
- `ProfileEvent_WriteBufferFromFileDescriptorWriteFailed` (UInt64) - 向文件描述符写入缓冲区失败事件的数量。
- `ProfileEvent_WriteBufferFromFileDescriptorWriteBytes` (UInt64) - 向文件描述符写入缓冲区字节数。

1.3.2 system.query_log表

ClickHouse的system.query_log表包含有关已执行查询的信息，例如开始时间、处理持续时间和错误消息。你可以在服务器配置的query_log部分中更改查询日志记录的设置。你可以通过设置log_queries = 0来禁用查询日志记录。不建议关闭日志记录，因为此表中的信息对于解决问题很重要。

system.query_log表包含以下列:

- type (Enum8) - 执行查询时发生的事件类型。
- event_date (Date) - 查询开始日期。
- event_time (DateTime) - 查询开始时间。
- query_start_time (DateTime) - 查询执行开始时间。
- query_duration_ms (UInt64) - 查询执行持续时间（以毫秒为单位）。
- read_rows (UInt64) - 从所有参与查询的表和表函数中读取的行总数。
- read_bytes (UInt64) - 从所有参与查询的表和表函数中读取的字节总数。

例如，你可以使用以下查询来查看最近5个查询的类型、开始时间和持续时间：

SELECT type, event_time, query_duration_ms FROM system.query_log 
ORDER BY event_time DESC LIMIT 5

这将返回类似于以下的结果：

┌─type──────────────┬────────event_time─┬─query_duration_ms─┐
│ QueryFinish       │ 2022-11-01 12:34:56│               1234│
│ QueryStart        │ 2022-11-01 12:34:56│                  0│
│ QueryFinish       │ 2022-11-01 12:33:45│                567│
│ QueryStart        │ 2022-11-01 12:33:45│                  0│
│ ExceptionWhileProcessing │ 2022-11-01 12:32:34│                890│
└───────────────────┴────────────────────┴──────────────────

1.3.3 system.query_thread_log表

ClickHouse的system.query_thread_log表包含有关执行查询的线程的信息，例如线程名称、线程开始时间和查询处理持续时间。你可以在服务器配置的query_thread_log部分中更改查询线程日志记录的设置。你可以通过设置log_query_threads = 1来启用查询线程日志记录。

system.query_thread_log表包含以下列:

- event_date (Date) - 线程完成查询执行时的日期。
- event_time (DateTime) - 线程完成查询执行时的日期和时间。
- query_start_time (DateTime) - 查询执行开始时间。
- query_duration_ms (UInt64) - 查询执行持续时间（以毫秒为单位）。
- read_rows (UInt64) - 读取的行数。
- read_bytes (UInt64) - 读取的字节数。
- thread_name (String) - 线程名称。
- thread_number (UInt32) - 内部线程ID。

例如，你可以使用以下查询来查看最近5个查询线程的名称、开始时间和持续时间：

SELECT thread_name, query_start_time, query_duration_ms 
FROM system.query_thread_log ORDER BY query_start_time DESC LIMIT 5

这将返回类似于以下的结果：

┌─thread_name──────┬────query_start_time─┬─query_duration_ms─┐
│ QueryPipelineEx   │ 2022-11-01 12:34:56 │               123 │
│ QueryPipelineEx   │ 2022-11-01 12:34:56 │               456 │
│ QueryPipelineEx   │ 2022-11-01 12:33:45 │                78 │
│ QueryPipelineEx   │ 2022-11-01 12:33:45 │               901 │
│ QueryPipelineEx   │ 2022-11-01 12:32:34 │               234 │
└───────────────────┴─────────────────────┴─────────────────

1.3.4 system.trace_log表

ClickHouse的system.trace_log表包含采样查询分析器收集的堆栈跟踪。当trace_log服务器配置部分被设置时，ClickHouse会创建此表。你还可以查看设置：query_profiler_real_time_period_ns、query_profiler_cpu_time_period_ns、memory_profiler_step、memory_profiler_sample_probability和trace_profile_events。要分析日志，可以使用addressToLine、addressToLineWithInlines、addressToSymbol和demangle内省函数。

system.trace_log表包含以下列:

- event_date (Date) - 采样时刻的日期。
- event_time (DateTime) - 采样时刻的日期和时间。
- query_start_time (DateTime) - 查询执行开始时间。
- query_duration_ms (UInt64) - 查询执行持续时间（以毫秒为单位）。
- read_rows (UInt64) - 读取的行数。
- read_bytes (UInt64) - 读取的字节数。
- thread_name (String) - 线程名称。

例如，你可以使用以下查询来查看最近5个采样时刻的日期和时间：

SELECT event_date, event_time FROM system.trace_log 
ORDER BY event_time DESC LIMIT 5

这将返回类似于以下的结果：

┌─event_date─┬────────event_time─┐
│ 2022-11-01 │ 2022-11-01 12:34:56│
│ 2022-11-01 │ 2022-11-01 12:33:45│
│ 2022-11-01 │ 2022-11-01 12:32:34│
│ 2022-11-01 │ 2022-11-01 12:31:23│
│ 2022-11-01 │ 2022-11-01 12:30:12│
└────────────┴────────────────────┘

1.3.5 system.part_log表

ClickHouse的system.part_log表仅在指定part_log服务器设置时创建。此表包含有关MergeTree系列表中数据部分发生的事件的信息，例如添加或合并数据¹。

system.part_log表包含以下列:

- query_id (String) - 创建此数据部分的INSERT查询的标识符。
- event_type (Enum8) - 发生在数据部分的事件类型。可以具有以下值之一：NEW_PART - 插入新的数据部分。MERGE_PARTS - 合并数据部分。DOWNLOAD_PART - 下载数据部分。REMOVE_PART - 使用DETACH PARTITION删除或分离数据部分。MUTATE_PART - 变异数据部分。MOVE_PART - 将数据部分从一个磁盘移动到另一个磁盘。
- event_date (Date) - 事件日期。
- event_time (DateTime) - 事件时间。
- duration_ms (UInt64) - 持续时间。
- database (String) - 数据部分所在的数据库名称。
- table (String) - 数据部分所在的表名称。
- part_name (String) - 数据部分名称。

例如，你可以使用以下查询来查看最近5个事件的类型、开始时间和持续时间：

SELECT event_type, event_time, duration_ms FROM system.part_log 
ORDER BY event_time DESC LIMIT 5

这将返回类似于以下的结果：

┌─event_type─┬────────event_time─┬─duration_ms─┐
│ NewPart    │ 2022-11-01 12:34:56│          123│
│ MergeParts │ 2022-11-01 12:33:45│          456│
│ DownloadPart│2022-11-01 12:32:34│           78│
│ RemovePart │ 2022-11-01 12:31:23│          901│
│ MutatePart │ 2022-11-01 12:30:12│          234│
└────────────┴────────────────────┴─────────────┘

1.3.6 system.crash_log表

ClickHouse的system.crash_log表包含有关致命错误堆栈跟踪的信息。该表默认不存在于数据库中，仅在发生致命错误时才创建。

system.crash_log表包含以下列:

- event_date (Datetime) - 事件日期。
- event_time (Datetime) - 事件时间。
- timestamp_ns (UInt64) - 以纳秒为单位的事件时间戳。
- signal (Int32) - 信号编号。
- thread_id (UInt64) - 线程ID。
- query_id (String) - 查询ID。
- trace (Array(UInt64)) - 崩溃时刻的堆栈跟踪。每个元素都是ClickHouse服务器进程内的虚拟内存地址。

例如，你可以使用以下查询来查看最近一次崩溃的日期和时间：

SELECT event_date, event_time FROM system.crash_log 
ORDER BY event_time DESC LIMIT 

这将返回类似于以下的结果：

┌─event_date─┬────────event_time─┐
│ 2022-11-01 │ 2022-11-01 12:34:56│

1.3.7 system.text_log表

 ClickHouse的system.text_log表包含日志条目。可以通过text_log.level服务器设置将进入此表的日志级别限制为。

system.text_log表包含以下列:

- event_date (Date) - 条目日期。
- event_time (DateTime) - 条目时间。
- event_time_microseconds (DateTime) - 具有微秒精度的条目时间。
- microseconds (UInt32) - 条目的微秒。
- thread_name (String) - 执行日志记录的线程名称。
- thread_id (UInt64) - 操作系统线程ID。
- level (Enum8) - 条目级别。可能的值：1或'Fatal'。2或'Critical'。3或'Error'。4或'Warning'。5或'Notice'。6或'Information'。7或'Debug'。8或'Trace'。
- query_id (String) - 查询ID。
- logger_name (LowCardinality(String)) - 记录器名称（例如DDLWorker）。
- message (String) - 消息本身。

例如，你可以使用以下查询来查看最近5个日志条目的级别、时间和消息：

SELECT level, event_time, message FROM system.text_log 
ORDER BY event_time DESC LIMIT 5

这将返回类似于以下的结果：

┌─level───────┬────────event_time─┬─message──────────────────────────────────────┐
│ Information │ 2022-11-01 12:34:56│ Update period 15 seconds                     │
│ Warning     │ 2022-11-01 12:33:45│ Failed to connect to server                  │
│ Error       │ 2022-11-01 12:32:34│ Failed to execute query                      │
│ Critical    │ 2022-11-01 12:31:23│ Server is running out of memory              │
│ Fatal       │ 2022-11-01 12:30:12│ Server crashed due to fatal error            │

1.4 ClickHouse常用的监控指标

ClickHouse有许多常用的监控指标，可以帮助你了解服务器的状态和性能。这些指标包括：

- 查询性能：查询持续时间、查询吞吐量、查询错误率。
- 系统资源使用情况：CPU使用率、内存使用率、磁盘使用率、网络流量。
- 数据库表的大小和增长速度。
- 数据库复制延迟。

你可以使用ClickHouse的系统表来获取这些指标，例如system.metrics、system.asynchronous_metrics和system.events。此外，你还可以使用外部监控工具，如Prometheus和Grafana，来收集和可视化这些指标

---

2. 监控工具和平台

2.1 监控工具和平台-常用监控工具简介

有许多常用的监控工具和平台可以用来监控ClickHouse服务器的状态和性能。这些工具和平台包括：

Prometheus：一个开源的监控系统，可以收集和存储ClickHouse服务器的指标数据。
Grafana：一个开源的仪表板和可视化平台，可以用来展示ClickHouse服务器的指标数据。
Zabbix：一个开源的监控解决方案，可以用来监控ClickHouse服务器的状态和性能。
Nagios：一个开源的监控系统，可以用来监控ClickHouse服务器的状态和性能。
Datadog:Datadog是一个基于云的监控和分析平台，可以与ClickHouse集成，提供数据库性能的实时可见性。它可以收集和可视化ClickHouse指标、日志和跟踪，并提供异常检测、警报和可定制的仪表板等功能。
Percona监控和管理（PMM）：PMM是一个用于管理和监控MySQL、PostgreSQL、MongoDB和ClickHouse的开源平台。它可以收集和可视化ClickHouse的性能指标，设置警报，并为性能优化提供见解。
Telegraf：Telegraf是一个用于收集和报告指标的开源服务器代理。使用ClickHouse输入插件，它可以收集各种ClickHouse指标，并将其转发到不同的监控和可视化工具，如InfluxDB和Grafana。
ELK堆栈（Elasticsearch、Logstash、Kibana）：ELK堆栈是用于日志和事件数据管理的开源工具的集合。通过获取ClickHouse日志和系统指标，您可以使用Kibana创建可视化并设置警报。

可以使用这些工具和平台来收集、存储、可视化和报警ClickHouse服务器的指标数据，以帮助你了解服务器的状态和性能。

2.2 集成第三方监控平台（如Grafana、Zabbix等）

2.2.1 如何使用Grafana监控ClickHouse

你可以使用Grafana来监控ClickHouse服务器的状态和性能。要使用Grafana监控ClickHouse，你需要执行以下步骤：

1. 安装并配置Grafana：按照Grafana官方文档中的说明安装并配置Grafana。
2. 安装ClickHouse插件：在Grafana中安装ClickHouse数据源插件。
3. 配置数据源：在Grafana中添加一个新的数据源，选择ClickHouse作为类型，并填写ClickHouse服务器的连接信息。
4. 创建仪表板：在Grafana中创建一个新的仪表板，并添加图表来展示ClickHouse服务器的指标数据。

你可以使用Grafana提供的丰富的可视化选项来定制仪表板，以满足你的需求。此外，你还可以使用Grafana提供的报警功能来设置报警规则，以便在发生异常情况时及时通知你。

2.2.2 如何安装并配置Grafana

要安装并配置Grafana，你需要按照以下步骤操作：

1. 访问Grafana官网（https://grafana.com/）并下载适用于你的操作系统的最新版本的Grafana。
2. 按照Grafana官方文档中的说明安装Grafana。
3. 启动Grafana服务。
4. 访问Grafana Web界面（默认情况下，它位于http://localhost:3000/）并使用默认用户名（admin）和密码（admin）登录。
5. 按照提示更改默认密码。
6. 按照需要配置Grafana的设置，例如数据源、仪表板和报警。

安装并配置完成后，你就可以开始使用Grafana来监控ClickHouse服务器了。

2.2.3 如何安装ClickHouse插件

要在Grafana中安装ClickHouse数据源插件，你可以按照以下步骤操作：

1. 访问Grafana插件页面（https://grafana.com/grafana/plugins/vertamedia-clickhouse-datasource）并查看ClickHouse数据源插件的详细信息。
2. 在Grafana服务器上，使用grafana-cli命令安装插件。例如，你可以运行以下命令来安装最新版本的插件：

grafana-cli plugins install vertamedia-clickhouse-datasource

3. 安装完成后，重启Grafana服务以使更改生效。
4. 登录到Grafana Web界面，然后导航到“配置”>“数据源”页面。
5. 点击“添加数据源”按钮，然后从列表中选择“ClickHouse”。

安装并启用插件后，你就可以开始配置ClickHouse数据源并使用它来监控ClickHouse服务器了。

2.2.4 如何配置数据源

要在Grafana中配置ClickHouse数据源，你需要按照以下步骤操作：

1. 登录到Grafana Web界面，然后导航到“配置”>“数据源”页面。
2. 点击“添加数据源”按钮，然后从列表中选择“ClickHouse”。
3. 在“设置”选项卡中，填写ClickHouse服务器的连接信息，包括URL、数据库名称、用户名和密码。
4. （可选）在“Auth”选项卡中，配置身份验证设置。
5. （可选）在“HTTP”选项卡中，配置HTTP连接设置。
6. 点击“保存并测试”按钮来测试连接并保存数据源。

配置完成后，你就可以开始使用这个数据源来监控ClickHouse服务器了。

2.2.5 如何创建仪表盘

 要在Grafana中创建一个新的仪表板，你需要按照以下步骤操作：

1. 登录到Grafana Web界面，然后点击左侧菜单栏中的“+”图标。
2. 从下拉菜单中选择“仪表板”。
3. 点击“添加面板”按钮来添加一个新的图表。
4. 在图表编辑器中，配置图表的设置，包括查询、可视化和显示选项。
5. （可选）重复步骤3和4来添加更多图表。
6. 点击“保存仪表板”按钮来保存仪表板。

创建并保存仪表板后，你就可以使用它来监控ClickHouse服务器了。你可以使用Grafana提供的丰富的可视化选项来定制图表，以满足你的需求。

2.2.6 如何使用Zabbix监控ClickHouse？

可以使用Zabbix来监控ClickHouse。Zabbix提供了一个名为“Template DB ClickHouse by HTTP”的模板，它可以通过HTTP无需任何外部脚本即可监控ClickHouse。大多数指标都可以一次性收集，这要归功于Zabbix的批量数据收集。此模板已在ClickHouse版本19.14+和20.3+上进行过测试。

需要在Zabbix中导入模板并进行一些配置，例如创建一个用于监控服务的用户并设置登录名和密码等。可以在Zabbix官网上查看详细的设置说明。

2.2.7 如何安装Zabbix

可以从Zabbix官网上下载并安装Zabbix。安装过程可能因您的操作系统和版本而异。以下是在RHEL 9上安装Zabbix 6.4的步骤：

1. 安装Zabbix存储库：

# rpm -Uvh https://repo.zabbix.com/zabbix/6.4/rhel/9/x86_64/zabbix-release-6.4-1.el9.noarch.rpm
# dnf clean all

2. 安装Zabbix服务器，前端和代理：

# dnf install zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf zabbix-sql-scripts zabbix-selinux-policy zabbix-agent

3. 创建初始数据库：

# mysql -uroot -p password
mysql> create database zabbix character set utf8mb4 collate utf8mb4_bin;
mysql> create user zabbix@localhost identified by 'password';
mysql> grant all privileges on zabbix.* to zabbix@localhost;
mysql> set global log_bin_trust_function_creators = 1;
mysql> quit;

# zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix

# mysql -uroot -p password
mysql> set global log_bin_trust_function_creators = 0;
mysql> quit;

4. 配置Zabbix服务器的数据库：

编辑文件 /etc/zabbix/zabbix_server.conf
DBPassword= password

5. 启动Zabbix服务器和代理进程，并设置开机自启：

# systemctl restart zabbix-server zabbix-agent httpd php-fpm
# systemctl enable zabbix-server zabbix-agent httpd php-fpm

2.2.8 如何配置Zabbix来监控ClickHouse

要配置Zabbix来监控ClickHouse，您需要执行以下步骤：

1. 在Zabbix中导入“Template DB ClickHouse by HTTP”模板。
2. 在ClickHouse服务器上创建一个用于监控服务的用户。例如，您可以在`/etc/clickhouse-server/users.d/`目录下创建一个名为`zabbix.xml`的文件，并在其中添加以下内容：

<yandex>
  <users>
    <zabbix>
      <password>zabbix_pass</password>
      <networks incl="networks" />
      <profile>web</profile>
      <quota>default</quota>
      <allow_databases>
        <database>test</database>
      </allow_databases>
    </zabbix>
  </users>
</yandex>

3. 在Zabbix中设置宏，例如`{$CLICKHOUSE.USER}`和`{$CLICKHOUSE.PASSWORD}`，以匹配您在上一步中创建的用户的用户名和密码。
4. 如果不需要身份验证，则可以从HTTP-Agent类型的项目中删除标头。

2.2.9 如何导入Zabbix模板

要在Zabbix中导入模板，需要执行以下步骤：

1. 登录到Zabbix的Web界面。
2. 在顶部菜单中，选择“配置”>“模板”。
3. 在右上角，点击“导入”按钮。
4. 在“导入”页面，点击“选择文件”按钮并选择要导入的XML模板文件。
5. 按照您的需要选择导入选项，然后点击“导入”按钮。

2.2.10 Zabbix能监控ClickHouse哪些指标

Zabbix可以通过“Template DB ClickHouse by HTTP”模板监控ClickHouse的许多指标。这个模板不需要任何外部脚本，大多数指标都可以一次性收集，这要归功于Zabbix的批量数据收集。此模板已在ClickHouse版本19.14+和20.3+上进行过测试。

2.2.11 如何查看Zabbix监控结果

可以在Zabbix的Web界面中查看监控结果。登录到Zabbix的Web界面后，可以在“监控”菜单下找到“仪表盘”和“最新数据”等选项，这些选项可以让您查看监控数据和图表。

也可以创建自定义的仪表盘和图表，以便更好地查看和分析监控数据。

2.2.12 如何使用Datadog监控ClickHouse

您可以使用Datadog来监控ClickHouse。Datadog与ClickHouse集成，可以为您提供对大数据分析作业的全面可见性。Datadog的ClickHouse集成提供了您需要的指标来跟踪读写性能。您可以跟踪每个ClickHouse实例的INSERT和SELECT查询速率，以及每个查询写入的行数。然后，您可以将查询吞吐量与查询资源使用情况（例如clickhouse.query.memory）进行比较，帮助您设计最大性能和最小系统拖累的查询。

2.2.13 如何安装Datadog

要安装Datadog，您需要在您的主机上安装Datadog Agent。Datadog Agent是一种软件，它可以从主机收集事件和指标并将它们发送到Datadog，以便您可以分析监控和性能数据。Datadog Agent是开源的，其源代码可在GitHub上的DataDog/datadog-agent处获得。建议您完全安装Agent。

安装过程可能因您的操作系统和版本而异。可以在Datadog官网（https://docs.datadoghq.com/）上查看有关如何安装Datadog Agent的详细信息。

2.2.14 如何查看Datadog监控结果

可以在Datadog的Web界面中查看监控结果。登录到Datadog的Web界面后，可以查看和分析您的监控数据。Datadog提供了一个随集成附带的开箱即用仪表盘，它提供了关于读写吞吐量、资源利用率和复制活动的见解。

也可以创建自定义的仪表盘和图表，以便更好地查看和分析监控数据。