【TiDB 4.0 PCTA 学习笔记】- 3.7.1 Metrics that DBAs should notice(运维中的关键监控)@2班+邱育珍

课程名称:3.7.1 Metrics that DBAs should notice(运维中的关键监控)

学习时长:30min

课程收获:

DBA 需要关注的一些和性能相关的 metrics,模块包括 system info、TiDB、TiKV、PD 以及 Dashboard。

课程内容:

对于日常运维,我们单独挑选出重要的 Metrics 放在 Overview 页面,方便日常运维人员观察集群组件 (PD, TiDB, TiKV) 使用状态以及集群使用状态。

以下为 Overview Dashboard 监控说明:

Services Port Status

  • Services Up:各服务在线节点数量

PD

  • etcd

    • 99% WAL fsync duration:99% 的情况下,持久化 WAL 所需花费的时间,这个值通常应该小于 1s,最好是< 5ms
    • 99% Region heartbeat latency:99% 的情况下,心跳的延迟,最好是< 5ms
  • 监控指标介绍

    • PD role:当前 PD 的角色
    • Storage capacity:TiDB 集群总可用数据库空间大小
    • Current storage size:TiDB 集群目前已用数据库空间大小,TiKV 多副本的空间占用也会包含在内
    • Normal stores:处于正常状态的节点数目
    • Abnormal stores:处于异常状态的节点数目,正常情况应当为 0
    • Number of Regions:当前集群的 Region 总量,请注意 Region 数量与副本数无关
    • 99% completed_cmds_duration_seconds:单位时间内,99% 的 pd-server 请求执行时间小于监控曲线的值,一般 <= 5ms
    • Handle_requests_duration_seconds:PD 发送请求的网络耗时
    • Region health:每个 Region 的状态,通常情况下,pending 的 peer 应该少于 100,miss 的 peer 不能一直大于 0
    • Hot write Region’s leader distribution:每个 TiKV 实例上是写入热点的 leader 的数量
    • Hot read Region’s leader distribution:每个 TiKV 实例上是读取热点的 leader 的数量
    • Region heartbeat report:TiKV 向 PD 发送的心跳个数
    • 99% Region heartbeat latency:99% 的情况下,心跳的延迟

TiDB

主要关注点
image

  • Query

    • 时长:99%时延应小于100ms(OLTP)
    • 慢查询:不应有太多慢查询,关注原因
    • Ideal CPS(Command Per Second):默认不可见参数,通过编辑grafana变为可见,该指标可以看出延迟是在TiDB端还是在客户端
  • Server

    • Get token duration:最好小于1ms,若高,说明token-limit(默认1000)配置不合理
      确认token-limit数量大于连接数
      获取token,是为了对连接限流
  • Executor

    • Parse duration:最好<10ms
    • Compile duration:最好小于30ms
  • Errors:KV Errors

    • Lock Resolve OPS:对于 expired和not-expired最好小于500,否则说明冲突较多;如果业务就是有很多锁,可以考虑使用悲观锁。
    • KV Backoff OPS:对于txnLockFast和txnLock,最好小于500
  • PD Client:PD TSO .99 Wait Duration:最好小于5ms

监控指标介绍

  • Statement OPS:不同类型 SQL 语句每秒执行的数量。按 SELECTINSERTUPDATE 等来统计
  • Duration:执行的时间
    • 客户端网络请求发送到 TiDB,到 TiDB 执行结束后返回给客户端的时间。一般情况下,客户端请求都是以 SQL 语句的形式发送,但也可以包含 COM_PINGCOM_SLEEPCOM_STMT_FETCHCOM_SEND_LONG_DATA 之类的命令执行的时间
    • 由于 TiDB 支持 Multi-Query,因此,可以接受客户端一次性发送的多条 SQL 语句,如: select 1; select 1; select 1; 。此时,统计的执行时间是所有 SQL 执行完之后的总时间
  • QPS By Instance:每个 TiDB 上的 QPS。按照命令和执行结果成功或失败来统计
  • Failed Query OPM:每个 TiDB 实例上,每秒钟执行 SQL 语句发生错误按照错误类型的统计(例如语法错误、主键冲突等)。包含了错误所属的模块和错误码
  • Connection count:每个 TiDB 的连接数
  • Memory Usage:每个 TiDB 实例的内存使用统计,分为进程占用内存和 Golang 在堆上申请的内存
  • Transaction OPS:每秒事务执行数量统计
  • Transaction Duration:事务执行的时间
  • KV Cmd OPS:KV 命令执行数量统计
  • KV Cmd Duration 99:KV 命令执行的时间
  • PD TSO OPS:TiDB 每秒从 PD 获取 TSO 的数量
  • PD TSO Wait Duration:TiDB 等待从 PD 获取 TS 的时间
  • TiClient Region Error OPS:TiKV 返回 Region 相关错误信息的数量
  • Lock Resolve OPS:TiDB 清理锁操作的数量。当 TiDB 的读写请求遇到锁时,会尝试进行锁清理
  • Load Schema Duration:TiDB 从 TiKV 获取 Schema 的时间
  • KV Backoff OPS:TiKV 返回错误信息的数量

