diff --git a/TOC.md b/TOC.md
index 62a625124ff9..2d9836e2ea0a 100644
--- a/TOC.md
+++ b/TOC.md
@@ -428,6 +428,7 @@
       + 集群诊断页面
         + [访问](/dashboard/dashboard-diagnostics-access.md)
         + [查看报告](/dashboard/dashboard-diagnostics-report.md)
+        + [使用示例](/dashboard/dashboard-diagnostics-usage.md)
       + [日志搜索页面](/dashboard/dashboard-log-search.md)
       + [实例性能分析页面](/dashboard/dashboard-profiling.md)
   + CLI
diff --git a/dashboard/dashboard-diagnostics-access.md b/dashboard/dashboard-diagnostics-access.md
index e69de29bb2d1..8dec5802186f 100644
--- a/dashboard/dashboard-diagnostics-access.md
+++ b/dashboard/dashboard-diagnostics-access.md
@@ -0,0 +1,61 @@
+---
+title: 集群诊断页面
+category: how-to
+---
+
+# 集群诊断页面
+
+集群诊断是在指定的时间范围内，对集群可能存在的问题进行诊断，并将诊断结果和一些集群相关的负载监控信息汇总成一个诊断报告。诊断报告是网页形式，通过浏览器保存后可离线浏览和传阅。
+
+> **注意：**
+>
+> 集群诊断功能依赖于集群中部署有 Prometheus 监控组件，参见 [TiUP](/tiup/tiup-overview.md) 或 [TiDB Ansible](/online-deployment-using-ansible.md) 部署文档了解如何部署监控组件。若集群中没有部署监控组件，生成的诊断报告中将提示生成失败。
+
+## 访问
+
+可以通过以下两种方法访问集群诊断页面：
+
+* 登录后，左侧导航条点击**集群诊断**（Cluster Diagnose）：
+
+![访问](/media/dashboard/diagnostics-access.png)
+
+* 在浏览器中访问 [http://127.0.0.1:2379/dashboard/#/diagnose](http://127.0.0.1:2379/dashboard/#/diagnose)（将 127.0.0.1:2379 替换为任意实际 PD 地址和端口）。
+
+## 生成诊断报告
+
+如果想对一个时间范围内的集群进行诊断，查看集群的负载等情况，可以使用以下步骤来生成一段时间范围的诊断报告：
+
+1. 设置区间的开始时间，例如 2020-05-21 14:40:00。
+2. 设置区间长度。例如 10 min 。
+3. 点击开始。
+
+![生成单个时间段的诊断报告](/media/dashboard/diagnostics-gen-report.png)
+
+> **建议：**
+>
+> 建议生成报告的时间范围在 1 min ~ 60 min 内，目前不建议生成超过 1 小时范围的报告。
+
+以上操作会生成 2020-05-21 14:40:00 至 2020-05-21 14:50:00 时间范围的诊断报告。点击**开始**后，会看到以下界面，**生成进度**是生成报告的进度条，生成报告完成后，点击**查看报告**即可。
+
+![生成报告的进度](/media/dashboard/diagnostics-gen-process.png)
+
+## 生成对比诊断报告
+
+如果系统在某个时间点发生异常，如 QPS 抖动或者延迟变高，可以生成一份异常时间范围和正常时间范围的对比报告，例如：
+
+* 系统异常时间段：2020-05-21 14:40:00 ~ 2020-05-21 14:45:00，系统异常时间
+* 系统正常时间段：2020-05-21 14:30:00 ~ 2020-05-21 14:35:00，系统正常时间
+
+生成以上两个时间范围的对比报告的步骤如下：
+
+1. 设置区间的开始时间，即异常时间段的开始时间，如 2020-05-21 14:40:00
+2. 设置区间长度。一般只系统异常的持续时间，例如 5 min 
+3. 开启与基线区间对比开关
+4. 设置基线开始时间，即想要对比的系统正常时段的开始时间，如 2020-05-21 14:30:00
+5. 点击开始
+
+![生成对比报告](/media/dashboard/diagnostics-gen-compare-report.png)
+
+然后同样等报告生成完成后点击**查看报告**即可。
+
+另外，已生成的诊断报告会显式在诊断报告主页的列表里面，可以点击查看之前生成的报告，不用重复生成。
diff --git a/dashboard/dashboard-diagnostics-report.md b/dashboard/dashboard-diagnostics-report.md
index e69de29bb2d1..74038f113b67 100644
--- a/dashboard/dashboard-diagnostics-report.md
+++ b/dashboard/dashboard-diagnostics-report.md
@@ -0,0 +1,362 @@
+---
+title: 集群诊断页面
+category: how-to
+---
+
+# 集群诊断页面
+
+本文档主要介绍诊断报告的内容以及查看技巧，访问集群诊断和生成报告请参考 [诊断报告访问文档](/dashboard/dashboard-diagnostics-access.md)
+
+## 查看报告
+
+诊断报告由以下几部分组成：
+
+* 基本信息：包括生成报告的时间范围，集群的硬件信息，集群的拓扑版本信息。
+* 诊断信息：显示自动诊断的结果。
+* 负载信息：包括服务器，TIDB/PD/TiKV 相关的 CPU, 内存等负载信息
+* 概览信息：包括 TiDB/PD/TiKV 的各个模块的耗时信息和错误信息。
+* TiDB/PD/TiKV 监控信息：包括各个组件的监控信息。
+* 配置信息：包括各个组件的配置信息。
+
+报告中报表示例如下：
+
+![示例报表](/media/dashboard/diagnostics-example-table.png)
+
+上图中，最上面蓝框内的 **Total Time Consume** 是报表名字。下面红框内的内容是对这个报表意义的解释，以及报表中各个字段的含义。
+
+报表内容中，有几个小按钮的作用如下：
+
+* i 图标：鼠标移动到 i 图标会显示该行的说明注释。
+* expand：点击 `expand` 会看到这项监控更加详细的信息，如是上图中 `tidb_get_token` 的详细信息包括各个 TiDB 实例的延迟监控信息。
+* fold：和 expland 相反，用于把监控的详细信息折叠起来。
+
+所有监控基本上和 `TiDB Grafna` 监控面板上的监控内容相对应，发现某个模块异常后，可以在 `TiDB Grafna` 监控面板上查看更多详细的监控信息。
+
+另外，报表中统计的 TOTAL_TIME 和 TOTAL_COUNT 由于是从 Prometheus 读取的监控数据，其统计会有一些计算上的精度误差。
+
+下面逐个介绍报告各个部分的报告内容。
+
+### 基本信息
+
+#### Report Time Range
+
+生成报告的时间范围，包括开始时间和结束时间。
+
+![report time range 报表](/media/dashboard/diagnostics-report-time-range.png)
+
+#### Cluster Hardware
+
+集群中各服务器的硬件信息，包括 CPU,Memory,磁盘等信息。
+
+![Cluster Hardware 报表](/media/dashboard/diagnostics-cluster-hardware.png)
+
+上表中各个字段含义如下：
+
+* HOST: 服务器的 IP 地址。
+* INSTANCE: 该服务器部署的实例数量，如 `pd * 1` 代表这台服务器部署了 1 个 PD; 如 `tidb * 2 pd * 1` 表示这台服务器部署了 2 个 TiDB 和 1 个 PD 。
+* CPU_CORES：表示服务器 CPU 的核心数，物理核心/逻辑核心。
+* MEMORY: 表示服务器的内存大小，单位是 GB。
+* DISK: 表示服务器磁盘大小，单位是 GB。
+* UPTIME: 服务器的启动时间，单位是 DAY。
+
+#### cluster info
+
+集群拓扑信息。表中信息来自 TiDB 的 [information_schema.cluster_info](/system-tables/system-table-cluster-info.md) 系统表。
+
+![Cluster Hardware 报表](/media/dashboard/diagnostics-cluster-info.png)
+
+上表中各个字段含义如下：
+
+* TYPE：节点类型。
+* INSTANCE：实例地址，为 IP:PORT 格式的字符串。
+* STATUS_ADDRESS：HTTP API 的服务地址。
+* VERSION：对应节点的语义版本号。
+* GIT_HASH：编译节点版本时的 Git Commit Hash，用于识别两个节点是否是绝对一致的版本。
+* START_TIME：对应节点的启动时间。
+* UPTIME：对应节点已经运行的时间。
+
+### 诊断信息
+
+TiDB 内置自动诊断的结果，具体各字段含义以及介绍可以参考 [information_schema.inspection-result](/system-tables/system-table-inspection-result.md) 系统表的内容。
+
+### 负载信息
+
+#### Node Load Info
+
+服务器节点的负载信息，包括时间范围内，服务器以下指标的平均值(AVG)，最大值(MAX)，最小值(MIN)：
+
+* cpu 使用率，最大值是 100%
+* memory 使用率
+* 磁盘 io 使用率
+* 磁盘写延迟
+* 磁盘读延迟
+* 磁盘每秒的读取字节数
+* 磁盘每秒的写入字节数
+* 节点网络每分钟收到的字节数
+* 节点网络每分钟发送的字节数
+* 节点正在使用的 TCP 连接数
+* 节点所有的 TCP 连接数
+
+![Server Load Info 报表](/media/dashboard/diagnostics-node-load-info.png)
+
+#### Instance cpu usage
+
+各个 TiDB/PD/TiKV 进程的 CPU 使用率的平均值(AVG)，最大值(MAX)，最小值(MIN)，这里进程 CPU 使用率最大值是 100% * CPU 逻辑核心数。
+
+![Instance CPU Usage 报表](/media/dashboard/diagnostics-process-cpu-usage.png)
+
+#### Instance Memory Usage
+
+各个 TiDB/PD/TiKV 进程的占用内存字节数的平均值(AVG)，最大值(MAX)，最小值(MIN)。
+
+![Instance memory usage 报表](/media/dashboard/diagnostics-process-memory-usage.png)
+
+#### TiKV Thread CPU Usage
+
+TiKV 内部各个模块线程的 CPU 使用率的平均值(AVG)，最大值(MAX)，最小值(MIN)。这里进程 CPU 使用率最大值为 100% * 对应配置的线程数量。
+
+![TiKV Thread CPU Usage 报表](/media/dashboard/diagnostics-thread-cpu-usage.png)
+
+上表中，
+
+* `CONFIG_KEY`：表示对应模块的相关线程数配置，``
+* `CURRENT_CONFIG_VALUE`：表示配置在生成报表时刻的当前值。
+
+> 注意：`CURRENT_CONFIG_VALUE` 是生成报告时的值，并不是报告时间范围内的值，目前不能获取历史时间某些配置的值。
+
+#### TiDB/PD goroutines count
+
+TiDB/PD 的 goroutines 数量的平均值(AVG)，最大值(MAX)，最小值(MIN)。如果 goroutines 数量超过 2000， 说明该进程并发太高，会对整体请求的延迟有影响。
+
+![TiDB/PD goroutines count 报表](/media/dashboard/diagnostics-goroutines-count.png)
+
+### 概览信息
+
+#### Time Consumed by Each Component
+
+包括集群中 TiDB, PD, TiKV 的各个模块的监控控耗时以及各项耗时的占比。默认时间单位是秒。可以用该表快速定位哪些模块的耗时较多。
+
+![Total Time Consume 报表](/media/dashboard/diagnostics-total-time-consume.png)
+
+上表各列的字段含义如下：
+
+* METRIC_NAME：监控项的名称
+* Label: 监控的 label 信息，点击 expand 后可以查看该项监控更加详细的各项 label 的监控信息。
+* TIME_RATIO：该项监控消耗的总时间和 TIME_RATIO 为 1 的监控行总时间比例。如 kv_request 的总耗时占 tidb_query 总耗时的 1.65 = 38325.58/23223.86。因为 KV 请求会并行执行，所以所有 KV 请求的总时间是有可能超过总查询（tidb_query）的执行时间。
+* TOTAL_TIME: 该项监控的总耗时。
+* TOTAL_COUNT: 该项监控执行的总次数。
+* P999: 该项监控的 P999 最大时间。
+* P99: 该项监控的 P99 最大时间。
+* P90: 该项监控的 P90 最大时间。
+* P80: 该项监控的 P80 最大时间。
+
+以上监控中相关模块的耗时关系如下所示：
+
+![各个模块耗时关系图](/media/dashboard/diagnostics-time-relation.png)
+
+上图中，黄色部分是 TiDB 相关的监控，蓝色部分是 TiKV 相关的监控，灰色部分暂时没有具体对应的监控项。
+
+上图中，tidb_query 的耗时包括 4 部分的耗时
+
+* get_token
+* parse
+* compile
+* execute
+
+其中 execute 的耗时包括以下部分：
+
+* wait_start_tso
+* TiDB 层的执行时间，目前暂无监控
+* KV 请求的时间
+* KV_backoff 的时间，这是 KV 请求失败后进行 backoff 的时间
+
+其中，KV 请求时间包含以下部分：
+
+* 请求的网络发送以及接收耗时，目前该项暂无监控，可以大致用 KV 请求时间 减去 tikv_grpc_messge 的时间
+* tikv_grpc_messge 耗时
+
+其中，tikv_grpc_messge 耗时包含以下部分：
+
+* Coprocessor reques 耗时，指用于处理 COP 类型的请求，该耗时包括以下部分：
+    * tikv_cop_wait，请求排队等待的耗时
+    * Coprocessor handle，处理 Cop 请求的耗时
+* tikv_scheduler_command 耗时，该耗时包含以下部分：
+    * tikv_scheduler_processing_read，处理读请求的耗时
+    * tikv_storage_async_request 中获取 snapshot 的耗时 ( snapshot 是该项监控的 label ）
+    * 处理写请求的耗时，该耗时包括以下部分：
+        * tikv_scheduler_latch_wait，等待 latch 的耗时
+        * tikv_storage_async_request 中 write 的耗时（write 是改监控的 labe）
+
+其中，tikv_storage_async_request 中的 write 耗时是指 raft kv 写入的耗时，包括以下部分：
+
+* tikv_raft_propose_wait
+* tikv_raft_process，该耗时主要时间包括：
+    * tikv_raft_append_log
+* tikv_raft_commit_log
+* tikv_raft_apply_wait
+* tikv_raft_apply_log
+
+用户可以根据上述耗时之间的关系，利用 TOTAL_TIME 以及 P999，P99 的时间大致定位哪些模块耗时比较久，然后再看相关的监控。
+
+> 注意：由于 raft kv 可能会对多个请求作为一个 batch 来写入，所以用 TOTAL_TIME 来衡量各个模块的耗时时，对 raft kv 的写入相关监控项不适用，具体是： tikv_raft_process，tikv_raft_append_log，tikv_raft_commit_log，tikv_raft_apply_wait，tikv_raft_apply_log，这里用 P999,P99 的时间来对比各个模块的耗时更加合理。
+>
+> 原因是，假如有 10 个 async write 请求，raft kv 内部将 10 个请求打包成一个 batch 执行，执行时间为 1 秒，所以每个请求的执行时间为 1 秒，10 个请求的总时间是 10 秒，但是 raft kv 处理的总时间是1秒。如果用 TOTAL_TIME 来衡量，用户可能会弄不懂剩余的 9 秒耗时在哪儿。这里从总请求数（ TOTAL_COUNT ）也能看出 raft kv 的监控和之前其他监控的差异。
+
+#### Errors Occurred in Each Component
+
+包括 TiDB , TiKV 出现错误的总数，如写 binlog 失败，tikv server is busy, TiKV channel full， tikv write stall 等错误，具体各项错误含义可以看行注释。
+
+![Errors Occurred in Each Component 报表](/media/dashboard/diagnostics-error.png)
+
+#### TiDB/PD/TiKV 的具体监控信息
+
+这部分包括了 TiDB/PD/TIKV 更多的具体的监控信息。
+
+#### TiDB 相关监控信息
+
+##### Time Consumed by TiDB Component
+
+TiDB 的各项监控耗时以及各项耗时的占比。和 overview 中的 time consume 表类似，但是这个表的 label 信息会更丰富，能看到更多细节。
+
+##### TiDB Server Connections
+
+TiDB 各个实例的客户端连接数。
+
+##### TiDB Transaction
+
+TiDB 事务相关的监控。
+
+![Transaction 报表](/media/dashboard/diagnostics-tidb-txn.png)
+
+* TOTAL_VALUE： 该项监控在报告时间段内所有值的和（SUM）。
+* TOTAL_COUNT：该项监控出现的总次数。
+* P999: 该项监控的 P999 最大值。
+* P99: 该项监控的 P99 最大值。
+* P90: 该项监控的 P90 最大值。
+* P80: 该项监控的 P80 最大值。
+
+示例：
+
+上表中，在报告时间范围内，tidb_txn_kv_write_size：一共约有 181296 次事务的 kv 写入，总 kv 写入大小是 266.772 MB， 其中单次事务的 KV 写入的 P999, P99, P90, P80 的最大值分别为 116.913 KB , 1.996 KB, 1.905 KB, 1.805 KB。
+
+##### DDL Owner
+
+![TiDB DDL Owner 报表](/media/dashboard/diagnostics-tidb-ddl.png)
+
+上表表示从 2020-05-21 14:40:00 开始，集群的 ddl-owner 在 10.0.1.13:10080 节点，如果 owner 发生变更，上表会有多行数据，其中 MinTime 列表示已知对应 Owner 的最小时间。
+
+> 如果 owner 信息为空，不代表这个时间段内一定没有 owner, 因为这里是依靠 ddl_worker 的监控信息来判断 DDL owner 的，也可能是这个时间段内 ddl_worker 没有做任何 DDL job 导致这里信息为空。
+
+TiDB  中其他监控表如下，这里不再一一列举：
+
+* Statistics Info：TiDB 统计信息的相关监控。
+* Top 10 Slow Query：报表时间范围内 Top 10 的慢查询信息。
+* Top 10 Slow Query Group By Digest：报表时间范围内 Top 10 的慢查询信息，并按照 SQL 指纹聚合。
+* Slow Query With Diff Plan：报表时间范围内执行计划发生变更的 SQL 语句。
+
+#### PD 相关监控信息
+
+PD 模块相关监控的报表如下：
+
+* Time Consumed by PD Component，PD 中相关模块的耗时监控
+* Blance Leader/Region，报表时间范围内集群发生的 balance-region, balance leader 监控，比如从  tikv_note_1 上调度走了多少个 leader，调度进了多少个 leader。
+* Cluster Status，集群的状态信息，包括总 TiKV 数量，总集群存储容量，region 数量，离线 TiKV 的数量等信息。
+* Store Status，记录各个 TiKV 节点的状态信息，包括 region score, leader score，region/leader 的数量。
+* Etcd Status，PD 内部的 ETCD 相关信息。
+
+#### TiKV 相关监控信息
+
+TIKV 模块的相关监控报表如下：
+
+* Time Consumed by TiKV Component，TiKV 中相关模块的耗时监控
+* Time Consumed by RocksDB，TiKV 中 RocksDB 的耗时监控
+* TiKV Error，TiKV 中各个模块相关的 error 信息
+* TiKV Engine Size，TiKV 中各个节点 column famaly 的存储数据大小
+* Coprocessor Info，TiKV 中 coprocessor 模块相关的监控。
+* Raft Info，TiKV 中 raft 模块的相关监控信息
+* Snapshot Info，TiKV 中 snapshot 相关监控信息
+* GC Info，TiKV 中 GC 相关的监控信息
+* Cache Hit，TiKV 中 rocksdb 的各个缓存的命中率监控信息
+
+### 配置信息
+
+配置信息中，部分模块的配置信息可以显示报告时间范围内的配置值，有部分配置则因为无法获取到历史的配置值，所以是生成报告时刻的当前配置值。
+
+在报告时间范围内，以下表包括部分配置的在报告时间范围的开始时间的值：
+
+* Scheduler Initial Config：PD 调度相关配置在报告开始时间的初始值
+* TiDB GC Initial Config：TiDB GC 相关配置在报告开始时间的初始值
+* TiKV RocksDB Initial Config：TiKV RocksDB  相关配置在报告开始时间的初始值
+* TiKV RaftStore Initial Config：TiKV RaftStore  相关配置在报告开始时间的初始值
+
+在报表时间范围内，如若有些配置被修改过，以下表包括部分配置被修改的记录：
+
+* Scheduler Config Change History
+* TiDB GC Config Change History
+* TiKV RocksDB Config Change History
+* TiKV RaftStore Config Change History
+
+示例：
+
+![Scheduler Config Change History 报表](/media/dashboard/diagnostics-config-change.png)
+
+上面报表显示，leader-schedule-limit 配置参数在报告时间范围内有被修改过：
+
+* 2020-05-22T20:00:00+08:00，即报告的开始时间 leader-schedule-limit 的配置值为 4，这里并不是指该配置被修改了，只是说明在报告时间范围的开始时间其配置值是 4。
+* 2020-05-22T20:07:00+08:00，leader-schedule-limit 的配置值为 8，说明在 2020-05-22T20:07:00+08:00 左右，该配置的值被修改了。
+
+下面的报表是生成报告时，TiDB, PD, TiKV 的在生成报告时刻的当前配置：
+
+* TiDB's Current Config
+* PD's Current Config
+* TiKV's Current Config
+
+## 对比报告
+
+生成 2 个时间段的对比报告，其内容和单个时间段的报告是一样的，只是加入了对比列显示两个时间段的差别。下面主要介绍对比报告中的一些特有表以及如何查看对比报表。
+
+首先在 基本信息中的 `Compare Report Time Range` 报表会显示出对比的两个时间段：
+
+![Compare Report Time Range 报表](/media/dashboard/diagnostics-compare-time.png)
+
+其中 t1 是正常时间段，或者叫参考时间段，t2 是异常时间段。
+
+下面是一些慢查询相关的报表：
+
+* Slow Queries In Time Range t2：仅出现在 t2 时间段但没有出现在 t1 时间段的慢查询
+* Top 10 slow query in time range t1：t1 时间段的 Top10 慢查询
+* Top 10 slow query in time range t2：t2 时间段的 Top10 慢查询
+
+### DIFF_RATIO 介绍
+
+这里以  `Instance CPU usage` 为例子介绍 `DIFF_RATIO`。
+
+![Compare Instance CPU Usage 报表](/media/dashboard/diagnostics-compare-instance-cpu-usage.png)
+
+* t1.AVG, t1.MAX, t1.Min 分别是 t1 时间段内 CPU 使用率的 平均值，最大值，最小值。
+* t2.AVG, t2.MAX, t2.Min 分别是 t2 时间段内 CPU 使用率的 平均值，最大值，最小值。
+* AVG_DIFF_RATIO 表示 t1 和 t2 时间段平均值的 DIFF_RATIO
+* MAX_DIFF_RATIO 表示 t1 和 t2 时间段最大值的 DIFF_RATIO
+* MIN_DIFF_RATIO 表示 t1 和 t2 时间段最小值的 DIFF_RATIO
+
+DIFF_RATIO：表示2个时间段的差异大小，有以下几个取值方式：
+
+* 如果该监控仅在 t2 时间内才有值，t1 时间段没有，则 DIFF_RATIO 取值为 1
+* 如果监控项仅在 t1 时间内才有值，t1 时间段没有，则 DIFF_RATIO 取值为 -1
+* 如果 t2 时间段的值比 t1 时间段的值大，则 DIFF_RATIO = (t2.value / t1.value) - 1
+* 如果 t2 时间段的值比 t1 时间段的值小，则 DIFF_RATIO = 1 - (t1.value / t2.value)
+
+例如上表中，`tidb` 节点的平均 CPU 使用率在 t2 时间段比 t1 时间段高 2.02 倍。 `2.02 = 1240/410 - 1`。 
+
+### Maximum Different Item 报表介绍
+
+`Maximum Different Item` 的报表是对比 2 个时间段的监控项后，按照监控项的差异大小排序，通过这个表可以很快发现 2 个时间段哪些监控的差异最大。示例如下：
+
+![Maximum Different Item 报表](/media/dashboard/diagnostics-maximum-different-item.png)
+
+* Table: 表示这个监控项来自于对比报告中的哪个报表，如 `TiKV, coprocessor_info` 表示是 TiKV 组件下的 `coprocessor_info` 报表。
+* METRIC_NAME: 监控项名，点击 `expand` 可以查看该监控的不同 label 的差异对比。
+* LABEL：监控项对应的 label。比如 `TiKV Coprocessor scan` 监控项有 2 个 label，分别是 instance, req, tag, sql_type，分别表示为 TiKV 地址，请求类型，操作类型 和 操作的 column famaly。
+* MAX_DIFF：差异大小，取值为 t1.VALUE 和 t2.VALUE 的 DIFF_RATIO 计算。
+
+可以从上表中发现，t2 时间段比 t1 时间段多出了很多倍的 coprocessor 请求，TiDB 的解析SQL (parse) 时间也变多了很多倍等等。
diff --git a/dashboard/dashboard-diagnostics-usage.md b/dashboard/dashboard-diagnostics-usage.md
new file mode 100644
index 000000000000..6728e1ca1c34
--- /dev/null
+++ b/dashboard/dashboard-diagnostics-usage.md
@@ -0,0 +1,112 @@
+---
+title: 使用诊断报告定位问题
+category: how-to
+---
+
+# 使用诊断报告定位问题
+
+## 对比诊断功能示例
+
+对比报告中有一个对比诊断的功能，通过对比2个时间段的监控项差异来尝试帮助 DBA 定位问题。先看几个示例。
+
+### 大查询/写入导致 qps 抖动或延迟上升诊断
+
+#### 示例 1
+
+![QPS 图](/media/dashboard/diagnostics-usage1.png)
+
+上图中，是在跑 go-ycsb 的压测，可以发现，在 2020-03-10 13:24:30 时，QPS 突然开始下降，3 分钟后，QPS 开始恢复正常，这是为什么呢？
+
+生成以下 2 个时间范围的对比报告：
+
+T1: 2020-03-10 13:21:00 ，2020-03-10 13:23:00 ，正常时间段，又叫参考时间段
+T2: 2020-03-10 13:24:30 ， 2020-03-10 13:27:30 ，QPS 开始下降的异常时间段
+
+这里2个时间间隔都是 3 分钟，因为抖动的影响范围就是3分钟。因为诊断时会用一些监控的平均值做对比，所有间隔时间太长会导致平均值差异不明显，然后无法准确定位问题。
+
+生成报告后查看 **Compare Diagnose** 报表内容如下：
+
+![对比诊断结果](/media/dashboard/diagnostics-usage2.png)
+
+上面诊断结果显示，在诊断的时间内可能有大查询，下面的每一行的含义是：
+
+* tidb_qps 下降 0.93 倍
+* tidb_query_duration, P999的查询延迟上升 1.54 倍
+* tidb_cop_duration，P999 的 cop 请求的处理延迟上升 2.48 倍
+* tidb_kv_write_num，P999 的 tidb 的事务写入 kv 数量上升 7.61 倍
+* tikv_cop_scan_keys_total_nun, TiKV 的 coprocessor 扫描 key/value 的数量分别在 3 台 TiKV 上有很大的提升。
+* pd_operator_step_finish_total_count 中， transfer leader 的数量上升 2.45 倍，说明异常时间段的调度比正常时间段要高。
+* 提示可能有慢查询，并提示用 SQL 查询 TiDB 的慢日志。在 TiDB 中执行结果如下：
+
+```sql
+SELECT * FROM (SELECT count(*), min(time), sum(query_time) AS sum_query_time, sum(Process_time) AS sum_process_time, sum(Wait_time) AS sum_wait_time, sum(Commit_time), sum(Request_count), sum(process_keys), sum(Write_keys), max(Cop_proc_max), min(query),min(prev_stmt), digest FROM information_schema.CLUSTER_SLOW_QUERY WHERE time >= '2020-03-10 13:24:30' AND time < '2020-03-10 13:27:30' AND Is_internal = false GROUP BY digest) AS t1 WHERE t1.digest NOT IN (SELECT digest FROM information_schema.CLUSTER_SLOW_QUERY WHERE time >= '2020-03-10 13:21:00' AND time < '2020-03-10 13:24:00' GROUP BY digest) ORDER BY t1.sum_query_time DESC limit 10\G
+***************************[ 1. row ]***************************
+count(*)           | 196
+min(time)          | 2020-03-10 13:24:30.204326
+sum_query_time     | 46.878509117
+sum_process_time   | 265.924
+sum_wait_time      | 8.308
+sum(Commit_time)   | 0.926820886
+sum(Request_count) | 6035
+sum(process_keys)  | 201453000
+sum(Write_keys)    | 274500
+max(Cop_proc_max)  | 0.263
+min(query)         | delete from test.tcs2 limit 5000;
+min(prev_stmt)     |
+digest             | 24bd6d8a9b238086c9b8c3d240ad4ef32f79ce94cf5a468c0b8fe1eb5f8d03df
+```
+
+可以发现，从 13:24:30 开始有一个批量删除的大写入，一共执行了 196 次，每次删除 5000 行数据，总共耗时 46.8 秒。
+
+#### 示例2
+
+如果大查询一直没执行完，就不会记录慢日志，这个时候也能诊断吗？下面再看一个例子。
+
+![QPS 图](/media/dashboard/diagnostics-usage3.png)
+
+上图中，也是在跑 go-ycsb 的压测，可以发现，在 2020-03-08 01:46:30 时，QPS 突然开始下降，并且一直没有恢复。
+
+生成以下2个时间范围的对比报告：
+
+T1 : 2020-03-08 01:36:00 ，2020-03-08 01:41:00 ，正常时间段，又叫参考时间段
+T2: 2020-03-08 01:46:30 ，2020-03-08 01:51:30 ，QPS 开始下降的异常时间段
+
+生成报告后看 `Compare Diagnose` 报表的内容如下：
+
+![对比诊断结果](/media/dashboard/diagnostics-usage4.png)
+
+上面诊断结果和例 1 类似，这里不再重复赘述，直接看最后一行，提示可能有慢查询，并提示用 SQL 查询 TiDB 日志中的 expensive query。在 TiDB 中执行结果如下：
+
+```sql
+> SELECT * FROM information_schema.cluster_log WHERE type='tidb' AND time >= '2020-03-08 01:46:30' AND time < '2020-03-08 01:51:30' AND level = 'warn' AND message LIKE '%expensive_query%'\G
+TIME     | 2020/03/08 01:47:35.846
+TYPE     | tidb
+INSTANCE | 172.16.5.40:4009
+LEVEL    | WARN
+MESSAGE  | [expensivequery.go:167] [expensive_query] [cost_time=60.085949605s] [process_time=2.52s] [wait_time=2.52s] [request_count=9] [total_keys=996009] [process_keys=996000] [num_cop_tasks=9] [process_avg_time=0.28s] [process_p90_time=0.344s] [process_max_time=0.344s] [process_max_addr=172.16.5.40:20150] [wait_avg_time=0.000777777s] [wait_p90_time=0.003s] [wait_max_time=0.003s] [wait_max_addr=172.16.5.40:20150] [stats=t_wide:pseudo] [conn_id=19717] [user=root] [database=test] [table_ids="[80,80]"] [txn_start_ts=415132076148785201] [mem_max="23583169 Bytes (22.490662574768066 MB)"] [sql="select count(*) from t_wide as t1 join t_wide as t2 where t1.c0>t2.c1 and t1.c2>0"]
+```
+
+上面查询结果显示，在 172.16.5.40:4009 这台 TiDB 上，2020/03/08 01:47:35.846 有一个已经执行了 60s，但还没有执行完的 的 expensive_query, 这个query 是个笛卡尔积的 join , 应该是有用户手抖了。
+
+## 用对比报告定位问题
+
+诊断有可能是误诊，使用对比报告或许可以帮助 DBA 更快速的定位问题。参考以下示例。
+
+![QPS 图](/media/dashboard/diagnostics-usage5.png)
+
+上图中，也是在跑 go-ycsb 的压测，可以发现，在 2020-05-22 22:14:00 时，QPS 突然开始下降，大概在持续 3 分钟后恢复。
+
+生成以下2个时间范围的对比报告：
+
+T1: 2020-05-22 22:11:00 ，2020-05-22 22:14:00 ，正常时间段
+T2: 2020-05-22 22:14:00 ，2020-05-22 22:17:00 ，QPS 开始下降的异常时间段
+
+生成对比报告后，查看 **Max diff item** 报表，它是对比2个时间段的监控项后，按照监控项的差异大小排序，这个表的结果如下：
+
+![对比结果](/media/dashboard/diagnostics-usage6.png)
+
+从上面结果可以看出，T2 时间段新增了很多倍的 Coprocessor 请求，可以猜测可能是 T2 时间段出现了一些大查询，或者是查询较多的负载。
+
+实际上，在 t1 ~ t2 整个时间段内都在跑 `go-ycsb` 的压测，然后在 t2 时间段跑了 20 个 `tpch` 的查询，所以是因为 `tpch` 大查询导致了出现很多的 cop 请求。
+
+这种大查询执行时间超过慢日志的阈值后也会记录在慢日志里面，可以继续查看 `Slow Queries In Time Range t2` 报表查看是否有一些慢查询。不过有一点主要注意的是，有些仅出现在 T2 时间段的慢查询，也可能是这种查询在 T1 时间段也存在，但是由于 T2 时间段的其他负载影响导致其执行变慢。
diff --git a/media/dashboard/diagnostics-access.png b/media/dashboard/diagnostics-access.png
new file mode 100644
index 000000000000..51937a32588f
Binary files /dev/null and b/media/dashboard/diagnostics-access.png differ
diff --git a/media/dashboard/diagnostics-cluster-hardware.png b/media/dashboard/diagnostics-cluster-hardware.png
new file mode 100644
index 000000000000..d5b5d036b87f
Binary files /dev/null and b/media/dashboard/diagnostics-cluster-hardware.png differ
diff --git a/media/dashboard/diagnostics-cluster-info.png b/media/dashboard/diagnostics-cluster-info.png
new file mode 100644
index 000000000000..ebde1ecdd833
Binary files /dev/null and b/media/dashboard/diagnostics-cluster-info.png differ
diff --git a/media/dashboard/diagnostics-compare-instance-cpu-usage.png b/media/dashboard/diagnostics-compare-instance-cpu-usage.png
new file mode 100644
index 000000000000..7b28c6a73aa4
Binary files /dev/null and b/media/dashboard/diagnostics-compare-instance-cpu-usage.png differ
diff --git a/media/dashboard/diagnostics-compare-process-cpu-usage.png b/media/dashboard/diagnostics-compare-process-cpu-usage.png
new file mode 100644
index 000000000000..b200537348c5
Binary files /dev/null and b/media/dashboard/diagnostics-compare-process-cpu-usage.png differ
diff --git a/media/dashboard/diagnostics-compare-time.png b/media/dashboard/diagnostics-compare-time.png
new file mode 100644
index 000000000000..16d39cbdde63
Binary files /dev/null and b/media/dashboard/diagnostics-compare-time.png differ
diff --git a/media/dashboard/diagnostics-config-change.png b/media/dashboard/diagnostics-config-change.png
new file mode 100644
index 000000000000..10228575cd1b
Binary files /dev/null and b/media/dashboard/diagnostics-config-change.png differ
diff --git a/media/dashboard/diagnostics-error.png b/media/dashboard/diagnostics-error.png
new file mode 100644
index 000000000000..18b1cbc1a4f4
Binary files /dev/null and b/media/dashboard/diagnostics-error.png differ
diff --git a/media/dashboard/diagnostics-example-table.png b/media/dashboard/diagnostics-example-table.png
new file mode 100644
index 000000000000..3d5ef53c46a5
Binary files /dev/null and b/media/dashboard/diagnostics-example-table.png differ
diff --git a/media/dashboard/diagnostics-gen-compare-report.png b/media/dashboard/diagnostics-gen-compare-report.png
new file mode 100644
index 000000000000..a71e9646503a
Binary files /dev/null and b/media/dashboard/diagnostics-gen-compare-report.png differ
diff --git a/media/dashboard/diagnostics-gen-process.png b/media/dashboard/diagnostics-gen-process.png
new file mode 100644
index 000000000000..7dcd8d920e2b
Binary files /dev/null and b/media/dashboard/diagnostics-gen-process.png differ
diff --git a/media/dashboard/diagnostics-gen-report.png b/media/dashboard/diagnostics-gen-report.png
new file mode 100644
index 000000000000..f9de54e6306e
Binary files /dev/null and b/media/dashboard/diagnostics-gen-report.png differ
diff --git a/media/dashboard/diagnostics-goroutines-count.png b/media/dashboard/diagnostics-goroutines-count.png
new file mode 100644
index 000000000000..170819bbfeee
Binary files /dev/null and b/media/dashboard/diagnostics-goroutines-count.png differ
diff --git a/media/dashboard/diagnostics-max-diff-item.png b/media/dashboard/diagnostics-max-diff-item.png
new file mode 100644
index 000000000000..3bf901a781b9
Binary files /dev/null and b/media/dashboard/diagnostics-max-diff-item.png differ
diff --git a/media/dashboard/diagnostics-maximum-different-item.png b/media/dashboard/diagnostics-maximum-different-item.png
new file mode 100644
index 000000000000..076d7bec632f
Binary files /dev/null and b/media/dashboard/diagnostics-maximum-different-item.png differ
diff --git a/media/dashboard/diagnostics-node-load-info.png b/media/dashboard/diagnostics-node-load-info.png
new file mode 100644
index 000000000000..acd40f31d087
Binary files /dev/null and b/media/dashboard/diagnostics-node-load-info.png differ
diff --git a/media/dashboard/diagnostics-process-cpu-usage.png b/media/dashboard/diagnostics-process-cpu-usage.png
new file mode 100644
index 000000000000..4a9370fb5d1a
Binary files /dev/null and b/media/dashboard/diagnostics-process-cpu-usage.png differ
diff --git a/media/dashboard/diagnostics-process-memory-usage.png b/media/dashboard/diagnostics-process-memory-usage.png
new file mode 100644
index 000000000000..fb630af116b1
Binary files /dev/null and b/media/dashboard/diagnostics-process-memory-usage.png differ
diff --git a/media/dashboard/diagnostics-report-time-range.png b/media/dashboard/diagnostics-report-time-range.png
new file mode 100644
index 000000000000..b16072ac8371
Binary files /dev/null and b/media/dashboard/diagnostics-report-time-range.png differ
diff --git a/media/dashboard/diagnostics-thread-cpu-usage.png b/media/dashboard/diagnostics-thread-cpu-usage.png
new file mode 100644
index 000000000000..194d665f5937
Binary files /dev/null and b/media/dashboard/diagnostics-thread-cpu-usage.png differ
diff --git a/media/dashboard/diagnostics-tidb-ddl.png b/media/dashboard/diagnostics-tidb-ddl.png
new file mode 100644
index 000000000000..8f141f9dc26b
Binary files /dev/null and b/media/dashboard/diagnostics-tidb-ddl.png differ
diff --git a/media/dashboard/diagnostics-tidb-txn.png b/media/dashboard/diagnostics-tidb-txn.png
new file mode 100644
index 000000000000..1f80fab7ec50
Binary files /dev/null and b/media/dashboard/diagnostics-tidb-txn.png differ
diff --git a/media/dashboard/diagnostics-time-relation.png b/media/dashboard/diagnostics-time-relation.png
new file mode 100644
index 000000000000..33b7eac7e987
Binary files /dev/null and b/media/dashboard/diagnostics-time-relation.png differ
diff --git a/media/dashboard/diagnostics-total-time-consume.png b/media/dashboard/diagnostics-total-time-consume.png
new file mode 100644
index 000000000000..048f35ed7da9
Binary files /dev/null and b/media/dashboard/diagnostics-total-time-consume.png differ
diff --git a/media/dashboard/diagnostics-usage1.png b/media/dashboard/diagnostics-usage1.png
new file mode 100644
index 000000000000..8466351edee2
Binary files /dev/null and b/media/dashboard/diagnostics-usage1.png differ
diff --git a/media/dashboard/diagnostics-usage2.png b/media/dashboard/diagnostics-usage2.png
new file mode 100644
index 000000000000..97d45fc1a21f
Binary files /dev/null and b/media/dashboard/diagnostics-usage2.png differ
diff --git a/media/dashboard/diagnostics-usage3.png b/media/dashboard/diagnostics-usage3.png
new file mode 100644
index 000000000000..fab12da1a62d
Binary files /dev/null and b/media/dashboard/diagnostics-usage3.png differ
diff --git a/media/dashboard/diagnostics-usage4.png b/media/dashboard/diagnostics-usage4.png
new file mode 100644
index 000000000000..b90c85ec800d
Binary files /dev/null and b/media/dashboard/diagnostics-usage4.png differ
diff --git a/media/dashboard/diagnostics-usage5.png b/media/dashboard/diagnostics-usage5.png
new file mode 100644
index 000000000000..19edcf2610d4
Binary files /dev/null and b/media/dashboard/diagnostics-usage5.png differ
diff --git a/media/dashboard/diagnostics-usage6.png b/media/dashboard/diagnostics-usage6.png
new file mode 100644
index 000000000000..5630f7701e3d
Binary files /dev/null and b/media/dashboard/diagnostics-usage6.png differ