INSPECTION_RESULT

    该诊断功能可以帮助用户快速发现问题，减少用户的重复性手动工作。可使用 select * from information_schema.inspection_result 语句来触发内部诊断。

    诊断结果表 information_schema.inspection_result 的表结构如下：

    1. +----------------+--------------+------+------+---------+-------+
    2. | Field          | Type         | Null | Key  | Default | Extra |
    3. +----------------+--------------+------+------+---------+-------+
    4. | RULE           | varchar(64)  | YES  |      | NULL    |       |
    5. | ITEM           | varchar(64)  | YES  |      | NULL    |       |
    6. | TYPE           | varchar(64)  | YES  |      | NULL    |       |
    7. | INSTANCE       | varchar(64)  | YES  |      | NULL    |       |
    8. | STATUS_ADDRESS | varchar(64)  | YES  |      | NULL    |       |
    9. | VALUE          | varchar(64)  | YES  |      | NULL    |       |
    10. | REFERENCE      | varchar(64)  | YES  |      | NULL    |       |
    11. | SEVERITY       | varchar(64)  | YES  |      | NULL    |       |
    12. | DETAILS        | varchar(256) | YES  |      | NULL    |       |
    13. +----------------+--------------+------+------+---------+-------+
    14. 9 rows in set (0.00 sec)

    字段解释：

    • RULE：诊断规则名称，目前实现了以下规则：
      • config：配置一致性以及合理性检测。如果同一个配置在不同实例不一致，会生成 warning 诊断结果。
      • version：版本一致性检测。如果同一类型的实例版本不同，会生成 critical 诊断结果。
      • node-load：服务器负载检测。如果当前系统负载太高，会生成对应的 warning 诊断结果。
      • critical-error：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 warning 诊断结果。
      • threshold-check：诊断系统会对一些关键指标进行阈值判断，如果超过阈值会生成对应的诊断信息。
    • ITEM：每一个规则会对不同的项进行诊断，该字段表示对应规则下面的具体诊断项。
    • TYPE：诊断的实例类型，可取值为 tidb，pd 和 tikv。
    • INSTANCE：诊断的具体实例地址。
    • STATUS_ADDRESS：实例的 HTTP API 服务地址。
    • VALUE：针对这个诊断项得到的值。
    • REFERENCE：针对这个诊断项的参考值（阈值）。如果 VALUE 超过阈值，就会产生对应的诊断信息。
    • SEVERITY：严重程度，取值为 warning 或 critical。
    • DETAILS：诊断的详细信息，可能包含进一步调查的 SQL 或文档链接。

    对当前时间的集群进行诊断。

    1. SELECT * FROM information_schema.inspection_result\G
    1. ***************************[ 1. row ]***************************
    2. RULE      | config
    3. ITEM      | log.slow-threshold
    4. TYPE      | tidb
    5. INSTANCE  | 172.16.5.40:4000
    6. VALUE     | 0
    7. REFERENCE | not 0
    8. SEVERITY  | warning
    9. DETAILS   | slow-threshold = 0 will record every query to slow log, it may affect performance
    10. ***************************[ 2. row ]***************************
    12. ITEM      | git_hash
    13. TYPE      | tidb
    14. INSTANCE  |
    15. REFERENCE | consistent
    16. SEVERITY  | critical
    17. DETAILS   | the cluster has 2 different tidb version, execute the sql to see more detail: select * from information_schema.cluster_info where type='tidb'
    18. ***************************[ 3. row ]***************************
    19. RULE      | threshold-check
    20. ITEM      | storage-write-duration
    21. TYPE      | tikv
    22. INSTANCE  | 172.16.5.40:23151
    23. VALUE     | 130.417
    24. REFERENCE | < 0.100
    25. SEVERITY  | warning
    26. DETAILS   | max duration of 172.16.5.40:23151 tikv storage-write-duration was too slow
    27. ***************************[ 4. row ]***************************
    28. RULE      | threshold-check
    29. ITEM      | rocksdb-write-duration
    30. TYPE      | tikv
    31. INSTANCE  | 172.16.5.40:20151
    32. VALUE     | 108.105
    33. REFERENCE | < 0.100
    34. SEVERITY  | warning
    35. DETAILS   | max duration of 172.16.5.40:20151 tikv rocksdb-write-duration was too slow

    上述诊断结果发现了以下几个问题：

    • 第一行表示 TiDB 的 log.slow-threshold 配置值为 0，可能会影响性能。
    • 第二行表示集群中有 2 个不同的 TiDB 版本
    • 第三、四行表示 TiKV 的写入延迟太大，期望时间是不超过 0.1s, 但实际值远超预期。

    诊断集群在时间段 “2020-03-26 00:03:00”, “2020-03-26 00:08:00” 的问题。指定时间范围需要使用 /*+ time_range() */ 的 SQL Hint，参考下面的查询示例：

    1. ***************************[ 1. row ]***************************
    2. RULE      | critical-error
    3. ITEM      | server-down
    4. TYPE      | tidb
    5. INSTANCE  | 172.16.5.40:4009
    6. VALUE     |
    7. REFERENCE |
    8. SEVERITY  | critical
    9. DETAILS   | tidb 172.16.5.40:4009 restarted at time '2020/03/26 00:05:45.670'
    10. ***************************[ 2. row ]***************************
    11. RULE      | threshold-check
    12. ITEM      | get-token-duration
    13. TYPE      | tidb
    14. INSTANCE  | 172.16.5.40:10089
    15. VALUE     | 0.234
    16. REFERENCE | < 0.001
    17. SEVERITY  | warning
    18. DETAILS   | max duration of 172.16.5.40:10089 tidb get-token-duration is too slow

    上面的诊断结果发现了以下问题：

    • 第一行表示 172.16.5.40:4009 TiDB 实例在 2020/03/26 00:05:45.670 发生了重启。
    • 第二行表示 172.16.5.40:10089 TiDB 实例的最大的 get-token-duration 时间为 0.234s, 期望时间是小于 0.001s。
    1. select * from information_schema.inspection_result where severity='critical';

    只查询 critical-error 规则的诊断结果:

    1. select * from information_schema.inspection_result where rule='critical-error';

    诊断规则介绍

    诊断模块内部包含一系列的规则，这些规则会通过查询已有的监控表和集群信息表，对结果和阈值进行对比。如果结果超过阈值将生成 warning 或 的结果，并在 details 列中提供相应信息。

    可以通过查询 inspection_rules 系统表查询已有的诊断规则:

    1. +-----------------+------------+---------+
    2. | NAME            | TYPE       | COMMENT |
    3. +-----------------+------------+---------+
    4. | version         | inspection |         |
    5. | node-load       | inspection |         |
    6. | critical-error  | inspection |         |
    7. | threshold-check | inspection |         |
    8. +-----------------+------------+---------+

    config 诊断规则通过查询 CLUSTER_CONFIG 系统表，执行以下两个诊断规则：

    • 检测相同组件的配置值是否一致，并非所有配置项都会有一致性检查，下面是一致性检查的白名单：

      1.   // TiDB 配置一致性检查白名单
      2.   port
      3.   status.status-port
      4.   host
      5.   path
      6.   advertise-address
      7.   status.status-port
      8.   log.file.filename
      9.   log.slow-query-file
      10.   tmp-storage-path
      12.   // PD 配置一致性检查白名单
      13.   advertise-client-urls
      14.   advertise-peer-urls
      15.   client-urls
      16.   data-dir
      17.   log-file
      18.   log.file.filename
      19.   metric.job
      20.   name
      21.   peer-urls
      23.   // TiKV 配置一致性检查白名单
      24.   server.addr
      25.   server.advertise-addr
      26.   server.status-addr
      27.   log-file
      28.   raftstore.raftdb-path
      29.   storage.data-dir
      30.   storage.block-cache.capacity

    • 检测以下配置项的值是否符合预期。

      | 组件 | 配置项 | 预期值 | | :—— | :—— | :—— | | TiDB | log.slow-threshold | 大于 0 | | TiKV | raftstore.sync-log | true |

    1. SELECT * FROM information_schema.inspection_result WHERE rule='version'\G

    critical-error 诊断规则执行以下两个诊断规则：

    • 通过查询 数据库中相关的监控系统表，检测集群是否有出现以下比较严重的错误：

      | 组件 | 错误名字 | 相关监控表 | 错误说明 | | —— | —— | —— | —— | | TiDB | panic-count | tidb_panic_count_total_count | TiDB 出现 panic 错误 | | TiDB | binlog-error | tidb_binlog_error_total_count | TiDB 写 binlog 时出现的错误 | | TiKV | critical-error | tikv_critical_error_total_coun | TiKV 的 critical error | | TiKV | scheduler-is-busy | tikv_scheduler_is_busy_total_count | TiKV 的 scheduler 太忙，会导致 TiKV 临时不可用 | | TiKV | coprocessor-is-busy | tikv_coprocessor_is_busy_total_count | TiKV 的 coprocessor 太忙 | | TiKV | channel-is-full | tikv_channel_full_total_count | TiKV 出现 channel full 的错误 | | TiKV | tikv_engine_write_stall | tikv_engine_write_stall | TiKV 出现写入 stall 的错误 |

    • 通过查询 metrics_schema.up 监控表和 CLUSTER_LOG 系统表，检查是否有组件发生重启。

    threshold-check 诊断规则通过查询 metrics schema 数据库中相关的监控系统表，检测集群中以下指标是否超出阈值：

    另外还会检测 TiKV 实例的以下 thread cpu usage 是否过高:

    • scheduler-worker-cpu
    • coprocessor-normal-cpu
    • coprocessor-high-cpu
    • coprocessor-low-cpu
    • grpc-cpu
    • raftstore-cpu
    • apply-cpu
    • storage-readpool-normal-cpu
    • storage-readpool-high-cpu
    • split-check-cpu

    TiDB 内置的诊断规则还在不断的完善改进中，如果你也想到了一些诊断规则，非常欢迎在 下提 PR 或 Issue。