3.4 监控汇总表

以查询 ['2020-03-08 13:23:00', '2020-03-08 13:33:00') 时间范围内 TiDB 集群中平均耗时最高的 3 组监控项为例。通过直接查询 表，并通过 /*+ time_range() */ 这个 hint 来指定时间范围来构造以下 SQL：

类似的，查询 metrics_summary_by_label 监控汇总表结果如下：

2. 推荐用法

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

• 时间段 t1 : (“2020-03-03 17:08:00”, “2020-03-03 17:11:00”)

对两个时间段的监控按照 METRICS_NAME 进行 join，并按照差值排序。其中 /*+ time_range() */ 是用于指定查询时间的 hint。

1. 查询 t1.avg_value / t2.avg_value 差异最大的 10 个监控项

查询结果表示：

• t1 时间段内的 tikv_region_average_written_bytes （region 的平均写入字节数） 比 t2 时间段高了 17.6 倍
• t1 时间段内的 tikv_region_average_written_keys （region 的平均写入 keys 数） 比 t2 时间段高了 8.8 倍

1. 反过来，查询 t2.avg_value / t1.avg_value 差异最大的 10 个监控项

上面查询结果表示：

• 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 时间段内的 tikv_cop_scan_details（tikv 的 cop 请求的 scan ） 比 t1 时间段高了 105 倍

通过上面两个时间段对比查询可以大致了解集群在这 2 个时间段的负载情况。t2 时间段的 Cop 请求要比 t2 时间段高很多，导致 TiKV 的 Copprocessor 过载，出现了 cop task 等待，可以猜测可能是 t2 时间段出现了一些大查询，或者是查询较多的负载。

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