METRICS_SUMMARY

    • information_schema.metrics_summary_by_label

    这两张表用于汇总所有监控数据,用户排查各个监控指标会更有效率。其中 information_schema.metrics_summary_by_label 会对不同的 label 进行区分统计。

    1. +--------------+--------------+------+------+---------+-------+
    2. | Field | Type | Null | Key | Default | Extra |
    3. +--------------+--------------+------+------+---------+-------+
    4. | METRICS_NAME | varchar(64) | YES | | NULL | |
    5. | QUANTILE | double | YES | | NULL | |
    6. | SUM_VALUE | double(22,6) | YES | | NULL | |
    7. | AVG_VALUE | double(22,6) | YES | | NULL | |
    8. | MIN_VALUE | double(22,6) | YES | | NULL | |
    9. | MAX_VALUE | double(22,6) | YES | | NULL | |
    10. | COMMENT | varchar(256) | YES | | NULL | |
    11. +--------------+--------------+------+------+---------+-------+
    12. 7 rows in set (0.00 sec)

    字段解释:

    • METRICS_NAME:监控表名。
    • QUANTILE:百分位。可以通过 SQL 语句指定 QUANTILE,例如:
      • select * from metrics_summary where quantile=0.99 指定查看百分位为 0.99 的数据。
      • select * from metrics_summary where quantile in (0.80, 0.90, 0.99, 0.999) 同时查看百分位为 0.80, 0.90, 0.99, 0.999 的数据。
    • SUM_VALUE、AVG_VALUE、MIN_VALUE、MAX_VALUE 分别表示总和、平均值、最小值、最大值。
    • COMMENT:对应监控的解释。

    具体查询示例:

    1. ***************************[ 1. row ]***************************
    2. METRICS_NAME | tidb_get_token_duration
    3. QUANTILE | 0.99
    4. SUM_VALUE | 8.972509
    5. AVG_VALUE | 0.996945
    6. MIN_VALUE | 0.996515
    7. MAX_VALUE | 0.997458
    8. COMMENT | The quantile of Duration (us) for getting token, it should be small until concurrency limit is reached(second)
    9. ***************************[ 2. row ]***************************
    10. METRICS_NAME | tidb_query_duration
    11. QUANTILE | 0.99
    12. AVG_VALUE | 0.007272
    13. MAX_VALUE | 0.01554
    14. COMMENT | The quantile of TiDB query durations(second)
    15. ***************************[ 3. row ]***************************
    16. METRICS_NAME | tidb_kv_request_duration
    17. QUANTILE | 0.99
    18. SUM_VALUE | 0.170232
    19. AVG_VALUE | 0.004601
    20. MIN_VALUE | 0.000975
    21. MAX_VALUE | 0.013
    22. COMMENT | The quantile of kv requests durations by store

    类似的,查询 metrics_summary_by_label 监控汇总表示例如下:

    1. ***************************[ 1. row ]***************************
    2. INSTANCE | 172.16.5.40:10089
    3. METRICS_NAME | tidb_get_token_duration
    4. LABEL |
    5. QUANTILE | 0.99
    6. SUM_VALUE | 8.972509
    7. AVG_VALUE | 0.996945
    8. MIN_VALUE | 0.996515
    9. MAX_VALUE | 0.997458
    10. COMMENT | The quantile of Duration (us) for getting token, it should be small until concurrency limit is reached(second)
    11. ***************************[ 2. row ]***************************
    12. INSTANCE | 172.16.5.40:10089
    13. METRICS_NAME | tidb_query_duration
    14. LABEL | Select
    15. QUANTILE | 0.99
    16. SUM_VALUE | 0.072083
    17. AVG_VALUE | 0.008009
    18. MIN_VALUE | 0.007905
    19. MAX_VALUE | 0.008241
    20. ***************************[ 3. row ]***************************
    21. INSTANCE | 172.16.5.40:10089
    22. METRICS_NAME | tidb_query_duration
    23. LABEL | Rollback
    24. QUANTILE | 0.99
    25. SUM_VALUE | 0.072083
    26. MIN_VALUE | 0.007905
    27. MAX_VALUE | 0.008241
    28. COMMENT | The quantile of TiDB query durations(second)

    前文提到 metrics_summary_by_label 表结构相对于 metrics_summary 多了一列 LABEL。以上面查询结果的第 2、3 行分别表示 tidb_query_durationSelectRollback 类型的语句平均耗时非常高。

    除以上示例之外,监控汇总表可以通过对比两个时间段的全链路监控,迅速找出监控数据中变化最大的模块,快速定位瓶颈。以下示例对比两个时间段的所有监控(其中 t1 为 baseline),并按照差别最大的监控排序:

    • 时间段 t1:("2020-03-03 17:08:00", "2020-03-03 17:11:00")
    • 时间段 t2:("2020-03-03 17:18:00", "2020-03-03 17:21:00")
    1. +----------------+------------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+
    2. | ratio | metrics_name | t1_avg_value | t2_avg_value | comment |
    3. +----------------+------------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+
    4. | 5865.59537065 | tidb_slow_query_cop_process_total_time | 0.016333 | 95.804724 | The total time of TiDB slow query statistics with slow query total cop process time(second) |
    5. | 3648.74109023 | tidb_distsql_partial_scan_key_total_num | 10865.666667 | 39646004.4394 | The total num of distsql partial scan key numbers |
    6. | 267.002351165 | tidb_slow_query_cop_wait_total_time | 0.003333 | 0.890008 | The total time of TiDB slow query statistics with slow query total cop wait time(second) |
    7. | 192.43267836 | tikv_cop_total_response_total_size | 2515333.66667 | 484032394.445 | |
    8. | 192.43267836 | tikv_cop_total_response_size_per_seconds | 41922.227778 | 8067206.57408 | |
    9. | 152.780296296 | tidb_distsql_scan_key_total_num | 5304.333333 | 810397.618317 | The total num of distsql scan numbers |
    10. | 126.042290167 | tidb_distsql_execution_total_time | 0.421622 | 53.142143 | The total time of distsql execution(second) |
    11. | 105.164020657 | tikv_cop_scan_details | 134.450733 | 14139.379665 | |
    12. | 105.164020657 | tikv_cop_scan_details_total | 8067.043981 | 848362.77991 | |
    13. | 101.635495394 | tikv_cop_scan_keys_num | 1070.875 | 108838.91113 | |
    14. +----------------+------------------------------------------+----------------+------------------+---------------------------------------------------------------------------------------------+

    上面查询结果表示:

    • t2 时间段内的 tidb_slow_query_cop_process_total_time(TiDB 慢查询中的 cop process 耗时)比 t1 时间段高了 5865 倍。
    • t2 时间段内的 tidb_distsql_partial_scan_key_total_num(TiDB 的 distsql 请求扫描 key 的数量)比 t1 时间段高了 3648 倍。
    • t2 时间段内的 tidb_slow_query_cop_wait_total_time(TiDB 慢查询中的 cop 请求排队等待的耗时)比 t1 时间段高了 267 倍。
    • t2 时间段内的 tikv_cop_total_response_size(TiKV 的 cop 请求结果的大小)比 t1 时间段高了 192 倍。
    • t2 时间段内的 tikv_cop_scan_details(TiKV 的 cop 请求的 scan)比 t1 时间段高了 105 倍。

    综上,可以马上知道 t2 时间段的 cop 请求要比 t2 时间段高很多,导致 TiKV 的 Coprocessor 过载,出现了 cop task 等待,可以猜测可能是 t2 时间段出现了一些大查询,或者是查询较多的负载。

    实际上,在 t1 ~ t2 整个时间段内都在跑 go-ycsb 的压测,然后在 t2 时间段跑了 20 个 tpch 的查询,所以是因为 大查询导致了出现很多的 cop 请求。