核心监控指标与告警实践

面对海量的数据库监控指标,您可能会感到无从下手。实际上,您无需关注所有指标,只需聚焦少数核心指标,即可快速评估PolarDB分布式版实例的整体运行状态。本文将为您解读计算节点(CN)、存储节点(DN)、日志节点(CDC)和列存节点(Columnar)中最关键的监控指标,并提供相应的观测方法与优化建议。

方案架构

对生产环境中的数据库进行持续的健康状态监控至关重要。有效的监控可以帮助预判资源瓶颈、诊断性能问题、保障数据服务的稳定性。筛选关键指标并设置合理告警阈值,是保障系统稳定运行的挑战。

PolarDB分布式版采用计算存储分离的分布式架构,理解其核心组件是有效监控的基础。围绕PolarDB分布式版的关键组件,通过云监控服务配置告警规则,可实现对系统健康状况的自动化监测。

  • 计算节点(Compute Node,CN):无状态的SQL代理层,负责SQL解析、优化、执行和结果合并。其性能主要受CPUJVM内存影响。

  • 存储节点 (Data Node,DN):基于MySQL的数据存储单元,负责数据的持久化存储和物理执行。其性能与CPU、内存(特别是Buffer Pool)和磁盘 I/O 密切相关。

  • 元数据服务(Global Meta Service,GMS):存储集群的元数据,如表结构、分区信息等。其稳定性至关重要,但通常无需直接监控。

  • 日志节点(Change Data Capture,CDC):负责生成全局一致性的Binlog,用于数据订阅和同步。仅在开启全局Binlog订阅时需要重点关注。

  • 列存节点(Columnar):负责将行存数据实时同步为列存格式,以加速分析型查询(AP)。其核心监控指标是数据同步延迟。

监控计算资源(CN)

CN节点是SQL请求的入口,其资源状态直接影响数据库的响应能力和吞吐量。

CPU使用率

  • 目的:监控CN节点的计算压力,防止因CPU资源耗尽导致SQL执行变慢或请求堆积。

  • 指标分析:在PolarDB分布式版控制台监控与报警 > 计算资源监控 > 实例 > CPU图表中查看。CPU使用率持续处于高位(例如超过70%)通常意味着计算资源成为瓶颈。

  • 决策建议

    • 增加节点(Scale-Out):当业务整体QPS增长导致总计算量上升时,通过增加CN节点数量以水平扩展处理能力。

    • 提升规格(Scale-Up):当单个复杂查询(例如大型报表、复杂关联)消耗大量CPU资源时,通过提升单个CN节点的规格来增强其计算能力。

内存与Full GC

  • 目的:监控CN节点的JVM堆内存健康状况。频繁的Full GC是内存不足或内存泄漏的明确信号,会严重影响性能。

  • 指标分析

    • 内存使用率:在PolarDB分布式版控制台监控与报警 > 计算资源监控 > 集群 > 内存图表中查看。

      CN内存是JVM堆内存,其使用率指标反映的是JVM老年代(Old Generation)的使用情况。内存使用率呈现规律性的锯齿状是Young GC的正常表现。由于 JVM的内存管理机制,即使业务负载下降,已分配的堆内存也通常不会立即释放给操作系统,而是留作复用。因此,内存使用率维持在较高水位(例如 80%-90%)是正常现象。判断内存瓶颈的核心指标是Full GC时间。

    • Full GC时间:在PolarDB分布式版控制台监控与报警 > 计算资源监控 > 集群 > Full GC时间图表中查看。在内存充足的情况下,此指标值应始终为0。任何非零值的出现都值得关注,若频繁发生,则表明内存资源严重不足。

  • 决策建议

    1. 定位消耗内存的SQL:使用SQL洞察功能,分析并优化消耗内存较多的SQL。常见类型包括:

      • 大批量的Batch Insert操作。

      • 产生大量中间结果的聚合操作,如GROUP BYDISTINCT

      • 跨分片的JOIN操作。

    2. 升配CN节点:如果SQL优化后内存压力依旧,需要提升CN节点的内存规格。

    3. 不建议监控内存使用率,而应监控Full GC时间。

