健康度定义

集群健康度通过多个维度的健康指标得出的参考性结论。是评判集群的运行状况、出现问题风险的重要风向标。相比监控指标，健康度指标的实时性偏低（每小时采集过去一小时的最大值），反映的问题更偏长期治理解决。

• 健康度指标：
  • 评判健康度的各维度指标，包括硬件与系统健康度，ClickHouse 健康度，查询健康度三个大类，9个具体指标（详见下文：指标含义与优化建议）
  • 根据阈值，每项监控指标会定4个不同档位：危险，不及格，及格，良好
• 健康度等级：
  • 作为集群的整体概览，抽象反映整体健康情况。
  • 有以下四个等级，和健康度指标的档位有对应关系：
    • 危险：有 1 项危险指标；
    • 不及格：没有危险指标，且 1 项以上指标为不及格指标；
    • 及格：没有危险和不及格，且 1 项以上指标为及格；
    • 良好：每一项都是良好。

查看步骤

前提条件：

• 操作用户是当前集群的 ClusterAdmin 角色，或 SystemAdmin 角色。
• 集群为“正在运行”状态。

操作步骤

1. 进入 ByteHouse 企业版，默认进入集群列表页面；
2. 如在其他页面，可选择 （右上角切换）运维与权限管理 > 集群管理 > 集群列表；
3. 单击集群名称，进入集群详情，选择“健康度” TAB。

指标含义与优化建议

最大磁盘占用率

指标含义： 数据盘（ByteHouse 目录所在磁盘）的占用率。磁盘使用率过高会影响后续的数据导入。
评分阈值：

优化建议：

• （云上支持）通过界面上方“更改规格”按钮操作，扩容磁盘。
• （私有化或云上无法再扩容磁盘）：
• 数据不需要的场景：
  • 删除不必要的表。可以通过select database, name, total_bytes from system.tables order by total_bytes desc limit 100查看系统中较大的表，并通过控制台或 Drop xxx.xx on cluster xxx的方式删除。
  • 按需减少表的 TTL。
• 所有数据都需要的场景：开启冷存储，参考 冷热分层存储。

最大文件数占比

指标含义： 指操作系统的 inode 使用率。过高时会影响集群数据导入和查询。通常是由写入的 Part 太碎，不能及时 Merge 造成的。
评分阈值：

优化建议：
参照文档 Part 过多中描述的方法进行处理。

节点宕机率

指标含义： 无法联通节点 / 全部节点数。
评分阈值：

优化建议：

• ByteHouse 企业版（火山引擎）基于公有云的 ECS 产品，底层资源保持 99.95% 的可用性。如果持续宕机率高，建议提交工单，更换底层设施。
• ByteHouse 企业版（私有化部署）的底层可能基于任意设施，如果持续宕机率高，可采用“节点替换”功能（支持版本：2.4.1 及以上），更换节点服务器。

平均 CPU 使用率

指标含义：
这个参数记录了系统 CPU 的平均使用率，它能够反映系统是否已经超出了 CPU 的处理能力限制，从而导致了性能问题
评分阈值：

优化建议：

• 通过SELECT * FROM system.query_log ORDER BY total_cpu_seconds DESC limit 20，查看 CPU 耗费较大的大查询，通过 慢查询章节中的优化建议，进行 SQL 与 Schema 的优化。
• 若 SQL 无大幅优化的空间，或 SQL 改写 / 调整 Schema 的成本较大，可以看 CPU 使用较多的用户是否可以通过放入 资源组，进行 CPU 资源的限制。
• 建议分数为不及格以上直接水平或垂直扩容。参考 集群变配。

平均内存使用率

指标含义：
系统内存的平均使用率，它能够反映系统是否已经用尽可用内存，从而导致了性能问题。
评分阈值：

优化建议：

• 参考 内存不足进行排查。
• 可以看查询内存较多的用户是否可以通过放入 资源组，进行内存资源的限制。
• 若无优化空间，建议分数为不及格以上直接水平或垂直扩容。参考 集群变配。

平均 IO 使用率

