为了业务提高对Hologres的自诊断和自运维能力，在2022年7月Hologres新增了若干监控指标，业务能更加精准的定位问题，查看资源使用情况，以提高系统的整体可用性。现

Hologres管理控制台提供的监控指标如下：

1. CPU使用率（%）

• 实例CPU使用率（%）
• Worker节点CPU使用率（%）：2022年7月新增指标

2. 内存使用率（%）

• 实例内存使用率（%）
• Worker节点内存使用率（%）：2022年7月新增指标

3. 实例存储用量（字节）
4. 连接数

• 实例连接数（个）
• FE节点连接数最高使用率（%）：2022年7月新增指标
• FE节点连接数：2022年7月新增指标

5. QPS（个/秒）
6. Query延迟（毫秒）
7. 实时导入RPS（记录/秒）
8. IO吞吐（字节）
9. 正在运行Query持续时长：2022年7月新增指标
10. 失败Query数（次/秒）：2022年7月新增指标
11. 主从实例同步延迟（豪秒）：2022年7月新增指标

在之前的文章中已经介绍过透出的监控指标，移步》使用实践｜监控告警常见问题。本次我们将会介绍7月新增的指标，以及如何根据这些指标排查问题。

新指标使用说明：

• 2022年7月新增的指标，仅适用于1.1及以上版本，若您的版本较低，请先升级实例
• CPU和内存指标的计算方式将会更加精准，以方便业务能更好的判断资源使用情况，因此在2022年7月发布新指标后，1.1版本的实例其CPU和内存使用率将会有部分变化，在5%-10%之间均属正常波动。云监控的CPU和内存使用率也同步变更，请及时关注云监控的告警信息，并重新设置合理的监控阈值。

7月新增监控指标介绍：

1、Worker节点CPU

2022年7月新增指标

Worker节点CPU指实例内每个Worker的CPU使用率，代表每个Worker的计算负载情况。Hologres根据实例规格，提供不同的Worker节点数，详情见文档实例规格。

• 当前指标只有1.1及以上版本支持显示。
• 当实例内所有Worker节点CPU使用率都长期接近100%时，说明实例的负载非常高，需要根据业务情况合理的优化资源使用或者扩容。
• 当实例只有部分Worker节点CPU比较高，部分Worker节点CPU水位较低，且计算算子本身具备均衡性时，说明实例的负载不均，可以查询当前运行的大query是否有数据倾斜，根据业务情况处理倾斜数据或者设置合适的distribution key，详情见内表性能调优

2、Worker节点内存

2022年7月新增指标

Worker节点内存指实例内每个Worker的内存使用率，代表每个内存的计算负载情况。Hologres根据实例规格，提供不同的Worker节点数，详情见文档实例规格。

• 当前指标只有1.1及以上版本支持显示。
• 当实例內所有Worker节点的内存水位都长期接近100%时，说明实例的负载非常高，需要根据业务情况合理的优化资源或者扩容
• 当实例部分Worker节点内存水位较高，部分Worker节点内存水位较低，且计算算子本身具备均衡性时，说明实例的负载不均，通常是因为数据倾斜导致，可以查询当前运行的query是否有数据倾斜，根据业务情况处理倾斜数据或者设置合适的distribution key，详情见内表性能调优

3、FE节点连接数

2022年7月新增指标

FE节点连接数代表实例中每个 Frontend（FE）节点的连接使用个数，包括active、idle等各种状态的JDBC/PSQL等连接。

• 当前指标只有1.1及以上版本支持显示。
• 每个FE节点的总连接数上限默认是128个，总数参考实例规格说明。
• 当每个FE节点的连接数长期接近最大值时，说明实例的连接数使用较多，可以根据业务情况查看是空闲连接还是业务连接，见文档连接管理，并根据业务情况及时清理空闲连接或者扩容获取更多的连接。
• 当部分Worker节点连接数较高，部分Worker节点的连接数较低时，说明实例的连接负载不均，通过连接管理查看空闲连接，并及时清理，以缓解连接负载不均的情况。

4、正在运行Query持续时长

2022年7月新增指标

正在运行Query时长指实例中正在运行的Query持续时长，默认汇报当前时刻运行时长最长的Query。

• 当前指标只有1.1及以上版本支持显示。
• Hologres是分布式系统，根据实例的规格不同会有不同的Worker节点。Query运行时会在不同的Worker节点随机分发。正在运行的Query持续时长会根据每个Worker节点上Query运行时长，汇报当前时刻运行时长最长的Query，例如当前时刻不同Worker节点分别有10min，5min，30s的query正在运行，此时正在运行的Query持续时长将会显示为10min。
• 可以根据Query的运行时长，并结合活跃Query或者慢Query日志判断Query运行时长是否合理，根据文档排查并解决query运行时间较长的问题，及早解决死锁、卡主等问题。
• 特殊说明：管控台的指标是20s汇报一次，因此指标中“正在运行的持续时长” x轴开始时间与query真正开始的时间有误差，所以该指标仅作为异常情况问题排查的辅助指标，即通过该指标快速定位到实例有运行时长较长的query，作为自运维的辅助指标，不提供精确query运行时间。

