reference: add 2 inspection tables #2261

TomShawn · 2020-04-13T12:03:25Z

What is changed, added or deleted? (Required)

Add inspection_result and inspection_summary tables.

Which TiDB version(s) do your changes apply to? (Required)

If you select two or more versions from above, to trigger the bot to cherry-pick this PR to your desired release version branch(es), you must add corresponding labels such as needs-cherry-pick-4.0, needs-cherry-pick-3.1, needs-cherry-pick-3.0, and needs-cherry-pick-2.1.

What is the related PR or file link(s)?

This PR is translated from: reference/system-databases: add 12 new documents for sql diagnosis docs-cn#2522 reference: fix typos and refine sql diagnosis related documents docs-cn#2737
Other reference link(s):

lilin90

I only finished reviewing part of this PR (till the ## Diagnosis rules line in inspection-result.md). Many understanding or technical writing issues exist. Please resolve my comments and check all changes in PR again. Thanks!

lilin90 · 2020-04-15T12:04:43Z

reference/system-databases/inspection-result.md

+
+# INSPECTION_RESULT
+
+TiDB has some built-in diagnosis rules for detecting faults and hidden dangers in the system.


danger might be a little bit too strong.

Suggested change

TiDB has some built-in diagnosis rules for detecting faults and hidden dangers in the system.

TiDB has some built-in diagnosis rules for detecting faults and hidden issues in the system.

lilin90 · 2020-04-15T12:06:37Z

reference/system-databases/inspection-result.md

+
+TiDB has some built-in diagnosis rules for detecting faults and hidden dangers in the system.
+
+This diagnosis feature can help you quickly find problems and reduce your repetitive manual work. You can use the `select * from information_schema.inspection_result` statement to trigger the internal diagnosis.


Suggested change

This diagnosis feature can help you quickly find problems and reduce your repetitive manual work. You can use the `select * from information_schema.inspection_result` statement to trigger the internal diagnosis.

The `INSPECTION_RESULT` diagnosis feature can help you quickly find problems and reduce your repetitive manual work. You can use the `select * from information_schema.inspection_result` statement to trigger the internal diagnosis.

lilin90 · 2020-04-15T12:10:23Z

reference/system-databases/inspection-result.md

+
+Field description:
+
+* `RULE`: The name of the diagnosis rules. Below are the currently available rules:


Suggested change

* `RULE`: The name of the diagnosis rules. Below are the currently available rules:

* `RULE`: The name of the diagnosis rule. Currently, the following rules are available:

lilin90 · 2020-04-15T12:14:31Z

reference/system-databases/inspection-result.md

+    * `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.
+    * `critical-error`: Each module of the system defines a serious error. If a certain serious error exceeds the threshold within the corresponding time period, a warning diagnosis result is generated.


@reafans Please help confirm whether it's "a error" or "errors".
@TomShawn Please keep words consistent with that in the rule name.

Suggested change

* `critical-error`: Each module of the system defines a serious error. If a certain serious error exceeds the threshold within the corresponding time period, a 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.

lilin90 · 2020-04-15T12:18:00Z

reference/system-databases/inspection-result.md

+    * `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.
+    * `critical-error`: Each module of the system defines a serious error. If a certain serious error exceeds the threshold within the corresponding time period, a warning diagnosis result is generated.
+    * `threshold-check`: The diagnosis system determines thresholds of many metrics. If a threshold is exceeded, the corresponding diagnosis information is generated.


Please try to understand it based on the context. It does not mean determine here.

Suggested change

* `threshold-check`: The diagnosis system determines thresholds of many metrics. If a threshold is exceeded, the corresponding diagnosis information 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.

lilin90 · 2020-04-15T12:56:21Z

reference/system-databases/inspection-result.md

+
+You can have the following findings from the above diagnosis result:
+
+* The first line indicates that TiDB's `log.slow-threshold` configuration value is `0`, which might affect performance.


Check the code block, please. It's row, not line.

Suggested change

* The first line indicates that TiDB's `log.slow-threshold` configuration value is `0`, which might affect performance.

* The first row indicates that TiDB's `log.slow-threshold` value is configured to `0`, which might affect performance.

lilin90 · 2020-04-15T13:00:22Z

reference/system-databases/inspection-result.md

+You can have the following findings from the above diagnosis result:
+
+* The first line indicates that TiDB's `log.slow-threshold` configuration value is `0`, which might affect performance.
+* The second line indicates that two different TiDB versions exist in the cluster.


Suggested change

* The second line indicates that two different TiDB versions exist in the cluster.

* The second row indicates that two different TiDB versions exist in the cluster.

lilin90 · 2020-04-15T13:07:31Z

reference/system-databases/inspection-result.md

+
+* The first line indicates that TiDB's `log.slow-threshold` configuration value is `0`, which might affect performance.
+* The second line indicates that two different TiDB versions exist in the cluster.
+* The third and fourth lines indicate that the TiKV write delay is too long, and the expected delay is no more than 0.1s. The actual delay is far beyond the expectation.


beyond the expectation is inappropriate and confusing here.

Suggested change

* The third and fourth lines indicate that the TiKV write delay is too long, and the expected delay is no more than 0.1s. The actual delay is far beyond the expectation.

* The third and fourth rows indicate that the TiKV write delay is too long. The expected delay is no more than 0.1 second, while the actual delay is far longer than expected.

lilin90 · 2020-04-15T13:22:13Z

reference/system-databases/inspection-result.md

+* The second line indicates that two different TiDB versions exist in the cluster.
+* The third and fourth lines indicate that the TiKV write delay is too long, and the expected delay is no more than 0.1s. The actual delay is far beyond the expectation.
+
+Diagnose the cluster problem from "2020-03-26 00:03:00" to "2020-03-26 00:08:00". To specify the time range, you need to use the SQL Hint of `/*+ time_range() */`. See the following query example:


Please pay attentiont to the connection between paragraphs.

Suggested change

Diagnose the cluster problem from "2020-03-26 00:03:00" to "2020-03-26 00:08:00". To specify the time range, you need to use the SQL Hint of `/*+ time_range() */`. See the following query example:

You can also diagnose issues existing within a specified range, such as from "2020-03-26 00:03:00" to "2020-03-26 00:08:00". To specify the time range, use the SQL Hint of `/*+ time_range() */`. See the following query example:

lilin90 · 2020-04-15T13:23:50Z

reference/system-databases/inspection-result.md

+You can have the following findings from the above result:
+
+* The first line indicates that the `172.16.5.40:4009` TiDB instance is restarted at `2020/03/26 00:05:45.670`.
+* The second line indicates that the maximum `get-token-duration` time of the `172.16.5.40:10089` TiDB instance is 0.234s, but the expected time is less than 0.001s.
+
+You can also specify conditions, for example, to query the `critical` level diagnosis results:
+
+{{< copyable "sql" >}}
+
+```sql
+select * from inspection_result where severity='critical';
+```
+
+Query only the diagnosis result of the `critical-error` rule:
+
+{{< copyable "sql" >}}
+
+```sql
+select * from inspection_result where rule='critical-error';
+```


Please refer to suggestion for the previous similar section and update accordingly.

TomShawn · 2020-04-16T08:35:29Z

@lilin90 All comments are addressed and applied to similar sections in this PR, PTAL again, thanks!

sre-bot · 2020-04-17T13:29:54Z

@lilin90, @reafans, PTAL.

sre-bot · 2020-04-19T13:29:55Z

@lilin90, @reafans, PTAL.

reafans

LGTM

…-tables

lilin90 · 2020-04-22T11:33:16Z

reference/system-databases/inspection-result.md

+
+### `config` diagnosis rule
+
+The following two diagnosis rules are executed as the `config` diagnosis by querying the `CLUSTER_CONFIG` system table:


Suggested change

The following two diagnosis rules are executed as the `config` diagnosis by querying the `CLUSTER_CONFIG` system table:

In the `config` diagnosis rule, the following two diagnosis rules are executed by querying the `CLUSTER_CONFIG` system table:

lilin90 · 2020-04-22T11:35:25Z

reference/system-databases/inspection-result.md

+
+The following two diagnosis rules are executed as the `config` diagnosis by querying the `CLUSTER_CONFIG` system table:
+
+* Check whether the configuration values of the same component are consistent. Not all configuration items has this consistency check. The white list of consistency check is shown below:


Suggested change

* Check whether the configuration values of the same component are consistent. Not all configuration items has this consistency check. The white list of consistency check is shown below:

* Check whether the configuration values of the same component are consistent. Not all configuration items has this consistency check. The white list of the consistency check is as follows:

lilin90 · 2020-04-22T11:38:05Z

reference/system-databases/inspection-result.md

+
+### `critical-error` diagnosis rule
+
+The following two diagnosis rules are executed as the the `critical-error` diagnosis:


Suggested change

The following two diagnosis rules are executed as the the `critical-error` diagnosis:

In `config` diagnosis rule, the following two diagnosis rules are executed:

lilin90 · 2020-04-22T11:39:13Z

reference/system-databases/inspection-result.md

+    |  Component  | Error name | Monitoring table | Error description |
+    |  ----  | ----  |  ----  |  ----  |
+    | TiDB | panic-count | tidb_panic_count_total_count | Panic occurs in TiDB. |
+    | TiDB | binlog-error | tidb_binlog_error_total_count | An error occurs when TiDB writes binlog files. |


lilin90 · 2020-04-22T11:40:56Z

reference/system-databases/inspection-result.md

+    | TiKV | channel-is-full | tikv_channel_full_total_count | The "channel full" error occurs in TiKV. |
+    | TiKV | tikv_engine_write_stall | tikv_engine_write_stall | The "stall" error occurs in TiKV. |
+
+* Check if any component is restarted by querying the `metrics_schema.up` monitoring table and the `CLUSTER_LOG` system table.


if has multiple meanings.

Suggested change

* Check if any component is restarted by querying the `metrics_schema.up` monitoring table and the `CLUSTER_LOG` system table.

* Check whether any component is restarted by querying the `metrics_schema.up` monitoring table and the `CLUSTER_LOG` system table.

lilin90 · 2020-04-22T11:57:34Z

reference/system-databases/inspection-summary.md

+
+Field description:
+
+* `RULE`: Summary rules. New rules are being added, and you can execute the `select * from inspection_rules where type='summary'` statement to check the latest rule list.


Suggested change

* `RULE`: Summary rules. New rules are being added, and you can execute the `select * from inspection_rules where type='summary'` statement to check the latest rule list.

* `RULE`: Summary rules. Because new rules are being added continuously, you can execute the `select * from inspection_rules where type='summary'` statement to query the latest rule list.

lilin90 · 2020-04-22T12:10:26Z

reference/system-databases/inspection-summary.md

+
+* `RULE`: Summary rules. New rules are being added, and you can execute the `select * from inspection_rules where type='summary'` statement to check the latest rule list.
+* `INSTANCE`: The monitored instance.
+* `METRIC_NAME`: The monitoring metrics name.


Please keep the field name consistent with that in the code block.

Please check the meaning of the this field because it seems inconsistent with the Chinese version 监控表.

Suggested change

* `METRIC_NAME`: The monitoring metrics name.

* `METRICS_NAME`: The monitoring metrics name.

As confirmed with @reafans, The monitoring metrics name is OK.

lilin90 · 2020-04-22T12:21:39Z

reference/system-databases/inspection-summary.md

+
+> **Note:**
+>
+> Because summarizing all results causes overhead, the rules in `information_summary` are triggered passively, which means that the specified `rule` is displayed in the SQL predicate before the rule runs. 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.


Suggested change

> Because summarizing all results causes overhead, the rules in `information_summary` are triggered passively, which means that the specified `rule` is displayed in the SQL predicate before the rule runs. 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, 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.

lilin90 · 2020-04-22T12:24:29Z

reference/system-databases/inspection-summary.md

+
+Usage example:
+
+Both the diagnosis result table and the diagnosis monitoring summary table can specify the diagnosis time range using `hint`. `select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` is the monitoring summary for the `2020-03-07 12:00:00` to `2020-03-07 13:00:00` period. Like the monitoring summary table, you can use the diagnosis result table to quickly find the monitoring items with large differences by comparing the data of two different periods. The following is an example:


Suggested change

Both the diagnosis result table and the diagnosis monitoring summary table can specify the diagnosis time range using `hint`. `select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` is the monitoring summary for the `2020-03-07 12:00:00` to `2020-03-07 13:00:00` period. Like the monitoring summary table, you can use the diagnosis result table to quickly find the monitoring items with large differences by comparing the data of two different periods. The following is an example:

Both the diagnosis result table and the diagnosis monitoring summary table can specify the diagnosis time range using `hint`. `select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` is the monitoring summary for the `2020-03-07 12:00:00` to `2020-03-07 13:00:00` period. Like the monitoring summary table, you can use the diagnosis result table to quickly find the monitoring items with large differences by comparing the data of two different periods.

lilin90 · 2020-04-22T12:27:01Z

reference/system-databases/inspection-summary.md

+
+Both the diagnosis result table and the diagnosis monitoring summary table can specify the diagnosis time range using `hint`. `select **+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') */* from inspection_summary` is the monitoring summary for the `2020-03-07 12:00:00` to `2020-03-07 13:00:00` period. Like the monitoring summary table, you can use the diagnosis result table to quickly find the monitoring items with large differences by comparing the data of two different periods. The following is an example:
+
+You can also diagnose issues existing within a specified range, such as from "2020-01-16 16:00:54.933" to "2020-01-16 16:10:54.933":


Suggested change

You can also diagnose issues existing within a specified range, such as from "2020-01-16 16:00:54.933" to "2020-01-16 16:10:54.933":

See the following example that diagnoses issues within a specified range, from "2020-01-16 16:00:54.933" to "2020-01-16 16:10:54.933":

TomShawn · 2020-04-23T08:21:56Z

@lilin90 All comments are addressed. PTAL again, thanks!

lilin90

LGTM

sre-bot · 2020-04-24T08:04:24Z

Your auto merge job has been accepted, waiting for:

2251

…-tables

Signed-off-by: sre-bot <sre-bot@pingcap.com>

sre-bot · 2020-04-24T08:13:06Z

cherry pick to release-4.0 in PR #2395

* cherry pick #2261 to release-4.0 Signed-off-by: sre-bot <sre-bot@pingcap.com> * resolve conflict Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com> Co-authored-by: TomShawn <1135243111@qq.com>

reference: add 2 inspection tables

45e0a37

TomShawn added translation/from-docs-cn This PR is translated from a PR in pingcap/docs-cn. v4.0 This PR/issue applies to TiDB v4.0. size/large Changes of a large size. needs-cherry-pick-4.0 labels Apr 13, 2020

TomShawn requested a review from reafans April 13, 2020 12:03

remove mysql in commands

14219cc

TomShawn requested a review from lilin90 April 14, 2020 06:43

TomShawn added the status/PTAL This PR is ready for reviewing. label Apr 14, 2020

Merge branch 'master' into inspection-system-tables

605eedf

lilin90 reviewed Apr 15, 2020

View reviewed changes

address comments

ef5863d

Merge branch 'master' into inspection-system-tables

4e6c529

reafans approved these changes Apr 21, 2020

View reviewed changes

TomShawn added 2 commits April 21, 2020 16:32

Merge remote-tracking branch 'upstream/master' into inspection-system…

ec719e6

…-tables

add sql in results

b3227ab

lilin90 reviewed Apr 22, 2020

View reviewed changes

address comments

4830062

lilin90 approved these changes Apr 24, 2020

View reviewed changes

Merge branch 'master' into inspection-system-tables

2939ec9

lilin90 added the status/can-merge Indicates a PR has been approved by a committer. label Apr 24, 2020

Merge remote-tracking branch 'upstream/master' into inspection-system…

ae9af4d

…-tables

TomShawn merged commit b948a68 into pingcap:master Apr 24, 2020

sre-bot pushed a commit to sre-bot/docs that referenced this pull request Apr 24, 2020

cherry pick pingcap#2261 to release-4.0

41b05de

Signed-off-by: sre-bot <sre-bot@pingcap.com>

sre-bot mentioned this pull request Apr 24, 2020

reference: add 2 inspection tables (#2261) #2395

Merged

5 tasks

TomShawn deleted the inspection-system-tables branch April 24, 2020 08:14


		# INSPECTION_RESULT

		TiDB has some built-in diagnosis rules for detecting faults and hidden dangers in the system.


		TiDB has some built-in diagnosis rules for detecting faults and hidden dangers in the system.

		This diagnosis feature can help you quickly find problems and reduce your repetitive manual work. You can use the `select * from information_schema.inspection_result` statement to trigger the internal diagnosis.

	This diagnosis feature can help you quickly find problems and reduce your repetitive manual work. You can use the `select * from information_schema.inspection_result` statement to trigger the internal diagnosis.
	The `INSPECTION_RESULT` diagnosis feature can help you quickly find problems and reduce your repetitive manual work. You can use the `select * from information_schema.inspection_result` statement to trigger the internal diagnosis.


		Field description:

		* `RULE`: The name of the diagnosis rules. Below are the currently available rules:

	* `critical-error`: Each module of the system defines a serious error. If a certain serious error exceeds the threshold within the corresponding time period, a 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 determines thresholds of many metrics. If a threshold is exceeded, the corresponding diagnosis information 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.


		You can have the following findings from the above diagnosis result:

		* The first line indicates that TiDB's `log.slow-threshold` configuration value is `0`, which might affect performance.

	* The first line indicates that TiDB's `log.slow-threshold` configuration value is `0`, which might affect performance.
	* The first row indicates that TiDB's `log.slow-threshold` value is configured to `0`, which might affect performance.

	* The second line indicates that two different TiDB versions exist in the cluster.
	* The second row indicates that two different TiDB versions exist in the cluster.

	* The third and fourth lines indicate that the TiKV write delay is too long, and the expected delay is no more than 0.1s. The actual delay is far beyond the expectation.
	* The third and fourth rows indicate that the TiKV write delay is too long. The expected delay is no more than 0.1 second, while the actual delay is far longer than expected.

	Diagnose the cluster problem from "2020-03-26 00:03:00" to "2020-03-26 00:08:00". To specify the time range, you need to use the SQL Hint of `/+ time_range() /`. See the following query example:
	You can also diagnose issues existing within a specified range, such as from "2020-03-26 00:03:00" to "2020-03-26 00:08:00". To specify the time range, use the SQL Hint of `/+ time_range() /`. See the following query example:


		### `config` diagnosis rule

		The following two diagnosis rules are executed as the `config` diagnosis by querying the `CLUSTER_CONFIG` system table:

	The following two diagnosis rules are executed as the `config` diagnosis by querying the `CLUSTER_CONFIG` system table:
	In the `config` diagnosis rule, the following two diagnosis rules are executed by querying the `CLUSTER_CONFIG` system table:


		The following two diagnosis rules are executed as the `config` diagnosis by querying the `CLUSTER_CONFIG` system table:

		* Check whether the configuration values of the same component are consistent. Not all configuration items has this consistency check. The white list of consistency check is shown below:


		### `critical-error` diagnosis rule

		The following two diagnosis rules are executed as the the `critical-error` diagnosis:

	The following two diagnosis rules are executed as the the `critical-error` diagnosis:
	In `config` diagnosis rule, the following two diagnosis rules are executed:

	\| TiDB \| binlog-error \| tidb_binlog_error_total_count \| An error occurs when TiDB writes binlog files. \|
	\| TiDB \| binlog-error \| tidb_binlog_error_total_count \| An error occurs when TiDB writes binlog. \|

	* Check if any component is restarted by querying the `metrics_schema.up` monitoring table and the `CLUSTER_LOG` system table.
	* Check whether any component is restarted by querying the `metrics_schema.up` monitoring table and the `CLUSTER_LOG` system table.


		Field description:

		* `RULE`: Summary rules. New rules are being added, and you can execute the `select * from inspection_rules where type='summary'` statement to check the latest rule list.

	* `RULE`: Summary rules. New rules are being added, and you can execute the `select * from inspection_rules where type='summary'` statement to check the latest rule list.
	* `RULE`: Summary rules. Because new rules are being added continuously, you can execute the `select * from inspection_rules where type='summary'` statement to query the latest rule list.

reference: add 2 inspection tables #2261

reference: add 2 inspection tables #2261

Uh oh!

Conversation

TomShawn commented Apr 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is changed, added or deleted? (Required)

Which TiDB version(s) do your changes apply to? (Required)

What is the related PR or file link(s)?

Uh oh!

lilin90 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TomShawn commented Apr 16, 2020

Uh oh!

sre-bot commented Apr 17, 2020

Uh oh!

sre-bot commented Apr 19, 2020

Uh oh!

reafans left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TomShawn commented Apr 23, 2020

Uh oh!

lilin90 left a comment

Choose a reason for hiding this comment

Uh oh!

sre-bot commented Apr 24, 2020

Uh oh!

sre-bot commented Apr 24, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

TomShawn commented Apr 13, 2020 •

edited

Loading

	* `METRIC_NAME`: The monitoring metrics name.
	* `METRICS_NAME`: The monitoring metrics name.


		Usage example:

		Both the diagnosis result table and the diagnosis monitoring summary table can specify the diagnosis time range using `hint`. `select *+ time_range('2020-03-07 12:00:00','2020-03-07 13:00:00') /* from inspection_summary` is the monitoring summary for the `2020-03-07 12:00:00` to `2020-03-07 13:00:00` period. Like the monitoring summary table, you can use the diagnosis result table to quickly find the monitoring items with large differences by comparing the data of two different periods. The following is an example:

	You can also diagnose issues existing within a specified range, such as from "2020-01-16 16:00:54.933" to "2020-01-16 16:10:54.933":
	See the following example that diagnoses issues within a specified range, from "2020-01-16 16:00:54.933" to "2020-01-16 16:10:54.933":