指标含义：
系统磁盘的平均 IOPS，它能够反映磁盘资源是否成为了性能瓶颈。
评分阈值：

优化建议：

• 通过SELECT * FROM system.query_log ORDER BY read_bytes DESC limit 20，SELECT * FROM system.query_log ORDER BY written_bytes DESC limit 20，查看读写耗费较大的大查询，通过 慢查询章节中的优化建议，进行 SQL 与 Schema 的优化。
• 若 SQL 无大幅优化的空间，或 SQL 改写 / 调整 Schema 的成本较大，建议分数为不及格以上直接水平或垂直扩容。参考 集群变配。

集群表个数

指标含义：
集群 *MergeTree 表的总数量。表数量越多，可能会导致 Zookeeper 压力大，导致数据同步问题。
评分阈值：

优化建议：

• 删除一些不必要的表，如果确有千张表的需求，建议用多个集群承载。

Kafka 表个数

指标含义：
集群 HaKafka 表的总数量。表数量越多，可能会导致集群的资源均用于写入，无资源查询。
评分阈值：

优化建议：

• 删除一些不必要的导入任务，如果确有超过50个导入任务的需求，建议用多个集群承载。

单表最大主备同步延迟

指标含义：
HaMergeTree 引擎的主备同步日志记录在系统表 ha_queue 中，这个指标标识了 ha_queue 中未处理日志最多的一张表的剩余日志数量，代表这张表的主备同步发生了一些问题，很可能只有一个节点数据完整，在承担查询工作，导致负载不均。
评分阈值：

处理步骤：
参考 主备延迟排查问题。

故障表数

指标含义：
记录了无法启动的表的数量，这些表无法被读写。可能因为意外重启或硬件损坏所致。
评分阈值：

处理步骤：
请联系 ByteHouse 支持人员处理。

Leader 为 0 的表数

指标含义：
这个参数记录了没有 Leader 副本的表的数量，没有 Leader 会导致这张表无法被写入。
通常为 ZooKeeper 的问题所致。
评分阈值：

处理步骤：

• 请联系 ByteHouse 支持人员处理。

最大节点 Part 总数

指标含义：
记录了单节点的最大 Part 数量。Part 数过多会导致后台大量资源用于 Merge，查询变慢，更严重会导致 inode 用尽，无法再写入。
评分阈值：

处理步骤：

• 参考 Part 过多进行处理。

分布式表延迟

指标含义：
展示了插入分布式表的后台文件数（back files），代表数据插入延迟。该指标过大会导致大量刚写入的数据无法被查询到。
评分阈值：

处理步骤：

• 请联系 ByteHouse 支持人员处理。

P95 查询延时

指标含义： 集群所有查询时延的 P95 分位（单位：秒），可基本反应集群查询的返回速度。数字越大，集群健康情况越差。
评分阈值：

优化建议：

• 该指标不健康表明集群的查询速度很慢，慢于一般用户对 ByteHouse 的预期。首先收集各下游业务反馈，如果本身业务查询的数据量确实很大，并且可以接受目前的查询速度，则可以暂时忽略问题，后续再持续追踪。
• 如果下游业务反馈查询不稳定，且越来越变慢。则通过 慢查询进行 SQL 优化。
• 若所有大查询均无法再被优化了，则考虑让大查询的用户的数据迁移到单独集群，并在本集群设置 max_execution_time等限制参数。

查询成功率

指标含义： 集群所有查询的成功率，反映是否有大面积超时和 SQL 语法错误，越低表示健康情况越差。
评分阈值：

优化建议：

• 这类问题通常是因为集群负载高而导致大量超时，或因为大量发送的查询不符合语法；通过数据管理与查询->查询管理->查询历史功能，可以找到这个集群对应的失败查询。判断主要的失败原因：
  • 超时：多为集群负载高原因，参考 慢查询 的处理方法。
  • Too Many Parts：为导入不合理所致。可参考 Part 过多 的处理方法。
  • 其他语法错误：主要看是否有特定用户持续在发送不合语法的查询，和该用户进行沟通调整。