逻辑QPS与物理QPS

  • 目的:衡量数据库的分布式查询效率,判断分区键是否被有效利用。

  • 指标分析

    • 逻辑QPS:在PolarDB分布式版控制台监控与报警 > 计算资源监控 > 节点 > 逻辑TPS/逻辑QPS/物理QPS图表中查看,代表CN层接收到的SQL请求数。

    • 物理QPS:在PolarDB分布式版控制台监控与报警 > 计算资源监控 > 节点 > 逻辑TPS/逻辑QPS/物理QPS图表中查看,代表CN层下推到DN层的SQL执行数。

  • 决策建议

    • 物理QPS与逻辑QPS的比例是衡量数据库扩展性的关键指标。理想情况下,该比例应接近1:1,表明绝大多数查询都精确地路由到了单个数据分片,分区键使用良好。

    • 当物理QPS远高于逻辑QPS(例如,实例有16个分片,而比例接近16:1),则表明存在大量未携带分区键的查询,导致了全分片扫描,这会严重消耗系统资源并影响性能。

    • 使用SQL洞察功能,筛选出物理执行次数大于1SQL,即可快速定位需要优化的查询。

说明

为准确反映业务负载,QPS监控指标已自动排除SELECT 1(连接池探活)、SELECT @@...(驱动初始化)及事务控制(commit/rollback/begin)等非业务SQL语句。

监控存储资源(DN)

DN节点负责数据持久化,其I/O、CPU和内存是数据库性能的基石。

CPU使用率

  • 目的:监控DN节点的计算压力。DNCPU过高通常与大量复杂计算下推或I/O瓶颈有关。

  • 决策建议:

    1. 优化SQL:检查是否存在慢查询或全表扫描,优化索引设计。

    2. 升配DN节点:提升DN节点的CPU和内存规格。

    3. 增加DN节点:增加DN节点数量以分散负载。此操作会触发数据重分布并消耗资源,建议在业务低峰期进行。

内存

  • 目的:监控DN节点的内存健康,特别是缓冲池(Buffer Pool)的效率。

  • 指标分析

    • 内存使用率:DN节点的内存主要用于Buffer Pool,该部分内存在进程启动时即分配,因此内存使用率长期维持在90%以上是正常且健康的状态。

    • 缓冲池读命中率:在PolarDB分布式版控制台监控与报警 > 存储资源监控 > 节点 > 内存缓冲池图表中查看。该指标是DN内存性能的核心。所有数据读写都需经过Buffer Pool,命中率越高,意味着从磁盘读取数据的次数越少。对于在线交易(OLTP)业务,此值维持在98%以上是健康水位。低于此值,性能会因磁盘I/O增加而下降。

IOPS使用率

  • 目的:监控磁盘I/O压力,这是常见的性能瓶颈之一。

  • 指标分析:在PolarDB分布式版控制台监控与报警 > 存储资源监控 > 节点 > IOPS使用率图表中查看。IOPS使用率通常与缓冲池读命中率负相关。当缓冲池无法缓存所有热点数据时,磁盘I/O会上升。当IOPS使用率持续处于高位,SQL延迟会显著增加。

监控日志与列存资源 (CDC & Columnar)

仅在开启相关功能时,才需关注这些组件的监控。

  • CDC日志节点:在使用全局Binlog(例如通过DTS、Canal订阅)时,需要监控CDC日志节点。核心关注日志节点的CPU使用率处理延迟。延迟过高表明日志处理不过来,可能需要升配CDC节点。

  • Columnar列存节点

    • 延迟列存同步延迟是一个关键指标。在正常情况下,列存节点的数据同步延迟维持在秒级。当延迟扩展至分钟级时,表明当前负载较大。如果延迟持续增加,则可能存在同步中断的风险。

    • CPU/内存:列存节点是Java程序,其CPU和内存监控方法可参考CN节点。CPU持续高位且延迟增大时,需要对Columnar节点进行升配。

配置告警规则

为确保及时发现并处理问题,需要为上述核心指标配置告警规则。

  1. PolarDB分布式版控制台监控与报警对应的计算/存储/日志/列存资源监控页面中,单击设置报警规则

  2. 根据下表建议配置各项指标的报警规则。建议将触发条件设置为连续3个周期,以避免因瞬时波动导致误报。

  3. 最后配置报警联系人组,以确保在触发告警时收到通知。

建议告警项汇总

组件

云监控产品名

云监控指标名

建议报警阈值

CN(计算节点)

云原生分布式数据库PolarDB-X 2.0 计算节点

PolarDB-X计算层CPU使用率

70%

DN(存储节点)

云原生分布式数据库PolarDB-X 2.0 存储节点

PolarDB-X存储节点CPU使用率

70%

PolarDB-X存储节点 IOPS 使用率

70%

PolarDB-X存储节点磁盘使用率

85%

CDC(日志节点)

云原生分布式数据库PolarDB-X 2.0 日志节点

PolarDB-X CDC DumperCPU使用率

70%

PolarDB-X CDC Dumper延迟

10

说明

上述表格中没有提到的监控项意味着通常不需要对这类指标设置报警规则,但不代表这些指标没有用处,在故障排查等场景下,这些指标仍然可能具有参考意义。