From cddbb2edcaed83b1177ce0bf153bc497a4aa5e8d Mon Sep 17 00:00:00 2001 From: crazycs520 Date: Tue, 19 May 2020 21:14:27 +0800 Subject: [PATCH 01/13] system-table: redine diagnose system table doc Signed-off-by: crazycs520 --- system-tables/system-table-cluster-log.md | 34 +++++++++---------- .../system-table-inspection-result.md | 18 +++++----- .../system-table-inspection-summary.md | 13 ++++--- system-tables/system-table-metrics-schema.md | 14 ++++---- system-tables/system-table-metrics-tables.md | 4 +-- system-tables/system-table-sql-diagnosis.md | 4 +-- 6 files changed, 44 insertions(+), 43 deletions(-) diff --git a/system-tables/system-table-cluster-log.md b/system-tables/system-table-cluster-log.md index 3384be36355b..af64a46aa287 100644 --- a/system-tables/system-table-cluster-log.md +++ b/system-tables/system-table-cluster-log.md @@ -40,35 +40,33 @@ desc information_schema.cluster_log; > **注意：** > -> + 日志表的所有字段都会下推到对应节点执行，所以为了降低使用集群日志表的开销，需尽可能地指定更多的条件。例如 `select * from cluter_log where instance='tikv-1'` 只会在 `tikv-1` 上执行日志搜索。 +> + 日志表的所有字段都会下推到对应节点执行，所以为了降低使用集群日志表的开销，必须指定搜索关键字以及时间范围，然后尽可能地指定更多的条件。例如 `select * from cluster_log where message like '%ddl%' and time > '2020-05-18 20:40:00' and time<'2020-05-18 21:40:00' and type='tidb'`。 > -> + `message` 字段支持 `like` 和 `regexp` 正则表达式，对应的 pattern 会编译为 `regexp`。同时指定多个 `message` 条件，相当于 `grep` 命令的 `pipeline` 形式，例如：`select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*'` 相当于在集群所有节点执行 `grep 'coprocessor' xxx.log | grep -E '.*slow.*'`。 +> + `message` 字段支持 `like` 和 `regexp` 正则表达式，对应的 pattern 会编译为 `regexp`。同时指定多个 `message` 条件，相当于 `grep` 命令的 `pipeline` 形式，例如：`select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*' and time > '2020-05-18 20:40:00' and time<'2020-05-18 21:40:00'` 相当于在集群所有节点执行 `grep 'coprocessor' xxx.log | grep -E '.*slow.*'`。 查询某个 DDL 的执行过程示例如下： {{< copyable "sql" >}} ```sql -select * from information_schema.cluster_log where message like '%ddl%' and message like '%job%58%' and type='tidb' and time > '2020-03-27 15:39:00'; +select time,instance,left(message,150) from information_schema.cluster_log where message like '%ddl%job%ID.80%' and type='tidb' and time > '2020-05-18 20:40:00' and time<'2020-05-18 21:40:00' ``` ``` -+-------------------------+------+------------------+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| TIME | TYPE | INSTANCE | LEVEL | MESSAGE | -+-------------------------+------+------------------+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| 2020/03/27 15:39:36.140 | tidb | 172.16.5.40:4008 | INFO | [ddl_worker.go:253] ["[ddl] add DDL jobs"] ["batch count"=1] [jobs="ID:58, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:57, RowCount:0, ArgLen:1, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0; "] | -| 2020/03/27 15:39:36.140 | tidb | 172.16.5.40:4008 | INFO | [ddl.go:457] ["[ddl] start DDL job"] [job="ID:58, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:57, RowCount:0, ArgLen:1, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0"] [query="create table t3 (a int, b int,c int)"] | -| 2020/03/27 15:39:36.879 | tidb | 172.16.5.40:4009 | INFO | [ddl_worker.go:554] ["[ddl] run DDL job"] [worker="worker 1, tp general"] [job="ID:58, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:57, RowCount:0, ArgLen:0, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0"] | -| 2020/03/27 15:39:36.936 | tidb | 172.16.5.40:4009 | INFO | [ddl_worker.go:739] ["[ddl] wait latest schema version changed"] [worker="worker 1, tp general"] [ver=35] ["take time"=52.165811ms] [job="ID:58, Type:create table, State:done, SchemaState:public, SchemaID:1, TableID:57, RowCount:0, ArgLen:1, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0"] | -| 2020/03/27 15:39:36.938 | tidb | 172.16.5.40:4009 | INFO | [ddl_worker.go:359] ["[ddl] finish DDL job"] [worker="worker 1, tp general"] [job="ID:58, Type:create table, State:synced, SchemaState:public, SchemaID:1, TableID:57, RowCount:0, ArgLen:0, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0"] | -| 2020/03/27 15:39:36.140 | tidb | 172.16.5.40:4009 | INFO | [ddl_worker.go:253] ["[ddl] add DDL jobs"] ["batch count"=1] [jobs="ID:58, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:57, RowCount:0, ArgLen:1, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0; "] | -| 2020/03/27 15:39:36.140 | tidb | 172.16.5.40:4009 | INFO | [ddl.go:457] ["[ddl] start DDL job"] [job="ID:58, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:57, RowCount:0, ArgLen:1, start time: 2020-03-27 15:39:36.129 +0800 CST, Err:, ErrCount:0, SnapshotVersion:0"] [query="create table t3 (a int, b int,c int)"] | -| 2020/03/27 15:39:37.141 | tidb | 172.16.5.40:4008 | INFO | [ddl.go:489] ["[ddl] DDL job is finished"] [jobID=58] | -+-------------------------+------+------------------+-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ ++-------------------------+----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+ +| time | instance | left(message,150) | ++-------------------------+----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+ +| 2020/05/18 21:37:54.784 | 127.0.0.1:4002 | [ddl_worker.go:261] ["[ddl] add DDL jobs"] ["batch count"=1] [jobs="ID:80, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:79, Ro | +| 2020/05/18 21:37:54.784 | 127.0.0.1:4002 | [ddl.go:477] ["[ddl] start DDL job"] [job="ID:80, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:79, RowCount:0, ArgLen:1, start | +| 2020/05/18 21:37:55.327 | 127.0.0.1:4000 | [ddl_worker.go:568] ["[ddl] run DDL job"] [worker="worker 1, tp general"] [job="ID:80, Type:create table, State:none, SchemaState:none, SchemaID:1, Ta | +| 2020/05/18 21:37:55.381 | 127.0.0.1:4000 | [ddl_worker.go:763] ["[ddl] wait latest schema version changed"] [worker="worker 1, tp general"] [ver=70] ["take time"=50.809848ms] [job="ID:80, Type: | +| 2020/05/18 21:37:55.382 | 127.0.0.1:4000 | [ddl_worker.go:359] ["[ddl] finish DDL job"] [worker="worker 1, tp general"] [job="ID:80, Type:create table, State:synced, SchemaState:public, SchemaI | +| 2020/05/18 21:37:55.786 | 127.0.0.1:4002 | [ddl.go:509] ["[ddl] DDL job is finished"] [jobID=80] | ++-------------------------+----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+ ``` 上面查询结果表示： -+ 用户将 DDL JOB ID 为 `58` 的请求发给 `172.16.5.40:4008` TiDB 节点。 -+ `172.16.5.40:4009` TiDB 节点处理这个 DDL 请求，说明此时 `172.16.5.40:4009` 节点是 DDL owner。 -+ DDL JOB ID 为 58 的请求处理完成。 ++ 用户将 DDL JOB ID 为 `80` 的请求发给 `127.0.0.1:4002` TiDB 节点。 ++ `127.0.0.1:4000` TiDB 节点处理这个 DDL 请求，说明此时 `127.0.0.1:4000` 节点是 DDL owner。 ++ DDL JOB ID 为 80 的请求处理完成。 diff --git a/system-tables/system-table-inspection-result.md b/system-tables/system-table-inspection-result.md index 514eb9be95e0..e0db8e2c5a49 100644 --- a/system-tables/system-table-inspection-result.md +++ b/system-tables/system-table-inspection-result.md @@ -39,23 +39,23 @@ desc information_schema.inspection_result; 字段解释： * `RULE`：诊断规则名称，目前实现了以下规则： - * `config`：配置一致性检测。如果同一个配置在不同实例不一致，会生成 `warning` 诊断结果。 + * `config`：配置一致性以及合理性检测。如果同一个配置在不同实例不一致，会生成 `warning` 诊断结果。 * `version`：版本一致性检测。如果同一类型的实例版本不同，会生成 `critical` 诊断结果。 - * `node-load`：如果当前系统负载太高，会生成对应的 `warning` 诊断结果。 + * `node-load`：服务器负载检测，如果当前系统负载太高，会生成对应的 `warning` 诊断结果。 * `critical-error`：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 `warning` 诊断结果。 - * `threshold-check`：诊断系统会对大量指标进行阈值判断，如果超过阈值会生成对应的诊断信息。 + * `threshold-check`：诊断系统会对一些关键指标指标进行阈值判断，如果超过阈值会生成对应的诊断信息。 * `ITEM`：每一个规则会对不同的项进行诊断，该字段表示对应规则下面的具体诊断项。 * `TYPE`：诊断的实例类型，可取值为 `tidb`，`pd` 和 `tikv`。 * `INSTANCE`：诊断的具体实例地址。 * `STATUS_ADDRESS`：实例的 HTTP API 服务地址。 * `VALUE`：针对这个诊断项得到的值。 -* `REFERENCE`：针对这个诊断项的参考值（阈值）。如果 `VALUE` 和阈值相差较大，就会产生对应的诊断信息。 +* `REFERENCE`：针对这个诊断项的参考值（阈值）。如果 `VALUE` 超过阈值，就会产生对应的诊断信息。 * `SEVERITY`：严重程度，取值为 `warning` 或 `critical`。 * `DETAILS`：诊断的详细信息，可能包含进一步调查的 SQL 或文档链接。 ## 诊断示例 -诊断集群当前时间的问题。 +对当前时间的集群进行诊断。 {{< copyable "sql" >}} @@ -160,7 +160,7 @@ select * from information_schema.inspection_result where rule='critical-error'; ## 诊断规则介绍 -诊断模块内部包含一系列的规则，这些规则会通过查询已有的监控表和集群信息表，对结果和预先设定的阈值进行对比。如果结果超过阈值或低于阈值将生成 `warning` 或 `critical` 的结果，并在 `details` 列中提供相应信息。 +诊断模块内部包含一系列的规则，这些规则会通过查询已有的监控表和集群信息表，对结果和阈值进行对比。如果结果超过阈值将生成 `warning` 或 `critical` 的结果，并在 `details` 列中提供相应信息。 可以通过查询 `inspection_rules` 系统表查询已有的诊断规则: @@ -261,7 +261,7 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo | 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 | 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 的错误 | @@ -274,9 +274,9 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo | 组件 | 监控指标 | 相关监控表 | 预期值 | 说明 | | :---- | :---- | :---- | :---- | :---- | -| TiDB | tso-duration | pd_tso_wait_duration | 小于 50 ms | 获取事务 TSO 时间戳的耗时 | +| TiDB | tso-duration | pd_tso_wait_duration | 小于 50 ms | 获取事务 TSO 时间戳的等待耗时 | | TiDB | get-token-duration | tidb_get_token_duration | 小于 1 ms | 查询获取 token 的耗时，相关的 TiDB 配置参数是 token-limit | -| TiDB | load-schema-duration | tidb_load_schema_duration | 小于 1 s | TiDB 更新获取表元信息的耗时 | +| TiDB | load-schema-duration | tidb_load_schema_duration | 小于 1 s | TiDB 更新表元信息的耗时 | | TiKV | scheduler-cmd-duration | tikv_scheduler_command_duration | 小于 0.1 s | TiKV 执行 KV cmd 请求的耗时 | | TiKV | handle-snapshot-duration | tikv_handle_snapshot_duration | 小于 30 s | TiKV 处理 snapshot 的耗时 | | TiKV | storage-write-duration | tikv_storage_async_request_duration | 小于 0.1 s | TiKV 写入的延迟 | diff --git a/system-tables/system-table-inspection-summary.md b/system-tables/system-table-inspection-summary.md index b2dca671c272..ff0fb9ce4996 100644 --- a/system-tables/system-table-inspection-summary.md +++ b/system-tables/system-table-inspection-summary.md @@ -7,7 +7,7 @@ aliases: ['/docs-cn/dev/reference/system-databases/inspection-summary/'] # INSPECTION_SUMMARY -在部分场景下，用户只关注特定链路或模块的监控汇总。例如当前 Coprocessor 配置的线程池为 8，如果 Coprocessor 的 CPU 使用率达到了 750%，可以确定存在风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。排查这部分场景的问题也非常重要，所以 TiDB 提供了 `inspection_summary` 来进行链路汇总。 +在部分场景下，用户只需要关注特定链路或模块的监控汇总。例如当前 Coprocessor 配置的线程池为 8，如果 Coprocessor 的 CPU 使用率达到了 750%，就可以确定存在风险，或者可能提前成为瓶颈。但是部分监控会因为用户的 workload 不同而差异较大，所以难以定义确定的阈值。排查这部分场景的问题也非常重要，所以 TiDB 提供了 `inspection_summary` 来进行链路汇总。 诊断汇总表 `information_schema.inspection_summary` 的表结构如下： @@ -38,7 +38,7 @@ desc information_schema.inspection_summary; * `RULE`：汇总规则。由于规则在持续添加，最新的规则列表可以通过 `select * from inspection_rules where type='summary'` 查询。 * `INSTANCE`：监控的具体实例。 -* `METRICS_NAME`：监控表。 +* `METRICS_NAME`：监控表的名字。 * `QUANTILE`：对于包含 `QUANTILE` 的监控表有效，可以通过谓词下推指定多个百分位，例如 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)` 来汇总 DDL 相关监控，查询百分位为 80/90/99/999 的结果。`AVG_VALUE`、`MIN_VALUE`、`MAX_VALUE` 分别表示聚合的平均值、最小值、最大值。 * `COMMENT`：对应监控的解释。 @@ -48,9 +48,12 @@ desc information_schema.inspection_summary; 使用示例: -诊断结果表和诊断监控汇总表都可以通过 `hint` 的方式指定诊断的时间范围，例如 `select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` 是对 2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，诊断结果表通过对比两个不同时间段的数据，快速发现差异较大的监控项。以下为一个例子： +诊断结果表和诊断监控汇总表都可以通过 `hint` 的方式指定诊断的时间范围，例如 `select /*+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` 是对 2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，`inspection_summary` 系统表也可以通过对比两个不同时间段的数据，快速发现差异较大的监控项。以下为一个例子： -诊断集群在时间段 `"2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933"` 的故障: +对比以下两个时间段读系统链路的监控项: + +* `(2020-01-16 16:00:54.933, 2020-01-16 16:10:54.933)` +* `(2020-01-16 16:10:54.933, 2020-01-16 16:20:54.933)` {{< copyable "sql" >}} @@ -68,7 +71,7 @@ FROM JOIN ( SELECT - /*+ time_range("2020-01-16 16:10:54.933","2020-01-16 16:20:54.933")*/ * + /*+ time_range("2020-01-16 16:10:54.933", "2020-01-16 16:20:54.933")*/ * FROM information_schema.inspection_summary WHERE rule='read-link' ) t2 ON t1.metrics_name = t2.metrics_name diff --git a/system-tables/system-table-metrics-schema.md b/system-tables/system-table-metrics-schema.md index b281f7d3d8b8..67723918136a 100644 --- a/system-tables/system-table-metrics-schema.md +++ b/system-tables/system-table-metrics-schema.md @@ -7,13 +7,13 @@ aliases: ['/docs-cn/dev/reference/system-databases/metrics-schema/'] # Metrics Schema -为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表。所有表都在 metrics schema 中，可以通过 SQL 的方式查询监控。实际上，SQL 诊断，以及 `metrics_summary`，`metrics_summary_by_label`，`inspection_result` 这三个监控相关的汇总表数据都是通过查询 metrics schema 库中的各种监控表来获取信息的。目前添加的系统表数量较多，用户可以通过 [`information_schema.metrics_tables`](/system-tables/system-table-metrics-tables.md) 查询这些表的相关信息。 +为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表。所有表都在 `metrics_schema` 数据库中，可以通过 SQL 的方式查询监控。实际上，SQL 诊断，以及 `metrics_summary`，`metrics_summary_by_label`，`inspection_result` 这三个监控相关的汇总表数据都是通过查询 metrics schema 库中的各种监控表来获取信息的。目前添加的系统表数量较多，用户可以通过 [`information_schema.metrics_tables`](/system-tables/system-table-metrics-tables.md) 查询这些表的相关信息。 ## 概览 -下面以 `tidb_query_duration` 表来作为示例介绍监控表相关的使用和原理，其他的监控表原理都是类似的。 +下面以 `metrics_schema` 中的 `tidb_query_duration` 监控表来作为示例介绍监控表相关的使用和原理，其他的监控表原理都是类似的。 -先查询 `information_schema.metrics_tables` 中关于 `tidb_query_duration` 表相关的信息： +查询 `information_schema.metrics_tables` 中关于 `tidb_query_duration` 表相关的信息如下： {{< copyable "sql" >}} @@ -29,9 +29,9 @@ select * from information_schema.metrics_tables where table_name='tidb_query_dur +---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+----------+----------------------------------------------+ ``` -* `TABLE_NAME`：对应于 metrics schema 中的表名，这里表名是 `tidb_query_duration`。 -* `PROMQL`：因为监控表的原理是将 SQL 映射成 `PromQL`，并将 Prometheus 结果转换成 SQL 查询结果。这个字段是 `PromQL` 的表达式模板，获取监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 -* `LABELS`：监控定义的 label，`tidb_query_duration` 有两个 label，分别是 `instance` 和 `sql_type`。 +* `TABLE_NAME`：对应于 `metrics_schema` 中的表名，这里表名是 `tidb_query_duration`。 +* `PROMQL`：因为监控表的原理是将 SQL 映射成 `PromQL` 后向 Prometheus 请求数据，并将 Prometheus 返回的结果转换成 SQL 查询结果。这个字段是 `PromQL` 的表达式模板，查询监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 +* `LABELS`：监控项定义的 label，`tidb_query_duration` 有两个 label，分别是 `instance` 和 `sql_type`。 * `QUANTILE`：百分位。直方图类型的监控数据会指定一个默认百分位。如果值为 `0`，表示该监控表对应的监控不是直方图。`tidb_query_duration` 默认查询 0.9 ，也就是 P90 的监控值。 * `COMMENT`：对这个监控表的解释。可以看出 `tidb_query_duration` 表是用来查询 TiDB query 执行的百分位时间，如 P999/P99/P90 的查询耗时，单位是秒。 @@ -110,7 +110,7 @@ desc select * from metrics_schema.tidb_query_duration where value is not null an 可以发现执行计划中有一个 `PromQL`, 以及查询监控的 `start_time` 和 `end_time`，还有 `step` 值，在实际执行时，TiDB 会调用 Prometheus 的 `query_range` HTTP API 接口来查询监控数据。 -从以上结果可知，在 [`2020-03-25 23:40:00`, `2020-03-25 23:42:00`] 时间范围内，每个 label 只有三个时间的值，执行计划中的 `step` 值为一分钟，这实际上是由下面两个 session 变量决定的： +从以上结果可知，在 [`2020-03-25 23:40:00`, `2020-03-25 23:42:00`] 时间范围内，每个 label 只有三个时间的值，间隔时间是 1 分钟，即执行计划中的 `step` 值。这个间隔时间实际上是由下面两个 session 变量决定的： * `tidb_metric_query_step`：查询的分辨率步长。从 Prometheus 的 `query_range` 接口查询数据时需要指定 `start_time`，`end_time` 和 `step`，其中 `step` 会使用该变量的值。 * `tidb_metric_query_range_duration`：查询监控时，会将 `PROMQL` 中的 `$RANGE_DURATION` 替换成该变量的值，默认值是 60 秒。 diff --git a/system-tables/system-table-metrics-tables.md b/system-tables/system-table-metrics-tables.md index 0a5703891fc0..ac310a9137da 100644 --- a/system-tables/system-table-metrics-tables.md +++ b/system-tables/system-table-metrics-tables.md @@ -7,7 +7,7 @@ aliases: ['/docs-cn/dev/reference/system-databases/metrics-tables/'] # METRICS_TABLES -`METRICS_TABLES` 表提供了 `metrics_schema` 中所有监控表的相关信息。 +`METRICS_TABLES` 表提供了 `metrics_schema` 数据库中所有监控表的相关信息。 {{< copyable "sql" >}} @@ -30,7 +30,7 @@ desc information_schema.metrics_tables; 表 `metrics_tables` 的字段解释： * `TABLE_NAME`：对应于 `metrics_schema` 中的表名。 -* `PROMQL`：监控表的主要原理是将 SQL 映射成 `PromQL`，并将 Prometheus 结果转换成 SQL 查询结果。这个字段是 `PromQL` 的表达式模板，获取监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 +* `PROMQL`：监控表的主要原理是将 SQL 映射成 `PromQL`，并将 Prometheus 结果转换成 SQL 查询结果。这个字段是 `PromQL` 的表达式模板，查询监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 * `LABELS`：监控定义的 label，每一个 label 对应监控表中的一列。SQL 中如果包含对应列的过滤，对应的 `PromQL` 也会改变。 * `QUANTILE`：百分位。对于直方图类型的监控数据，指定一个默认百分位。如果值为 `0`，表示该监控表对应的监控不是直方图。 * `COMMENT`：对这个监控表的解释。 diff --git a/system-tables/system-table-sql-diagnosis.md b/system-tables/system-table-sql-diagnosis.md index 8fb0dfc186d1..3735b63d014d 100644 --- a/system-tables/system-table-sql-diagnosis.md +++ b/system-tables/system-table-sql-diagnosis.md @@ -14,7 +14,7 @@ SQL 诊断共分三大块： * **集群信息表**：TiDB 4.0 诊断系统添加了集群信息表，为原先离散的各实例信息提供了统一的获取方式。它将整个集群的集群拓扑、硬件信息、软件信息、内核参数、监控、系统信息、慢查询、语句、日志完全整合在表中，让用户能够统一使用 SQL 进行查询。 * **集群监控表**：TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 语句来查询监控信息。比起原先的可视化监控，SQL 查询监控允许用户对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。由于 TiDB 集群的监控指标数量较大，SQL 诊断还提供了监控汇总表，让用户能够更便捷地从众多监控中找出异常的监控项。 -* **自动诊断**：尽管用户可以手动执行 SQL 来查询集群信息表、集群监控表与汇总表，但自动诊断更加方便。所以 SQL 诊断基于已有的集群信息表和监控表，提供了与之相关的诊断结果表与诊断汇总表来执行自动诊断。 +* **自动诊断**：尽管用户可以手动执行 SQL 来查询集群信息表、集群监控表与汇总表来定位问题，但自动诊断可以快速定位常见的异常项。SQL 诊断基于已有的集群信息表和监控表，提供了与之相关的诊断结果表与诊断汇总表来执行自动诊断。 ## 集群信息表 @@ -43,7 +43,7 @@ TiDB 4.0 之前的系统表，只能查看当前实例信息，TiDB 4.0 实现 ## 自动诊断 -以上集群信息表和集群监控表均需要用户手动执行固定模式的 SQL 语句来排查集群问题。为了进一步优化用户体验，TiDB 根据已有的基础信息表，提供诊断相关的系统表，使诊断自动执行。自动诊断相关的系统表如下： +以上集群信息表和集群监控表均需要用户手动执行 SQL 语句来排查集群问题。TiDB 4.0 中添加了自动诊断功能，根据已有的基础信息表，提供诊断相关的系统表，使诊断自动执行。自动诊断相关的系统表如下： * 诊断结果表 [`information_schema.inspection_result`](/system-tables/system-table-inspection-result.md) 用于展示对系统的诊断结果。诊断是惰性触发，使用 `select * from inspection_result` 会触发所有诊断规则对系统进行诊断，并在结果中展示系统中的故障或风险。 * 诊断汇总表 [`information_schema.inspection_summary`](/system-tables/system-table-inspection-summary.md) 用于对特定链路或模块的监控进行汇总，用户可以根据整个模块或链路的上下文来排查定位问题。 From b830a53dfe18bc1874283b8a52fa5e7512cf8ddb Mon Sep 17 00:00:00 2001 From: crazycs Date: Thu, 21 May 2020 22:13:00 +0800 Subject: [PATCH 02/13] Update system-tables/system-table-inspection-result.md Co-authored-by: Lilian Lee --- system-tables/system-table-inspection-result.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-tables/system-table-inspection-result.md b/system-tables/system-table-inspection-result.md index e0db8e2c5a49..ab92e5e7921f 100644 --- a/system-tables/system-table-inspection-result.md +++ b/system-tables/system-table-inspection-result.md @@ -41,7 +41,7 @@ desc information_schema.inspection_result; * `RULE`：诊断规则名称，目前实现了以下规则： * `config`：配置一致性以及合理性检测。如果同一个配置在不同实例不一致，会生成 `warning` 诊断结果。 * `version`：版本一致性检测。如果同一类型的实例版本不同，会生成 `critical` 诊断结果。 - * `node-load`：服务器负载检测，如果当前系统负载太高，会生成对应的 `warning` 诊断结果。 + * `node-load`：服务器负载检测。如果当前系统负载太高，会生成对应的 `warning` 诊断结果。 * `critical-error`：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 `warning` 诊断结果。 * `threshold-check`：诊断系统会对一些关键指标指标进行阈值判断，如果超过阈值会生成对应的诊断信息。 * `ITEM`：每一个规则会对不同的项进行诊断，该字段表示对应规则下面的具体诊断项。 From 1e6964572020fed03d91b9e50d80dd994e9318bd Mon Sep 17 00:00:00 2001 From: crazycs Date: Thu, 21 May 2020 22:13:11 +0800 Subject: [PATCH 03/13] Update system-tables/system-table-inspection-result.md Co-authored-by: Lilian Lee --- system-tables/system-table-inspection-result.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-tables/system-table-inspection-result.md b/system-tables/system-table-inspection-result.md index ab92e5e7921f..1dd8c14b6505 100644 --- a/system-tables/system-table-inspection-result.md +++ b/system-tables/system-table-inspection-result.md @@ -43,7 +43,7 @@ desc information_schema.inspection_result; * `version`：版本一致性检测。如果同一类型的实例版本不同，会生成 `critical` 诊断结果。 * `node-load`：服务器负载检测。如果当前系统负载太高，会生成对应的 `warning` 诊断结果。 * `critical-error`：系统各个模块定义了严重的错误，如果某一个严重错误在对应时间段内超过阈值，会生成 `warning` 诊断结果。 - * `threshold-check`：诊断系统会对一些关键指标指标进行阈值判断，如果超过阈值会生成对应的诊断信息。 + * `threshold-check`：诊断系统会对一些关键指标进行阈值判断，如果超过阈值会生成对应的诊断信息。 * `ITEM`：每一个规则会对不同的项进行诊断，该字段表示对应规则下面的具体诊断项。 * `TYPE`：诊断的实例类型，可取值为 `tidb`，`pd` 和 `tikv`。 * `INSTANCE`：诊断的具体实例地址。 From d62c97442d9480076dbfb37962fd3bd697b8771f Mon Sep 17 00:00:00 2001 From: crazycs Date: Thu, 21 May 2020 22:13:24 +0800 Subject: [PATCH 04/13] Update system-tables/system-table-metrics-schema.md Co-authored-by: Lilian Lee --- system-tables/system-table-metrics-schema.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-tables/system-table-metrics-schema.md b/system-tables/system-table-metrics-schema.md index 67723918136a..54d61614040e 100644 --- a/system-tables/system-table-metrics-schema.md +++ b/system-tables/system-table-metrics-schema.md @@ -11,7 +11,7 @@ aliases: ['/docs-cn/dev/reference/system-databases/metrics-schema/'] ## 概览 -下面以 `metrics_schema` 中的 `tidb_query_duration` 监控表来作为示例介绍监控表相关的使用和原理，其他的监控表原理都是类似的。 +下面以 `metrics_schema` 中的 `tidb_query_duration` 监控表为例，介绍监控表相关的使用和原理，其他的监控表原理均类似。 查询 `information_schema.metrics_tables` 中关于 `tidb_query_duration` 表相关的信息如下： From 6e46ead0dfa3b52a8120780b3d37bd707ce4c34e Mon Sep 17 00:00:00 2001 From: crazycs Date: Thu, 21 May 2020 22:13:32 +0800 Subject: [PATCH 05/13] Update system-tables/system-table-metrics-schema.md Co-authored-by: Lilian Lee --- system-tables/system-table-metrics-schema.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-tables/system-table-metrics-schema.md b/system-tables/system-table-metrics-schema.md index 54d61614040e..f7ee486392e4 100644 --- a/system-tables/system-table-metrics-schema.md +++ b/system-tables/system-table-metrics-schema.md @@ -110,7 +110,7 @@ desc select * from metrics_schema.tidb_query_duration where value is not null an 可以发现执行计划中有一个 `PromQL`, 以及查询监控的 `start_time` 和 `end_time`，还有 `step` 值，在实际执行时，TiDB 会调用 Prometheus 的 `query_range` HTTP API 接口来查询监控数据。 -从以上结果可知，在 [`2020-03-25 23:40:00`, `2020-03-25 23:42:00`] 时间范围内，每个 label 只有三个时间的值，间隔时间是 1 分钟，即执行计划中的 `step` 值。这个间隔时间实际上是由下面两个 session 变量决定的： +从以上结果可知，在 [`2020-03-25 23:40:00`, `2020-03-25 23:42:00`] 时间范围内，每个 label 只有三个时间的值，间隔时间是 1 分钟，即执行计划中的 `step` 值。该间隔时间由以下两个 session 变量决定： * `tidb_metric_query_step`：查询的分辨率步长。从 Prometheus 的 `query_range` 接口查询数据时需要指定 `start_time`，`end_time` 和 `step`，其中 `step` 会使用该变量的值。 * `tidb_metric_query_range_duration`：查询监控时，会将 `PROMQL` 中的 `$RANGE_DURATION` 替换成该变量的值，默认值是 60 秒。 From 6d1fcb33422880064cc35958df91048323814846 Mon Sep 17 00:00:00 2001 From: crazycs Date: Thu, 21 May 2020 22:15:20 +0800 Subject: [PATCH 06/13] Update system-tables/system-table-cluster-log.md Co-authored-by: kissmydb --- system-tables/system-table-cluster-log.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-tables/system-table-cluster-log.md b/system-tables/system-table-cluster-log.md index af64a46aa287..44d54ba38d32 100644 --- a/system-tables/system-table-cluster-log.md +++ b/system-tables/system-table-cluster-log.md @@ -65,7 +65,7 @@ select time,instance,left(message,150) from information_schema.cluster_log where +-------------------------+----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+ ``` -上面查询结果表示： +上面查询结果记录了一个 DDL 执行的过程： + 用户将 DDL JOB ID 为 `80` 的请求发给 `127.0.0.1:4002` TiDB 节点。 + `127.0.0.1:4000` TiDB 节点处理这个 DDL 请求，说明此时 `127.0.0.1:4000` 节点是 DDL owner。 From 9d4b267ed690714572d9496ee512e7917ed9856f Mon Sep 17 00:00:00 2001 From: crazycs Date: Thu, 21 May 2020 22:15:46 +0800 Subject: [PATCH 07/13] Update system-tables/system-table-inspection-summary.md Co-authored-by: kissmydb --- system-tables/system-table-inspection-summary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-tables/system-table-inspection-summary.md b/system-tables/system-table-inspection-summary.md index ff0fb9ce4996..78430aade78e 100644 --- a/system-tables/system-table-inspection-summary.md +++ b/system-tables/system-table-inspection-summary.md @@ -50,7 +50,7 @@ desc information_schema.inspection_summary; 诊断结果表和诊断监控汇总表都可以通过 `hint` 的方式指定诊断的时间范围，例如 `select /*+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` 是对 2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，`inspection_summary` 系统表也可以通过对比两个不同时间段的数据，快速发现差异较大的监控项。以下为一个例子： -对比以下两个时间段读系统链路的监控项: +以下为一个例子，对比以下两个时间段，读系统链路的监控项: * `(2020-01-16 16:00:54.933, 2020-01-16 16:10:54.933)` * `(2020-01-16 16:10:54.933, 2020-01-16 16:20:54.933)` From 45a0e015d1d8d326f9be7b93c2462ef48e3d4b48 Mon Sep 17 00:00:00 2001 From: crazycs Date: Thu, 21 May 2020 22:16:32 +0800 Subject: [PATCH 08/13] Update system-tables/system-table-inspection-summary.md Co-authored-by: kissmydb --- system-tables/system-table-inspection-summary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-tables/system-table-inspection-summary.md b/system-tables/system-table-inspection-summary.md index 78430aade78e..6fb441c03d06 100644 --- a/system-tables/system-table-inspection-summary.md +++ b/system-tables/system-table-inspection-summary.md @@ -48,7 +48,7 @@ desc information_schema.inspection_summary; 使用示例: -诊断结果表和诊断监控汇总表都可以通过 `hint` 的方式指定诊断的时间范围，例如 `select /*+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` 是对 2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，`inspection_summary` 系统表也可以通过对比两个不同时间段的数据，快速发现差异较大的监控项。以下为一个例子： +诊断结果表和诊断监控汇总表都可以通过 `hint` 的方式指定诊断的时间范围，例如 `select /*+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` 是对 2020-03-07 12:00:00 - 2020-03-07 13:00:00 时间段的监控汇总。和监控汇总表一样，`inspection_summary` 系统表也可以通过对比两个不同时间段的数据，快速发现差异较大的监控项。 以下为一个例子，对比以下两个时间段，读系统链路的监控项: From 33e93f34e9d2d81ede42f20bfd84b654e08d3547 Mon Sep 17 00:00:00 2001 From: crazycs Date: Thu, 21 May 2020 22:16:49 +0800 Subject: [PATCH 09/13] Update system-tables/system-table-metrics-tables.md Co-authored-by: kissmydb --- system-tables/system-table-metrics-tables.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-tables/system-table-metrics-tables.md b/system-tables/system-table-metrics-tables.md index ac310a9137da..f88bfccd4f22 100644 --- a/system-tables/system-table-metrics-tables.md +++ b/system-tables/system-table-metrics-tables.md @@ -7,7 +7,7 @@ aliases: ['/docs-cn/dev/reference/system-databases/metrics-tables/'] # METRICS_TABLES -`METRICS_TABLES` 表提供了 `metrics_schema` 数据库中所有监控表的相关信息。 +`INFORMATION_SCHEMA.METRICS_TABLES` 表提供了 `metrics_schema` 数据库中所有监控表的相关信息。 {{< copyable "sql" >}} From 8c3ee67599adfc4eef22c371696b5005dc72f249 Mon Sep 17 00:00:00 2001 From: crazycs520 Date: Thu, 21 May 2020 22:21:32 +0800 Subject: [PATCH 10/13] address comment Signed-off-by: crazycs520 --- system-tables/system-table-sql-diagnosis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-tables/system-table-sql-diagnosis.md b/system-tables/system-table-sql-diagnosis.md index 3735b63d014d..efd81e2c649c 100644 --- a/system-tables/system-table-sql-diagnosis.md +++ b/system-tables/system-table-sql-diagnosis.md @@ -39,7 +39,7 @@ TiDB 4.0 之前的系统表，只能查看当前实例信息，TiDB 4.0 实现 由于 TiDB 集群的监控指标数量较大，因此 TiDB 4.0 提供以下监控汇总表： * 监控汇总表 [`information_schema.metrics_summary`](/system-tables/system-table-metrics-summary.md) 用于汇总所有监控数据，以提升用户排查各监控指标的效率。 -* 监控汇总表 [`information_schema.metrics_summary_by_label`](/system-tables/system-table-metrics-summary.md) 同样用于汇总所有监控数据，不过该表会对不同的 label 进行区分统计。 +* 监控汇总并按 label 聚合表 [`information_schema.metrics_summary_by_label`](/system-tables/system-table-metrics-summary.md) 同样用于汇总所有监控数据，但该表会对各项监控的不同的 label 进行聚合统计。 ## 自动诊断 From 17310dbb173d200979a552a5e29741bbc2102cf4 Mon Sep 17 00:00:00 2001 From: crazycs Date: Thu, 21 May 2020 22:21:57 +0800 Subject: [PATCH 11/13] Update system-tables/system-table-metrics-schema.md Co-authored-by: Lilian Lee --- system-tables/system-table-metrics-schema.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-tables/system-table-metrics-schema.md b/system-tables/system-table-metrics-schema.md index f7ee486392e4..46646e5e393e 100644 --- a/system-tables/system-table-metrics-schema.md +++ b/system-tables/system-table-metrics-schema.md @@ -9,7 +9,7 @@ aliases: ['/docs-cn/dev/reference/system-databases/metrics-schema/'] 为了能够动态地观察并对比不同时间段的集群情况，TiDB 4.0 诊断系统添加了集群监控系统表。所有表都在 `metrics_schema` 数据库中，可以通过 SQL 的方式查询监控。实际上，SQL 诊断，以及 `metrics_summary`，`metrics_summary_by_label`，`inspection_result` 这三个监控相关的汇总表数据都是通过查询 metrics schema 库中的各种监控表来获取信息的。目前添加的系统表数量较多，用户可以通过 [`information_schema.metrics_tables`](/system-tables/system-table-metrics-tables.md) 查询这些表的相关信息。 -## 概览 +## 监控表的使用与原理 下面以 `metrics_schema` 中的 `tidb_query_duration` 监控表为例，介绍监控表相关的使用和原理，其他的监控表原理均类似。 From 582a519ed49b3e21d934bf31b097e70f6ea6d0c2 Mon Sep 17 00:00:00 2001 From: crazycs Date: Tue, 26 May 2020 17:44:19 +0800 Subject: [PATCH 12/13] Update system-tables/system-table-metrics-schema.md Co-authored-by: Lilian Lee --- system-tables/system-table-metrics-schema.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-tables/system-table-metrics-schema.md b/system-tables/system-table-metrics-schema.md index 46646e5e393e..1a641722f98d 100644 --- a/system-tables/system-table-metrics-schema.md +++ b/system-tables/system-table-metrics-schema.md @@ -30,7 +30,7 @@ select * from information_schema.metrics_tables where table_name='tidb_query_dur ``` * `TABLE_NAME`：对应于 `metrics_schema` 中的表名，这里表名是 `tidb_query_duration`。 -* `PROMQL`：因为监控表的原理是将 SQL 映射成 `PromQL` 后向 Prometheus 请求数据，并将 Prometheus 返回的结果转换成 SQL 查询结果。这个字段是 `PromQL` 的表达式模板，查询监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 +* `PROMQL`：因为监控表的原理是将 SQL 映射成 `PromQL` 后向 Prometheus 请求数据，并将 Prometheus 返回的结果转换成 SQL 查询结果。该字段是 `PromQL` 的表达式模板，查询监控表数据时使用查询条件改写模板中的变量，生成最终的查询表达式。 * `LABELS`：监控项定义的 label，`tidb_query_duration` 有两个 label，分别是 `instance` 和 `sql_type`。 * `QUANTILE`：百分位。直方图类型的监控数据会指定一个默认百分位。如果值为 `0`，表示该监控表对应的监控不是直方图。`tidb_query_duration` 默认查询 0.9 ，也就是 P90 的监控值。 * `COMMENT`：对这个监控表的解释。可以看出 `tidb_query_duration` 表是用来查询 TiDB query 执行的百分位时间，如 P999/P99/P90 的查询耗时，单位是秒。 From 5fe2d3309e347c9bb0500958e7c66dacf9cf3fde Mon Sep 17 00:00:00 2001 From: crazycs Date: Tue, 26 May 2020 18:51:57 +0800 Subject: [PATCH 13/13] Update system-tables/system-table-sql-diagnosis.md Co-authored-by: Lonng --- system-tables/system-table-sql-diagnosis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system-tables/system-table-sql-diagnosis.md b/system-tables/system-table-sql-diagnosis.md index efd81e2c649c..d45ba1a6b25c 100644 --- a/system-tables/system-table-sql-diagnosis.md +++ b/system-tables/system-table-sql-diagnosis.md @@ -14,7 +14,7 @@ SQL 诊断共分三大块： * **集群信息表**：TiDB 4.0 诊断系统添加了集群信息表，为原先离散的各实例信息提供了统一的获取方式。它将整个集群的集群拓扑、硬件信息、软件信息、内核参数、监控、系统信息、慢查询、语句、日志完全整合在表中，让用户能够统一使用 SQL 进行查询。 * **集群监控表**：TiDB 4.0 诊断系统添加了集群监控系统表，所有表都在 `metrics_schema` 中，可以通过 SQL 语句来查询监控信息。比起原先的可视化监控，SQL 查询监控允许用户对整个集群的所有监控进行关联查询，并对比不同时间段的结果，迅速找出性能瓶颈。由于 TiDB 集群的监控指标数量较大，SQL 诊断还提供了监控汇总表，让用户能够更便捷地从众多监控中找出异常的监控项。 -* **自动诊断**：尽管用户可以手动执行 SQL 来查询集群信息表、集群监控表与汇总表来定位问题，但自动诊断可以快速定位常见的异常项。SQL 诊断基于已有的集群信息表和监控表，提供了与之相关的诊断结果表与诊断汇总表来执行自动诊断。 +* **自动诊断**：尽管用户可以手动执行 SQL 来查询集群信息表、集群监控表与汇总表来定位问题，但自动诊断可以快速对常见异常进行定位。SQL 诊断基于已有的集群信息表和监控表，提供了与之相关的诊断结果表与诊断汇总表来执行自动诊断。 ## 集群信息表