From 11675d6d608054461bbf9f9e644e8dd6744a95a6 Mon Sep 17 00:00:00 2001 From: TomShawn <1135243111@qq.com> Date: Wed, 29 Apr 2020 20:51:22 +0800 Subject: [PATCH] reference: refine sql diagnosis --- reference/system-databases/cluster-config.md | 4 +- .../system-databases/cluster-hardware.md | 8 ++-- reference/system-databases/cluster-info.md | 18 +++---- reference/system-databases/cluster-load.md | 30 ++++++------ reference/system-databases/cluster-log.md | 22 ++++----- .../system-databases/cluster-systeminfo.md | 6 +-- .../system-databases/inspection-result.md | 48 ++++++++++--------- .../system-databases/inspection-summary.md | 35 +++++++------- reference/system-databases/metrics-summary.md | 28 +++++------ reference/system-databases/metrics-tables.md | 20 ++++---- reference/system-databases/sql-diagnosis.md | 16 +++---- 11 files changed, 121 insertions(+), 114 deletions(-) diff --git a/reference/system-databases/cluster-config.md b/reference/system-databases/cluster-config.md index e029923ef6fc3..d8a13a25413e9 100644 --- a/reference/system-databases/cluster-config.md +++ b/reference/system-databases/cluster-config.md @@ -11,7 +11,7 @@ You can use the `CLUSTER_CONFIG` cluster configuration table to get the current {{< copyable "sql" >}} ```sql -desc cluster_config; +desc information_schema.cluster_config; ``` ```sql @@ -37,7 +37,7 @@ The following example shows how to query the `coprocessor` configuration on the {{< copyable "sql" >}} ```sql -select * from cluster_config where type='tikv' and `key` like 'coprocessor%'; +select * from information_schema.cluster_config where type='tikv' and `key` like 'coprocessor%'; ``` ```sql diff --git a/reference/system-databases/cluster-hardware.md b/reference/system-databases/cluster-hardware.md index a5542498a849f..5e1800421d2dc 100644 --- a/reference/system-databases/cluster-hardware.md +++ b/reference/system-databases/cluster-hardware.md @@ -11,7 +11,7 @@ The `CLUSTER_HARDWARE` hardware system table provides the hardware information o {{< copyable "sql" >}} ```sql -desc cluster_hardware; +desc information_schema.cluster_hardware; ``` ```sql @@ -45,15 +45,15 @@ The following example shows how to query the CPU information using the `CLUSTER_ {{< copyable "sql" >}} ```sql -select * from cluster_hardware where device_type='cpu' and device_name='cpu' and name like '%cores'; +select * from information_schema.cluster_hardware where device_type='cpu' and device_name='cpu' and name like '%cores'; ``` ```sql +------+-----------------+-------------+-------------+--------------------+-------+ | TYPE | INSTANCE | DEVICE_TYPE | DEVICE_NAME | NAME | VALUE | +------+-----------------+-------------+-------------+--------------------+-------+ -| tidb | 127.0.0.1:10080 | cpu | cpu | cpu-logical-cores | 8 | -| tidb | 127.0.0.1:10080 | cpu | cpu | cpu-physical-cores | 4 | +| tidb | 0.0.0.0:4000 | cpu | cpu | cpu-logical-cores | 8 | +| tidb | 0.0.0.0:4000 | cpu | cpu | cpu-physical-cores | 4 | | pd | 127.0.0.1:2379 | cpu | cpu | cpu-logical-cores | 8 | | pd | 127.0.0.1:2379 | cpu | cpu | cpu-physical-cores | 4 | | tikv | 127.0.0.1:20160 | cpu | cpu | cpu-logical-cores | 8 | diff --git a/reference/system-databases/cluster-info.md b/reference/system-databases/cluster-info.md index 7565ba7491762..cc96939ceda16 100644 --- a/reference/system-databases/cluster-info.md +++ b/reference/system-databases/cluster-info.md @@ -11,7 +11,7 @@ The `CLUSTER_INFO` cluster topology table provides the current topology informat {{< copyable "sql" >}} ```sql -desc cluster_info; +desc information_schema.cluster_info; ``` ```sql @@ -42,15 +42,15 @@ Field description: {{< copyable "sql" >}} ```sql -select * from cluster_info; +select * from information_schema.cluster_info; ``` ```sql -+------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+ -| TYPE | INSTANCE | STATUS_ADDRESS | VERSION | GIT_HASH | START_TIME | UPTIME | -+------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+ -| tidb | 127.0.0.1:4000 | 127.0.0.1:10080 | 5.7.25-TiDB-v4.0.0-beta-195-gb5ea3232a | b5ea3232afa970f00db7a0fb13ed10857db1912e | 2020-03-02T16:27:28+08:00 | 4m18.845924s | -| pd | 127.0.0.1:2379 | 127.0.0.1:2379 | 4.1.0-alpha | 4b9bcbc1425c96848042b6d700eb63f84e72b338 | 2020-03-02T16:27:17+08:00 | 4m29.845928s | -| tikv | 127.0.0.1:20160 | 127.0.0.1:20180 | 4.1.0-alpha | 7c4202a1c8faf60eda659dfe0e64e31972488e78 | 2020-03-02T16:27:28+08:00 | 4m18.845929s | -+------+-----------------+-----------------+----------------------------------------+------------------------------------------+---------------------------+--------------+ ++------+-----------------+-----------------+-------------+------------------------------------------+---------------------------+--------------+ +| TYPE | INSTANCE | STATUS_ADDRESS | VERSION | GIT_HASH | START_TIME | UPTIME | ++------+-----------------+-----------------+-------------+------------------------------------------+---------------------------+--------------+ +| tidb | 0.0.0.0:4000 | 0.0.0.0:10080 | 4.0.0-beta | b5ea3232afa970f00db7a0fb13ed10857db1912e | 2020-03-02T16:27:28+08:00 | 4m18.845924s | +| pd | 127.0.0.1:2379 | 127.0.0.1:2379 | 4.1.0-alpha | 4b9bcbc1425c96848042b6d700eb63f84e72b338 | 2020-03-02T16:27:17+08:00 | 4m29.845928s | +| tikv | 127.0.0.1:20160 | 127.0.0.1:20180 | 4.1.0-alpha | 7c4202a1c8faf60eda659dfe0e64e31972488e78 | 2020-03-02T16:27:28+08:00 | 4m18.845929s | ++------+-----------------+-----------------+-------------+------------------------------------------+---------------------------+--------------+ ``` diff --git a/reference/system-databases/cluster-load.md b/reference/system-databases/cluster-load.md index fd3bdb308ce01..c9bc4a379e6b2 100644 --- a/reference/system-databases/cluster-load.md +++ b/reference/system-databases/cluster-load.md @@ -11,7 +11,7 @@ The `CLUSTER_LOAD` cluster load table provides the current load information of t {{< copyable "sql" >}} ```sql -desc cluster_load; +desc information_schema.cluster_load; ``` ```sql @@ -45,21 +45,21 @@ The following example shows how to query the current load information of cpu usi {{< copyable "sql" >}} ```sql -select * from cluster_load where device_type='cpu' and device_name='cpu'; +select * from information_schema.cluster_load where device_type='cpu' and device_name='cpu'; ``` ```sql -+------+-----------------+-------------+-------------+--------+---------------+ -| TYPE | INSTANCE | DEVICE_TYPE | DEVICE_NAME | NAME | VALUE | -+------+-----------------+-------------+-------------+--------+---------------+ -| tidb | 127.0.0.1:10080 | cpu | cpu | load1 | 1.94 | -| tidb | 127.0.0.1:10080 | cpu | cpu | load5 | 2.16 | -| tidb | 127.0.0.1:10080 | cpu | cpu | load15 | 2.24 | -| pd | 127.0.0.1:2379 | cpu | cpu | load1 | 1.94 | -| pd | 127.0.0.1:2379 | cpu | cpu | load5 | 2.16 | -| pd | 127.0.0.1:2379 | cpu | cpu | load15 | 2.24 | -| tikv | 127.0.0.1:20160 | cpu | cpu | load1 | 1.94287109375 | -| tikv | 127.0.0.1:20160 | cpu | cpu | load5 | 2.15576171875 | -| tikv | 127.0.0.1:20160 | cpu | cpu | load15 | 2.2421875 | -+------+-----------------+-------------+-------------+--------+---------------+ ++------+-----------------+-------------+-------------+--------+-------+ +| TYPE | INSTANCE | DEVICE_TYPE | DEVICE_NAME | NAME | VALUE | ++------+-----------------+-------------+-------------+--------+-------+ +| tidb | 0.0.0.0:4000 | cpu | cpu | load1 | 0.39 | +| tidb | 0.0.0.0:4000 | cpu | cpu | load5 | 0.36 | +| tidb | 0.0.0.0:4000 | cpu | cpu | load15 | 0.66 | +| pd | 127.0.0.1:2379 | cpu | cpu | load1 | 0.39 | +| pd | 127.0.0.1:2379 | cpu | cpu | load5 | 0.36 | +| pd | 127.0.0.1:2379 | cpu | cpu | load15 | 0.66 | +| tikv | 127.0.0.1:20160 | cpu | cpu | load1 | 0.39 | +| tikv | 127.0.0.1:20160 | cpu | cpu | load5 | 0.36 | +| tikv | 127.0.0.1:20160 | cpu | cpu | load15 | 0.66 | ++------+-----------------+-------------+-------------+--------+-------+ ``` diff --git a/reference/system-databases/cluster-log.md b/reference/system-databases/cluster-log.md index 1ce32bafeb5c7..649c99e5726e5 100644 --- a/reference/system-databases/cluster-log.md +++ b/reference/system-databases/cluster-log.md @@ -13,19 +13,19 @@ To get the logs of the TiDB cluster before v4.0, you need to log in to each inst {{< copyable "sql" >}} ```sql -desc cluster_log; +desc information_schema.cluster_log; ``` ```sql -+----------+---------------------------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+----------+---------------------------+------+------+---------+-------+ -| TIME | varchar(32) | YES | | NULL | | -| TYPE | varchar(64) | YES | | NULL | | -| INSTANCE | varchar(64) | YES | | NULL | | -| LEVEL | varchar(8) | YES | | NULL | | -| MESSAGE | var_string(1024) unsigned | YES | | NULL | | -+----------+---------------------------+------+------+---------+-------+ ++----------+------------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++----------+------------------+------+------+---------+-------+ +| TIME | varchar(32) | YES | | NULL | | +| TYPE | varchar(64) | YES | | NULL | | +| INSTANCE | varchar(64) | YES | | NULL | | +| LEVEL | varchar(8) | YES | | NULL | | +| MESSAGE | var_string(1024) | YES | | NULL | | ++----------+------------------+------+------+---------+-------+ 5 rows in set (0.00 sec) ``` @@ -48,7 +48,7 @@ The following example shows how to query the execution process of a DDL statemen {{< copyable "sql" >}} ```sql -select * from `CLUSTER_LOG` where message like '%ddl%' and message like '%job%58%' and type='tidb' and time > '2020-03-27 15:39:00'; +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'; ``` ```sql diff --git a/reference/system-databases/cluster-systeminfo.md b/reference/system-databases/cluster-systeminfo.md index d44dcdc540eb5..e51f7c94e5efb 100644 --- a/reference/system-databases/cluster-systeminfo.md +++ b/reference/system-databases/cluster-systeminfo.md @@ -6,12 +6,12 @@ category: reference # CLUSTER_SYSTEMINFO -You can use the `CLUSTER_SYSTEMINFO` kernel parameter table to query the kernel configuration information of the server where all nodes of the cluster are located. Currently, you can query the information of the `sysctl` system. +You can use the `CLUSTER_SYSTEMINFO` kernel parameter table to query the kernel configuration information of the server where all instances of the cluster are located. Currently, you can query the information of the `sysctl` system. {{< copyable "sql" >}} ```sql -desc cluster_systeminfo; +desc information_schema.cluster_systeminfo; ``` ```sql @@ -40,7 +40,7 @@ Field description: The following example shows how to query the kernel version of all servers in the cluster using the `CLUSTER_SYSTEMINFO` system information table. ```sql -select * from CLUSTER_SYSTEMINFO where name like '%kernel.osrelease%' +select * from information_schema.cluster_systeminfo where name like '%kernel.osrelease%' ``` ```sql diff --git a/reference/system-databases/inspection-result.md b/reference/system-databases/inspection-result.md index b8db51bbecdcc..9ae16944a9696 100644 --- a/reference/system-databases/inspection-result.md +++ b/reference/system-databases/inspection-result.md @@ -15,23 +15,24 @@ The structure of the `information_schema.inspection_result` diagnosis result tab {{< copyable "sql" >}} ```sql -desc inspection_result; +desc information_schema.inspection_result; ``` ```sql -+-----------+--------------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+-----------+--------------+------+------+---------+-------+ -| RULE | varchar(64) | YES | | NULL | | -| ITEM | varchar(64) | YES | | NULL | | -| TYPE | varchar(64) | YES | | NULL | | -| INSTANCE | varchar(64) | YES | | NULL | | -| VALUE | varchar(64) | YES | | NULL | | -| REFERENCE | varchar(64) | YES | | NULL | | -| SEVERITY | varchar(64) | YES | | NULL | | -| DETAILS | varchar(256) | YES | | NULL | | -+-----------+--------------+------+------+---------+-------+ -8 rows in set (0.00 sec) ++----------------+--------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++----------------+--------------+------+------+---------+-------+ +| RULE | varchar(64) | YES | | NULL | | +| ITEM | varchar(64) | YES | | NULL | | +| TYPE | varchar(64) | YES | | NULL | | +| INSTANCE | varchar(64) | YES | | NULL | | +| STATUS_ADDRESS | varchar(64) | YES | | NULL | | +| VALUE | varchar(64) | YES | | NULL | | +| REFERENCE | varchar(64) | YES | | NULL | | +| SEVERITY | varchar(64) | YES | | NULL | | +| DETAILS | varchar(256) | YES | | NULL | | ++----------------+--------------+------+------+---------+-------+ +9 rows in set (0.00 sec) ``` Field description: @@ -39,12 +40,13 @@ Field description: * `RULE`: The name of the diagnosis rule. Currently, the following rules are available: * `config`: The consistency check of configuration. If the same configuration is inconsistent on different instances, a `warning` diagnosis result is generated. * `version`: The consistency check of version. If the same version is inconsistent on different instances, a `warning` diagnosis result is generated. - * `current-load`: If the current system load is too high, the corresponding `warning` diagnosis result is generated. + * `node-load`: If the current system load is too high, the corresponding `warning` diagnosis result is generated. * `critical-error`: Each module of the system defines critical errors. If a critical error exceeds the threshold within the corresponding time period, a warning diagnosis result is generated. * `threshold-check`: The diagnosis system checks the thresholds of a large number of metrics. If a threshold is exceeded, the corresponding diagnosis information is generated. * `ITEM`: Each rule diagnoses different items. This field indicates the specific diagnosis items corresponding to each rule. * `TYPE`: The instance type of the diagnosis. The optional values are `tidb`, `pd`, and `tikv`. * `INSTANCE`: The specific address of the diagnosed instance. +* `STATUS_ADDRESS`: The HTTP API service address of the instance. * `VALUE`: The value of a specific diagnosis item. * `REFERENCE`: The reference value (threshold value) for this diagnosis item. If the difference between `VALUE` and the threshold is very large, the corresponding diagnosis information is generated. * `SEVERITY`: The severity level. The optional values are `warning` and `critical`. @@ -57,7 +59,7 @@ Diagnose issues currently existing in the cluster. {{< copyable "sql" >}} ```sql -select * from inspection_result\G +select * from information_schema.inspection_result\G ``` ```sql @@ -110,7 +112,7 @@ You can also diagnose issues existing within a specified range, such as from "20 {{< copyable "sql" >}} ```sql -select /*+ time_range("2020-03-26 00:03:00", "2020-03-26 00:08:00") */ * from inspection_result\G +select /*+ time_range("2020-03-26 00:03:00", "2020-03-26 00:08:00") */ * from information_schema.inspection_result\G ``` ```sql @@ -144,7 +146,7 @@ You can also specify conditions, for example, to query the `critical` level diag {{< copyable "sql" >}} ```sql -select * from inspection_result where severity='critical'; +select * from information_schema.inspection_result where severity='critical'; ``` Query only the diagnosis result of the `critical-error` rule: @@ -152,7 +154,7 @@ Query only the diagnosis result of the `critical-error` rule: {{< copyable "sql" >}} ```sql -select * from inspection_result where rule='critical-error'; +select * from information_schema.inspection_result where rule='critical-error'; ``` ## Diagnosis rules @@ -164,7 +166,7 @@ You can query the existing diagnosis rules by querying the `inspection_rules` sy {{< copyable "sql" >}} ```sql -select * from inspection_rules where type='inspection'; +select * from information_schema.inspection_rules where type='inspection'; ``` ```sql @@ -173,7 +175,7 @@ select * from inspection_rules where type='inspection'; +-----------------+------------+---------+ | config | inspection | | | version | inspection | | -| current-load | inspection | | +| node-load | inspection | | | critical-error | inspection | | | threshold-check | inspection | | +-----------------+------------+---------+ @@ -195,6 +197,7 @@ In the `config` diagnosis rule, the following two diagnosis rules are executed b status.status-port log.file.filename log.slow-query-file + tmp-storage-path // The whitelist of the PD configuration consistency check advertise-client-urls @@ -214,6 +217,7 @@ In the `config` diagnosis rule, the following two diagnosis rules are executed b log-file raftstore.raftdb-path storage.data-dir + storage.block-cache.capacity ``` * Check whether the values of the following configuration items are as expected. @@ -230,7 +234,7 @@ The `version` diagnosis rule checks whether the version hash of the same compone {{< copyable "sql" >}} ```sql -select * from inspection_result where rule='version'\G +select * from information_schema.inspection_result where rule='version'\G ``` ```sql diff --git a/reference/system-databases/inspection-summary.md b/reference/system-databases/inspection-summary.md index 833feb551d95b..865be6bcd5afc 100644 --- a/reference/system-databases/inspection-summary.md +++ b/reference/system-databases/inspection-summary.md @@ -13,22 +13,24 @@ The structure of the `information_schema.inspection_summary` inspection summary {{< copyable "sql" >}} ```sql -desc inspection_summary; +desc information_schema.inspection_summary; ``` ```sql -+--------------+-----------------------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+--------------+-----------------------+------+------+---------+-------+ -| RULE | varchar(64) | YES | | NULL | | -| INSTANCE | varchar(64) | YES | | NULL | | -| METRICS_NAME | varchar(64) | YES | | NULL | | -| LABEL | varchar(64) | YES | | NULL | | -| QUANTILE | double unsigned | YES | | NULL | | -| AVG_VALUE | double(22,6) unsigned | YES | | NULL | | -| MIN_VALUE | double(22,6) unsigned | YES | | NULL | | -| MAX_VALUE | double(22,6) unsigned | YES | | NULL | | -+--------------+-----------------------+------+------+---------+-------+ ++--------------+--------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++--------------+--------------+------+------+---------+-------+ +| RULE | varchar(64) | YES | | NULL | | +| INSTANCE | varchar(64) | YES | | NULL | | +| METRICS_NAME | varchar(64) | YES | | NULL | | +| LABEL | varchar(64) | YES | | NULL | | +| QUANTILE | double | YES | | NULL | | +| AVG_VALUE | double(22,6) | YES | | NULL | | +| MIN_VALUE | double(22,6) | YES | | NULL | | +| MAX_VALUE | double(22,6) | YES | | NULL | | +| COMMENT | varchar(256) | YES | | NULL | | ++--------------+--------------+------+------+---------+-------+ +9 rows in set ``` Field description: @@ -37,10 +39,11 @@ Field description: * `INSTANCE`: The monitored instance. * `METRICS_NAME`: The monitoring metrics name. * `QUANTILE`: Takes effect on monitoring tables that contain `QUANTILE`. You can specify multiple percentiles by pushing down predicates. For example, you can execute `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)` to summarize the DDL-related monitoring metrics and query the P80/P90/P99/P999 results. `AVG_VALUE`, `MIN_VALUE`, and `MAX_VALUE` respectively indicate the average value, minimum value, and maximum value of the aggregation. +* `COMMENT`: The comment about the corresponding monitoring metric. > **Note:** > -> Because summarizing all results causes overhead, the rules in `information_summary` are triggered passively. That is, the specified `rule` runs only when it displays in the SQL predicate. For example, executing the `select * from inspection_summary` statement returns an empty result set. Executing `select * from inspection_summary where rule in ('read-link', 'ddl')` summarizes the read link and DDL-related monitoring metrics. +> Because summarizing all results causes overhead, it is recommended to display the specific `rule` in the SQL predicate to reduce overhead. For example, executing `select * from inspection_summary where rule in ('read-link', 'ddl')` summarizes the read link and DDL-related monitoring metrics. Usage example: @@ -59,13 +62,13 @@ FROM ( SELECT /*+ time_range("2020-01-16 16:00:54.933", "2020-01-16 16:10:54.933")*/ * - FROM inspection_summary WHERE rule='read-link' + FROM information_schema.inspection_summary WHERE rule='read-link' ) t1 JOIN ( SELECT /*+ time_range("2020-01-16 16:10:54.933","2020-01-16 16:20:54.933")*/ * - FROM inspection_summary WHERE rule='read-link' + FROM information_schema.inspection_summary WHERE rule='read-link' ) t2 ON t1.metrics_name = t2.metrics_name and t1.instance = t2.instance diff --git a/reference/system-databases/metrics-summary.md b/reference/system-databases/metrics-summary.md index c18362e063fee..2e940ede6e87a 100644 --- a/reference/system-databases/metrics-summary.md +++ b/reference/system-databases/metrics-summary.md @@ -16,21 +16,21 @@ The two tables summarize all monitoring data for you to check each monitoring me {{< copyable "sql" >}} ```sql -desc metrics_summary; +desc information_schema.metrics_summary; ``` ```sql -+--------------+-----------------------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+--------------+-----------------------+------+------+---------+-------+ -| METRICS_NAME | varchar(64) | YES | | NULL | | -| QUANTILE | double unsigned | YES | | NULL | | -| SUM_VALUE | double(22,6) unsigned | YES | | NULL | | -| AVG_VALUE | double(22,6) unsigned | YES | | NULL | | -| MIN_VALUE | double(22,6) unsigned | YES | | NULL | | -| MAX_VALUE | double(22,6) unsigned | YES | | NULL | | -| COMMENT | varchar(256) | YES | | NULL | | -+--------------+-----------------------+------+------+---------+-------+ ++--------------+--------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++--------------+--------------+------+------+---------+-------+ +| METRICS_NAME | varchar(64) | YES | | NULL | | +| QUANTILE | double | YES | | NULL | | +| SUM_VALUE | double(22,6) | YES | | NULL | | +| AVG_VALUE | double(22,6) | YES | | NULL | | +| MIN_VALUE | double(22,6) | YES | | NULL | | +| MAX_VALUE | double(22,6) | YES | | NULL | | +| COMMENT | varchar(256) | YES | | NULL | | ++--------------+--------------+------+------+---------+-------+ ``` Field description: @@ -50,7 +50,7 @@ To query the three groups of monitoring items with the highest average time cons ```sql select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * -from information_schema.`METRICS_SUMMARY` +from information_schema.metrics_summary where metrics_name like 'tidb%duration' and avg_value > 0 and quantile = 0.99 @@ -91,7 +91,7 @@ Similarly, the following example queries the `metrics_summary_by_label` monitori ```sql select /*+ time_range('2020-03-08 13:23:00','2020-03-08 13:33:00') */ * -from information_schema.`METRICS_SUMMARY_BY_LABEL` +from information_schema.metrics_summary_by_label where metrics_name like 'tidb%duration' and avg_value > 0 and quantile = 0.99 diff --git a/reference/system-databases/metrics-tables.md b/reference/system-databases/metrics-tables.md index 622039ac4e068..fdd17d43e0880 100644 --- a/reference/system-databases/metrics-tables.md +++ b/reference/system-databases/metrics-tables.md @@ -11,19 +11,19 @@ The `METRICS_TABLES` table provides information of all monitoring tables in the {{< copyable "sql" >}} ```sql -desc metrics_tables; +desc information_schema.metrics_tables; ``` ```sql -+------------+-----------------+------+------+---------+-------+ -| Field | Type | Null | Key | Default | Extra | -+------------+-----------------+------+------+---------+-------+ -| TABLE_NAME | varchar(64) | YES | | NULL | | -| PROMQL | varchar(64) | YES | | NULL | | -| LABELS | varchar(64) | YES | | NULL | | -| QUANTILE | double unsigned | YES | | NULL | | -| COMMENT | varchar(256) | YES | | NULL | | -+------------+-----------------+------+------+---------+-------+ ++------------+--------------+------+------+---------+-------+ +| Field | Type | Null | Key | Default | Extra | ++------------+--------------+------+------+---------+-------+ +| TABLE_NAME | varchar(64) | YES | | NULL | | +| PROMQL | varchar(64) | YES | | NULL | | +| LABELS | varchar(64) | YES | | NULL | | +| QUANTILE | double | YES | | NULL | | +| COMMENT | varchar(256) | YES | | NULL | | ++------------+--------------+------+------+---------+-------+ ``` Field description: diff --git a/reference/system-databases/sql-diagnosis.md b/reference/system-databases/sql-diagnosis.md index 683a60c4a5d53..2500a2cc66e93 100644 --- a/reference/system-databases/sql-diagnosis.md +++ b/reference/system-databases/sql-diagnosis.md @@ -19,7 +19,7 @@ The SQL diagnosis system has the following advantages: The SQL diagnosis system consists of three major parts: -+ **Cluster information table**: The SQL diagnosis system introduces cluster information tables that provide a unified way to get the discrete information of each instance and node. This system fully integrates the cluster topology, hardware information, software information, kernel parameters, monitoring, system information, slow queries, statements, and logs of the entire cluster into the table. So you can query these information using SQL statements. ++ **Cluster information table**: The SQL diagnosis system introduces cluster information tables that provide a unified way to get the discrete information of each instance. This system fully integrates the cluster topology, hardware information, software information, kernel parameters, monitoring, system information, slow queries, statements, and logs of the entire cluster into the table. So you can query these information using SQL statements. + **Cluster monitoring table**: The SQL diagnosis system introduces cluster monitoring tables. All of these tables are in `metrics_schema`, and you can query monitoring information using SQL statements. Compared to the visualized monitoring before v4.0, you can use this SQL-based method to perform correlated queries on all the monitoring information of the entire cluster, and compare the results of different time periods to quickly identify performance bottlenecks. Because the TiDB cluster has many monitoring metrics, the SQL diagnosis system also provides monitoring summary tables, so you can find abnormal monitoring items more easily. @@ -27,16 +27,16 @@ The SQL diagnosis system consists of three major parts: ## Cluster information tables -The cluster information tables bring together the information of all nodes and instances in a cluster. With these tables, you can query all cluster information using only one SQL statement. The following is a list of cluster information tables: +The cluster information tables bring together the information of all instances and instances in a cluster. With these tables, you can query all cluster information using only one SQL statement. The following is a list of cluster information tables: -+ From the cluster topology table [`information_schema.cluster_info`](/reference/system-databases/cluster-info.md), you can get the current topology information of the cluster, the version of each node, the Git Hash corresponding to the version, the starting time of each node, and the running time of each node. -+ From the cluster configuration table [`information_schema.cluster_config`](/reference/system-databases/cluster-config.md), you can get the configuration of all nodes in the cluster. For versions earlier than 4.0, you need to access the HTTP API of each node one by one to get these configuration information. ++ From the cluster topology table [`information_schema.cluster_info`](/reference/system-databases/cluster-info.md), you can get the current topology information of the cluster, the version of each instance, the Git Hash corresponding to the version, the starting time of each instance, and the running time of each instance. ++ From the cluster configuration table [`information_schema.cluster_config`](/reference/system-databases/cluster-config.md), you can get the configuration of all instances in the cluster. For versions earlier than 4.0, you need to access the HTTP API of each instance one by one to get these configuration information. + On the cluster hardware table [`information_schema.cluster_hardware`](/reference/system-databases/cluster-hardware.md), you can quickly query the cluster hardware information. -+ On the cluster load table [`information_schema.cluster_load`](/reference/system-databases/cluster-load.md), you can query the load information of different nodes and hardware types of the cluster. -+ On the kernel parameter table [`information_schema.cluster_systeminfo`](/reference/system-databases/cluster-systeminfo.md), you can query the kernel configuration information of different nodes in the cluster. Currently, TiDB supports querying the sysctl information. -+ On the cluster log table [`information_schema.cluster_log`](/reference/system-databases/cluster-log.md), you can query cluster logs. By pushing down query conditions to each node, the impact of the query on cluster performance is less than that of the `grep` command. ++ On the cluster load table [`information_schema.cluster_load`](/reference/system-databases/cluster-load.md), you can query the load information of different instances and hardware types of the cluster. ++ On the kernel parameter table [`information_schema.cluster_systeminfo`](/reference/system-databases/cluster-systeminfo.md), you can query the kernel configuration information of different instances in the cluster. Currently, TiDB supports querying the sysctl information. ++ On the cluster log table [`information_schema.cluster_log`](/reference/system-databases/cluster-log.md), you can query cluster logs. By pushing down query conditions to each instance, the impact of the query on cluster performance is less than that of the `grep` command. -On the system tables earlier than TiDB v4.0, you can only view the current node. TiDB v4.0 introduces the corresponding cluster tables and you can have a global view of the entire cluster on a single TiDB node. These tables are currently in `information_schema`, and the query method is the same as other `information_schema` system tables. +On the system tables earlier than TiDB v4.0, you can only view the current instance. TiDB v4.0 introduces the corresponding cluster tables and you can have a global view of the entire cluster on a single TiDB instance. These tables are currently in `information_schema`, and the query method is the same as other `information_schema` system tables. ## Cluster monitoring tables