TiKV

重点关注指标
image

  • Cluster
    Region:最好<50K ,否则可能需要region merge和hibernate region;太大会造成心跳检测消耗高

  • gRPC
    .99 gRPC message duration:越低越好,最好小于100ms(除了复杂的协处理器请求)

  • Thread CPU

    • Raft store CPU:better < 75% * raftsore.store-pool-size
    • Async apply CPU:better < 75%* raftstore.apply-pool-size
    • Scheduler worker CPU:better < 80% * storage.scheduler-worker-pool-size
    • gRPC poll CPU:better < 80% * server.grpc-concurrency
    • Unified read pool CPU:better < 80% * readpool.unified.max-thread-count
    • Storage ReadPool CPU:better < 80% * readpool.storage.normal-concurrency
  • Raft IO

    • Apply log duration:Raft apply 日志所花费的时间 (99.99% <30ms)
    • Append log duration:Raft append 日志并持久化到磁盘上所花费的时间 (99.99% <10ms)
    • Commit log duration:Raft commit 日志所花费的时间 (99.99% <30ms)
    • 以上项的99.999%的时间消耗
  • Raft propose

    • Propose wait duration:proposal 的等待时间的直方图 99.99% < 20ms
    • Apply wait duration:apply 的等待时间的直方图 99.99% < 50ms
    • 以上项的99.999%的时间消耗,是否有毛刺
  • Errors
    Server is busy:各种会导致 TiKV 实例暂时不可用的事件个数,如 write stall,channel full 等,正常情况下应当为 0

监控指标介绍

  • leader:各个 TiKV 节点上 Leader 的数量分布
  • region:各个 TiKV 节点上 Region 的数量分布,最好<50K ,否则可能需要region merge和hibernate region
  • CPU:各个 TiKV 节点的 CPU 使用率
  • Memory:各个 TiKV 节点的内存使用量
  • store size:每个 TiKV 实例的使用的存储空间的大小
  • cf size:每个列族的大小
  • channel full:每个 TiKV 实例上 channel full 错误的数量,正常情况下应当为 0
  • server report failures:每个 TiKV 实例上报错的消息个数,正常情况下应当为 0
  • scheduler pending commands:每个 TiKV 实例上 pending 命令的个数
  • coprocessor executor count:TiKV 每秒收到的 coprocessor 操作数量,按照 coprocessor 类型统计
  • coprocessor request duration:处理 coprocessor 读请求所花费的时间
  • raft store CPU:raftstore 线程的 CPU 使用率,线程数量默认为 2 (通过 raftstore.store-pool-size 配置)。如果单个线程使用率超过 80%,说明使用率很高
  • Coprocessor CPU:coprocessor 线程的 CPU 使用率

System Info

主要关注点

System Info 监控指标介绍

  • Vcores:CPU 核心数量
  • Memory:内存总大小
  • CPU Usage:CPU 使用率,最大为 100%。CPU %超过80%可能成为整个系统的一个瓶颈
  • Load [1m]:1 分钟的负载情况, 应小于核数,否则可能成为系统瓶颈
  • Memory Available:剩余内存大小; TiKV:usage < 60%, TiDB:20% free
  • Network Traffic:网卡流量统计
  • TCP Retrans:TCP 重传数量统计
  • IO Util:磁盘使用率,最高为 100%,一般到 80% - 90% 就需要考虑加节点

Dashboard 监控项

访问地址http://pdaddr:PdPort/dashboard
image

学习过程中参考的其他资料

同学你好,感谢参与 TiDB 4.0 课程的学习!

本篇笔记逻辑清晰、内容丰富,被评选为优质笔记,将额外获得 20 积分,并在 「TiDB 培训」分类下获得“置顶”权益,积分兑换规则将于近期开放,敬请关注!

期待您继续产出优质内容!