5、失败Query数（次/秒）

失败Query数代表实例內平均每秒SQL语句失败的次数，包括SELECT、INSERT、UPDATE和DELETE、OTHER共5种SQL语句。

• 指标每20s汇报一次，如果20s内只有一个SQL语句执行，那么SQL语句QPS将在该20s的数据点会显示1/20=0.05。
• 根据失败的query类型和次数，在慢Query日志中查找失败的Query并分析原因，以提高系统的可用性。

6、主从实例同步延迟（毫秒）

2022年7月新增指标

Hologres提供共享存储的多子实例高可用部署，一个主实例可以配置4个子实例，详细使用见文档。主从实例同步延迟代表从实例读取主实例数据时的延迟（毫秒）

• 仅1.1及以上版本支持配置主从实例，仅子实例显示该指标，主实例默认不显示。
• 只有在子实例绑定了主实例之后，该指标会显示数据（0ms），当主实例有数据写入时，子实例的同步延迟会出现数据波动。
• 一般情况下，主从实例的同步延迟毫秒级，当实例偶尔出现延迟抖动时，一般情况为主实例在做DDL等元数据修改的操作，可忽略。若长期延迟较大（大于秒），一般情况为实例水位较高，资源不足，可以结合CPU、内存等水位情况综合评估，并适当扩容以减少延迟。实例重启或者升级期间，同步延迟可能增加到分钟级别，并会自动恢复。

常见监控问题诊断

1、正在运行query时长较长如何解决？

监控指标“正在运行Query持续时长”中有长时间运行的query，例如大于1h。当出现有running query较长时，可以先通过活跃qeury查看正在运行的query。通常有以下种原因，可以根据情况进行排查：

原因1：实例有较长时间的写入

解决办法：通过监控指标“实时写入RPS”看是否有持续的写入任务，从而出现query运行时间较长。

原因2：有idle in trancation的SQL

客户端打开事务，进行DDL后未进行commit，在查询了活跃query之后，query的state显示为idle in trancation，且运行时间较长。

SELECT datname::text,usename,query,pid::text,state

  FROM pg_stat_activity

  WHERE state != 'idle' ;

解决办法：

• 使用superuser账号kill对应的query。
• 客户端关闭事务。

原因3：SQL运行复杂且有PQE的query

• 通过活跃query查询当前正在运行的query，且运行时间较长的query，然后通过执行计划（explain sql）查看当前有sql走了PQE引擎（执行计划中有External  SQL（Postgres）），导致执行时间较长。

SELECT datname::text,usename,query,pid::text,state
FROM pg_stat_activity
WHERE state !='idle';

解决办法：

• superuser账号kill掉运行时间较长的Query
• 优化SQL中走PQE引擎的算子，见文档内表性能调优

原因4：并发执行DDL导致抢锁

执行DDL时，会锁表。如果并发执行DDL时，会导致互相抢锁，从而出现等锁，从而运行时间较长。

解决办法：

• 可以通过活跃Query查询是否有DDL正在执行中，并kill掉对应的DDL，释放锁
• 串行执行DDL

2、失败query如何排查？

失败query代表每秒钟失败的query，query总数是时间范围乘以QPS个数，即面积。不建议依赖QPS来判断失败的总数量。可以通过慢query日志排查总的失败数量以及query失败的原因，并根据报错针对性的解决。

3、Worker CPU负载不均/某个Worker CPU很低的原因和解法

shard在Hologres中是指数据分片，它决定了数据的分布情况。一个worker在计算时可能会访问一个或者多个shard的数据。同一个实例中，一个shard同一时间只能被一个worker访问，不能同时被多个worker访问。如果实例中，每个worker访问的shard总数不同，那么就有可能出现worker资源负载不均的情况，主要原因如下：

原因1：存在数据倾斜。

如果数据存在严重的倾斜，那么Worker的负载就会访问固定的shard，导致出现CPU负载不均的情况。解法：通过以下语句需要排查数据倾斜。可根据业务清楚处理倾斜数据或者设置合适的distribution key

selectcount(1)from t1 groupby hg_shard_id;

原因2：数据均匀但访问的热点数据不均匀
通过排查倾斜情况，得知数据在shard上是均匀分布。需要根据业务逻辑排查是否有数据访问热点的情况。


原因3：实例设置的shard数和worker个数整倍数关系

当Table Group中设置的shard数和实例的总Worker数不是整倍数关系时，意味着不同的Worker上分配的shard数不同，从而导致负载不均。

解法：根据实例规格，设置合理的shard数，见文档。一般这种情况出现在较大规格（大于256core）的实例上，小规格实例可以使用默认shard数，无需更改。

原因4：有worker failover后导致shard分配不均

当有worker因为oom等原因出现oom而被kill时，为了能快速恢复worker的查询，高系统会将该kill的worker对应的shard，快速迁移至其他worker。当被kill的worker被拉起后，系统会再分配部分shard给它。从而出现worker间shard分配不均的现象。

解法：如果实例负载较低，可忽略该负载分配不均的问题。如果实例负载较高，可以重启实例以重新均匀分配shard资源。

了解Hologres：https://www.aliyun.com/product/bigdata/hologram