45人参与 • 2026-03-28 • 运维
作为一个在数据深渊里捞了十几年 bug 的女码农,我深知监控与运维在数据库系统中的重要性。clickhouse 作为一款高性能的列存数据库,其监控与运维策略直接影响到系统的稳定性和可靠性。今天,我就来聊聊 clickhouse 的监控与运维策略,从监控指标到故障处理,带你构建一个完善的运维体系。
服务器层面的指标是基础,直接影响 clickhouse 的运行状态:
clickhouse 自身的指标能直接反映数据库的运行状态:
对于集群部署,zookeeper 的状态至关重要:
目前最流行的监控组合,适合大规模集群:
# prometheus.yml
scrape_configs:
- job_name: 'clickhouse'
static_configs:
- targets: ['clickhouse1:9363', 'clickhouse2:9363', 'clickhouse3:9363']
- job_name: 'zookeeper'
static_configs:
- targets: ['zookeeper1:9141', 'zookeeper2:9141', 'zookeeper3:9141']
导入 clickhouse 官方仪表板(id: 882),或创建自定义仪表板:
clickhouse 提供了丰富的系统表,可用于监控:
-- 查看查询状态 select * from system.processes; -- 查看查询历史 select * from system.query_log order by event_time desc limit 100; -- 查看复制状态 select * from system.replication_queue; -- 查看表大小 select table, sum(bytes) as size from system.parts group by table;
配置日志轮转和集中管理:
<logger>
<level>information</level>
<log>/var/log/clickhouse-server/clickhouse-server.log</log>
<errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
<size>100m</size>
<count>10</count>
</logger>
使用 elk 或 loki 进行日志集中管理和分析。
制定定期备份策略,确保数据安全:
#!/bin/bash
# 备份表结构
clickhouse-client --query="show create table database.table" > /backup/table_structure_$(date +%y%m%d).sql
# 备份数据
clickhouse-client --query="backup table database.table to disk('backup', 'table_backup_$(date +%y%m%d)')"
定期优化表结构和数据:
-- 合并分区 optimize table events final; -- 重建索引 alter table events drop index idx_event_type; alter table events add index idx_event_type event_type type minmax granularity 1;
定期检查系统状态和性能:
#!/bin/bash # 检查 clickhouse 状态 systemctl status clickhouse-server # 检查查询性能 clickhouse-client --query="select query, time, read_rows, written_rows from system.query_log where event_time > now() - interval 1 hour order by time desc limit 10" # 检查复制状态 clickhouse-client --query="select * from system.replication_queue"
使用 git 等版本控制工具管理配置文件,确保配置变更可追溯。
<clickhouse>
<!-- 内存配置 -->
<max_memory_usage>32gb</max_memory_usage>
<max_bytes_before_external_group_by>20gb</max_bytes_before_external_group_by>
<max_bytes_before_external_sort>20gb</max_bytes_before_external_sort>
<!-- 并发配置 -->
<max_concurrent_queries>100</max_concurrent_queries>
<background_pool_size>16</background_pool_size>
<!-- 日志配置 -->
<logger>
<level>information</level>
<log>/var/log/clickhouse-server/clickhouse-server.log</log>
<errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
<size>100m</size>
<count>10</count>
</logger>
</clickhouse>
配置用户权限和网络访问控制:
<users>
<default>
<password>default_password</password>
<networks>
<ip>127.0.0.1</ip>
</networks>
<profile>default</profile>
<quota>default</quota>
</default>
<admin>
<password_sha256_hex>admin_password_hash</password_sha256_hex>
<networks>
<ip>192.168.1.0/24</ip>
</networks>
<profile>admin</profile>
<quota>admin</quota>
</admin>
</users>
配置 tls 加密传输:
<openssl>
<server>
<certificatefile>/etc/clickhouse-server/server.crt</certificatefile>
<privatekeyfile>/etc/clickhouse-server/server.key</privatekeyfile>
<dhparamsfile>/etc/clickhouse-server/dhparams.pem</dhparamsfile>
<verificationmode>none</verificationmode>
<loaddefaultcafile>true</loaddefaultcafile>
<cachesessions>true</cachesessions>
<disableprotocols>sslv2,sslv3</disableprotocols>
</server>
</openssl>
| 故障类型 | 症状 | 可能原因 |
|---|---|---|
| 查询超时 | 查询执行时间过长 | 数据量过大、查询语句不合理、资源不足 |
| 写入失败 | 写入操作报错 | 磁盘空间不足、权限问题、网络问题 |
| 复制延迟 | 复制队列堆积 | 网络延迟、节点负载高、zookeeper 异常 |
| 节点宕机 | 服务不可用 | 硬件故障、系统崩溃、配置错误 |
| zookeeper 异常 | 复制中断 | 网络问题、zookeeper 集群故障 |
症状:查询执行时间超过 30 秒
诊断:
解决方案:
症状:复制队列长度持续增长
诊断:
解决方案:
症状:节点服务不可用
诊断:
解决方案:
场景:管理一个 20 节点的 clickhouse 集群,处理每日 5tb 的数据
监控方案:
告警规则:
groups:
- name: clickhouse_alerts
rules:
- alert: clickhousedown
expr: up{job="clickhouse"} == 0
for: 5m
labels:
severity: critical
annotations:
summary: "clickhouse 节点宕机"
description: "{{ $labels.instance }} 节点已宕机超过 5 分钟"
- alert: highcpuusage
expr: (100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 80
for: 10m
labels:
severity: warning
annotations:
summary: "cpu 使用率过高"
description: "{{ $labels.instance }} cpu 使用率超过 80% 已持续 10 分钟"
- alert: highmemoryusage
expr: (node_memory_memtotal_bytes - node_memory_memavailable_bytes) / node_memory_memtotal_bytes * 100 > 90
for: 10m
labels:
severity: warning
annotations:
summary: "内存使用率过高"
description: "{{ $labels.instance }} 内存使用率超过 90% 已持续 10 分钟"
- alert: diskspacelow
expr: (node_filesystem_size_bytes{mountpoint="/"} - node_filesystem_free_bytes{mountpoint="/"}) / node_filesystem_size_bytes{mountpoint="/"} * 100 > 85
for: 10m
labels:
severity: warning
annotations:
summary: "磁盘空间不足"
description: "{{ $labels.instance }} 磁盘使用率超过 85% 已持续 10 分钟"
- alert: replicationdelay
expr: clickhouse_replication_delay > 300
for: 5m
labels:
severity: warning
annotations:
summary: "复制延迟过高"
description: "{{ $labels.instance }} 复制延迟超过 300 秒已持续 5 分钟"
场景:生产环境中 clickhouse 集群突然出现查询性能下降
处理过程:
clickhouse 的监控与运维是一个系统工程,需要从监控指标、监控工具、运维策略、故障处理等多个方面入手。
到此这篇关于clickhouse数据库的监控与运维:监控指标、监控工具、运维策略、故障处理的文章就介绍到这了,更多相关clickhouse监控与运维内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
您想发表意见!!点此发布评论
版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。
发表评论