From 9c1d1be3eedc08ec76234d39b9e2da2cf6902f9e Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Mon, 8 Jun 2020 21:09:37 +0800 Subject: [PATCH 01/10] Add faq. intro, deploy, secure and reverse proxy for TiDB Dashboard --- dashboard/dashboard-faq.md | 60 ++++++++++++ dashboard/dashboard-intro.md | 63 +++++++++++++ dashboard/dashboard-ops-deploy.md | 138 ++++++++++++++++++++++++++++ dashboard/dashboard-ops-security.md | 79 ++++++++++++++++ 4 files changed, 340 insertions(+) create mode 100644 dashboard/dashboard-faq.md create mode 100644 dashboard/dashboard-intro.md create mode 100644 dashboard/dashboard-ops-deploy.md create mode 100644 dashboard/dashboard-ops-security.md diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md new file mode 100644 index 0000000000000..901f7b45ac28f --- /dev/null +++ b/dashboard/dashboard-faq.md @@ -0,0 +1,60 @@ +--- +title: TiDB Dashboard FAQ +summary: Learn about the frequently asked questions (FAQs) and answers about TiDB Dashboard. +category: how-to +--- + +# TiDB Dashboard FAQ + +This document summarizes the frequently asked questions (FAQs) and answers about TiDB Dashboard. + +## Access TiDB Dashboard + +### When the firewall or reverse proxy is configured, I am redirected to an internal address other than TiDB Dashboard + +When multiple PD instances are deployed in a cluster, only one of the PD instances actually runs the TiDB Dashboard service. If you access other PD instances than this Dashboard-running one, your browser redirects you to another address. If the firewall or reverse proxy is not properly configured for accessing TiDB Dashboard, after the visiting the Dashboard, you might be redirected to an internal address that is protected by the firewall or reverse proxy. + +- See [TiDB Dashboard Multi-PD Instance Deployment](/dashboard/dashboard-ops-deploy.md#) to learn the working principle of TiDB Dashboard with multiple PD instances. +- See [Use TiDB Dashboard through Reverse Proxy](/dashboard/dashboard-ops-reverse-proxy.md) to learn how to correctly configure reverse proxy. +- See [Improve TiDB Dashboard Security](/dashboard/dashboard-ops-security.md) to learn how to correctly configure the firewall. + +### When dual network cards are deployed, TiDB Dashboard cannot be accessed using another network card + +For security reasons, TiDB Dashboard on PD only monitors the IP addresses specified during deployment (that is, it only listens on one network card), nsot on `0.0.0.0`. Therefore, when multiple network cards are installed on the host, you cannot access TiDB Dashboard using another network card. + +If you have deployed TiDB using the `tiup cluster` or `tiup playground` command, currently this problem cannot be solved. It is recommended that you use a reverse proxy to safely expose TiDB Dashboard to another network card. For details, see [Use TiDB Dashboard through Reverse Proxy](/dashboard/dashboard-ops-reverse-proxy.md). + +## Interface feature + +### `prometheus_not_found` error is shown in **QPS** and **Latency** sections on the Overview page + +Monitoring metrics in **QPS** and **Latency** sections on the **Overview** page rely on the Prometheus monitoring instance that should have been deployed properly in the cluster. Errors are shown if Prometheus is not deployed. You can address this problem by deploying new Prometheus instance in the cluster. + +If the Prometheus monitoring instance has been deployed but this error persists, the possible reason is that the version of your deployment tool (TiUP, TiDB Operator or TiDB Ansible) is old, and this tool does report monitoring addresses automatically, which makes TiDB Dashboard unable to perceive and query monitoring data. You can upgrade you deployment tool to the latest version and try again. + +If your deployment tool is TiUP, take the following steps to solve this problem. For other deployment tools, refer to the corresponding documents of those tools. + +1. Upgrade TiUP and TiUP Cluster: + + {{< copyable "shell-regular" >}} + + ```bash + tiup update --self + tiup update cluster --force + ``` + +2. After the upgrade, when a new cluster is deployed with monitoring nodes, the monitoring metrics can be shown normally. + +3. For an existing cluster, you can restart this cluster to report the monitoring addresses. Replace `CLUSTER_NAME` with the actual cluster name: + + {{< copyable "shell-regular" >}} + + ```bash + tiup cluster start CLUSTER_NAME + ``` + + Even if the cluster has been started, still execute this command. This command does not affect the normal application in the cluster, but refreshes and reports the monitoring addresses, so that the monitoring metrics can be shown normally in TiDB Dashboard. + +### `invalid connection` error is shown in **Top SQL Statements** and **Recent Slow Queries** on the Overview page + +The possible reason is that you have enabled the `prepared-plan-cache` feature of TiDB. As an experimental feature, `prepared-plan-cache` might not function properly in some TiDB versions, which might cause this problem in TiDB Dashboard (and other applications) after being enabled. Disable `prepared-plan-cache` in [TiDB Configuration file](/tidb-configuration-file.md#prepared-plan-cache). \ No newline at end of file diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md new file mode 100644 index 0000000000000..9dd1bb80e1588 --- /dev/null +++ b/dashboard/dashboard-intro.md @@ -0,0 +1,63 @@ +--- +title: TiDB Dashboard Introduction +summary: Introduce TiDB Dashboard. +category: how-to +--- + +# TiDB Dashboard Introduction + +TiDB Dashboard is a graphical interface provided by TiDB since v4.0, which is used to monitor and diagnose TiDB clusters. TiDB Dashboard is built into the PD component of TiDB and does not require independent deployment. + +![TiDB Dashboard interface](/media/dashboard/dashboard-intro.gif) + +TiDB Dashboard is open-sourced on [Github](https://github.com/pingcap-incubator/tidb-dashboard). + +This document introduces the main features of TiDB Dashboard. You can click links in the following sections to learn more details. + +## Show the overall running status of TiDB cluster + +You can use TiDB Dashboard to learn the TiDB cluster's queries per second (QPS), execution duration, the SQL types that consume the most resources, and other overview information. + +See [TiDB Dashboard Overview](/dashboard/dashboard-overview.md) for details. + +## Show the running status of components and host + +You can use TiDB Dashboard to view the running status of TiDB, TiKV, PD, TiFlash components in the entire cluster and the running status of the host on which these components are located. + +See [TiDB Dashboard Cluster Information Page](/dashboard/dashboard-cluster-info.md) for details. + +## Show distribution and trend of read and write traffic + +The Key Visualizer feature of TiDB Dashboard visually shows the change of read and write traffic over time in the entire cluster in the form of heatmap. You can use this feature to timely discover changes of application modes or locate hotspot issues with uneven performance. + +See [Key Visualizer Page](/dashboard/dashboard-key-visualizer.md) for details. + +## Show a list of execution information of all SQL statements + +The execution information of all SQL statements is listed on the SQL Statements page. You can use this page to learn the execution duration and total execution times at all stages, which helps you analyze and locate the SQL queries that consume the most resource and improve the overall cluster performance. + +See [SQL Statements Page of TiDB Dashboard](/dashboard/dashboard-statement-list.md) for details. + +## Learn the detailed execution information of slow queries + +The Slow Queries page of TiDB Dashboard shows a list of all SQL statements that take a long time to execute, including the SQL texts and execution information. This page helps you locate the cause of slow SQL performance or performance jitter. + +See [Slow Queries Page](/dashboard/dashboard-slow-query.md) for details. + +## Diagnose common cluster problems and generate reports + +The diagnostic feature of TiDB Dashboard automatically determines whether some common risks (such as inconsistent configurations) or problems exist in the cluster, generates reports and gives operation suggestions, or compares the status of each cluster metric in different time ranges for you to analyze the possible problems. + +See [TiDB Dashboard Cluster Diagnostics Page](/dashboard/dashboard-diagnostics-access.md) for details. + +## Query logs of all components + +On the Search Logs page of TiDB Dashboard, you can quickly search logs of all running instances in the cluster by keywords, time range, and other conditions, and download these logs to your local. + +See [Search Logs Page](/dashboard/dashboard-log-search.md) for details。 + +## Collect performance data of each component + +Advanced debugging feature: Profiles each component online, and analyze internal operations (executed during the analysis period) and proportions of component instances without a third-party tools. + +See [Profile Instances Page](/dashboard/dashboard-profiling.md) for details. diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md new file mode 100644 index 0000000000000..0a7b946803a15 --- /dev/null +++ b/dashboard/dashboard-ops-deploy.md @@ -0,0 +1,138 @@ +--- +title: Deploy TiDB Dashboard +category: how-to +--- + +# Deploy TiDB Dashboard + +The TiDB Dashboard interface is built into the PD component of TiDB v4.0 or higher, and no additional deployment is required. You can just deploy a standard TiDB cluster and TiDB Dashboard is be integrated natively. + +See to the following documents to learn how to deploy a standard TiDB cluster: + ++ [Quick Start Guide for the TiDB Database Platform](/quick-start-with-tidb.md#deploy-a-local-test-environment-using-tiup-playground) ++ [Deploy TiDB in Production Environment](/production-deployment-using-tiup.md) ++ [Kubernetes environment deployment](https://pingcap.com/docs/tidb-in-kubernetes/stable/access-dashboard/) + +> **Note:** +> +> You cannot deploy TiDB Dashboard in a TiDB cluster earlier than v4.0. + +## Deployment with multiple PD instances + +When multiple PD instances are deployed in the cluster, only one of these instances provides the TiDB Dashboard service. + +PD instances, when running for the first time, automatically negotiate with each other and choose one instance to provide the TiDB Dashboard service. After the negotiation is completed, the TiDB Dashboard service will always run on the chosen instance no matter it is restarted or scaled out, unless this instance is manually scaled in. TiDB Dashboard will not run on other PD instances. This negotiation process can be completed automatically without user intervention. + +When you access a PD instance that does not provide the TiDB Dashboard service, the browser receives a redirection instruction and automatically guides you to re-access the PD instance that provides the TiDB Dashboard service, so that you can use the service normally. This process is shown in the image below. + +![Process Schematic](/media/dashboard/dashboard-ops-multiple-pd.svg) + +> **Note:** +> +> The PD instance that provides the TiDB Dashboard service might not be consistent with the PD leader. + +### Check the PD instance that actually provides the TiDB Dashboard service + +If a started cluster is deployed using TiUP, you can use the `tiup cluster display` command to check which PD node provides the TiDB Dashboard service. Replace `CLUSTER_NAME` with the cluster name. + +{{< copyable "shell-regular" >}} + +```bash +tiup cluster display CLUSTER_NAME --dashboard +``` + +The sample output is as follows: + +```bash +http://192.168.0.123:2379/dashboard/ +``` + +> **Note:** +> +> This feature is available only in the later version of the `tiup cluster` deployment tool (v1.0.3 or later). You can upgrade `tiup cluster` with the following commands: +> +> {{< copyable "shell-regular" >}} +> +> ```bash +> tiup update --self +> tiup update cluster --force +> ``` + +### Switch to another PD instance to provide TiDB Dashboard service + +If a started cluster is deployed using TiUP, you can use the `tiup ctl pd` command to change the PD instance that provides the TiDB Dashboard service, or re-specify a PD instance to provide the TiDB Dashboard service with TiDB Dashboard disabled: + +{{< copyable "shell-regular" >}} + +```bash +tiup ctl pd -u http://127.0.0.1:2379 config set dashboard-address http://9.9.9.9:2379 +``` + +In the command above: + +- Replace `127.0.0.1:2379` with the IP and port of any PD instance. +- Replace `9.9.9.9:2379` with the IP and port of the new PD instance that you desire to run the TiDB Dashboard service. + +After the modification above, you can use the `tiup cluster display` command to confirm whether the modification takes effect (replace `CLUSTER_NAME` with the cluster name): + +{{< copyable "shell-regular" >}} + +```bash +tiup cluster display CLUSTER_NAME --dashboard +``` + +> **Warning:** +> +> If you change the instance to run TiDB Dashboard, the local data stored in the previous TiDB Dashboard instance will be lost, including the traffic visualization history and historical search records. + +## Disable TiDB Dashboard + +If a started cluster is deployed using TiUP, use the `tiup ctl pd` command to disable TiDB Dashboard on all PD instances (replace `127.0.0.1:2379` with the IP and port of any PD instance): + +{{< copyable "shell-regular" >}} + +```bash +tiup ctl pd -u http://127.0.0.1:2379 config set dashboard-address none +``` + +After disabling TiDB Dashboard, checking which PD instance provides the TiDB Dashboard service will fail: + +``` +Error: TiDB Dashboard is disabled +``` + +Visiting the TiDB Dashboard address of any PD instance via the browser will also fail: + +``` +Dashboard is not started. +``` + +## Re-enable TiDB Dashboard + +If a started cluster is deployed using TiUP, use the `tiup ctl pd` command to request PD to renegotiate an instance to run TiDB Dashboard (replace `127.0.0.1:2379` with the IP and port of any PD instance) : + +{{< copyable "shell-regular" >}} + +```bash +tiup ctl pd -u http://127.0.0.1:2379 config set dashboard-address auto +``` + +After executing the command above, use the `tiup cluster display` command to view the TiDB Dashboard instance address automatically negotiated by PD (replace `CLUSTER_NAME` with the cluster name): + +{{< copyable "shell-regular" >}} + +```bash +tiup cluster display CLUSTER_NAME --dashboard +``` + +You can also re-enable TiDB Dashboard by manually specifying which PD instance provides the TiDB Dashboard service. For specific operations, see [Switch to another PD instance to provide TiDB Dashboard service](#switch-to-another-pd-instance-to-provide-tidb-dashboard-service). + +> **Warning:** +> +> If the newly enabled TiDB Dashboard instance is inconsistent with the previous instance that provides the TiDB Dashboard service, the local data stored in the previous TiDB Dashboard instance will be lost, including traffic visualization history and historical search records. + +## Next + +- See [Access TiDB Dashboard](/dashboard/dashboard-access.md) to learn how to access and sign into the TiDB Dashboard interface. + +- See [Improve TiDB Dashboard Security](/dashboard/dashboard-ops-security.md) to learn how to enhance the security of TiDB Dashboard, such as configuring a firewall. diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md new file mode 100644 index 0000000000000..cc31c70866dd1 --- /dev/null +++ b/dashboard/dashboard-ops-security.md @@ -0,0 +1,79 @@ +--- +title: Improve TiDB Dashboard Security +summary: Learn how to improve the security of TiDB Dashboard. +category: how-to +--- + +# Improve TiDB Dashboard Security + +Although you need to sign into TiDB Dashboard before accessing it, TiDB Dashboard is designed to be accessed by trusted user entities by default. When you want to provide TiDB Dashboard to external network users or untrusted users for access, take the following measures to avoid security vulnerabilities. + +## Set a strong password for TiDB `root` user + +The account system of TiDB Dashboard is consistent with that of TiDB SQL users. By default, TiDB's `root` user has no password, so accessing TiDB Dashboard does not require password authentication, which will give the malicious visitor great privileges, including executing privileged SQL statements. + +It is recommended that you set a strong password for TiDB `root` user. See [TiDB User Account Management](/user-account-management.md) for details. + +## Use a firewall to block untrusted access + +TiDB Dashboard provides services through the PD client port, which defaults to . Although TiDB Dashboard requires identity authentication, other privileged interfaces (such as ) in PD carried on the PD client port do not require identity authentication and can perform privileged operations. Therefore, exposing the PD client port directly to the external network is extremely risky. + +It is recommended that you take the following measures: + ++ Use a firewall to prohibit a component from accessing **any** client port of the PD component via the external network or untrusted network. + + > **Note:** + > + > TiDB, TiKV, and other components need to communicate with the PD component through the PD client port, so do not block access to the internal network between components. Otherwise, the cluster will become unavailable. + ++ See [Use TiDB Dashboard through Reverse Proxy](/dashboard/dashboard-ops-reverse-proxy.md) to learn how to configure the reverse proxy to safely provide the TiDB Dashboard service on another port to the external network. + +### How to open access to TiDB Dashboard port when deploying multiple PD instances + +> **Warning:** +> +> This section describes an unsafe access solution, which is for the test environment only. **DO NOT** use this solution in the production environment. + +In the test environment, you might need to configure the firewall to open the TiDB Dashboard port for external access. + +When multiple PD instances are deployed, only one of the PD instances actually runs TiDB Dashboard, and browser redirection occurs when you access other PD instances. Therefore, you need to ensure that the firewall is configured with the correct IP address. For details of this mechanism, see [Deployment with multiple PD instances](/dashboard/dashboard-ops-deploy.md#deployment-with-multiple-pd-instances). + +When using the TiUP deployment tool, you can use the following command to view the address of the PD instance that actually runs TiDB Dashboard (replace `CLUSTER_NAME` with the cluster name): + +{{< copyable "shell-regular" >}} + +```bash +tiup cluster display CLUSTER_NAME --dashboard +``` + +The output is the actual TiDB Dashboard address. + +> **Note:** +> +> This feature is available only in the later version of the `tiup cluster` deployment tool (v1.0.3 or later). You can upgrade `tiup cluster` with the following commands: +> +> {{< copyable "shell-regular" >}} +> +> ```bash +> tiup update --self +> tiup update cluster --force +> ``` + +The following is a sample output: + +```bash +http://192.168.0.123:2379/dashboard/ +``` + +In this example, the firewall needs to be configured with inbound access for the `2379` port of the `192.168.0.123` open IP, and the TiDB Dashboard is accessed via . + +## Reverse proxy only for TiDB Dashboard + +As mentioned in [Use a firewall to block untrusted access](#use-a-firewall-to-block-untrusted access), the services provided under the PD client port include not only TiDB Dashboard (located at ), but also other privileged interfaces in PD (such as ). Therefore, when using a reverse proxy to provide TiDB Dashboard to the external network, ensure that the services **ONLY** with the `/dashboard` prefix are provided (**NOT** all services under the port) to avoid that the external network can access the privileged interface in PD through the reverse proxy . + +It is recommended that you see [Use TiDB Dashboard through Reverse Proxy](/dashboard/dashboard-ops-reverse-proxy.md) to learn a safe and recommended reverse proxy configuration. + +## Other recommended safety measures + +- [Enable TLS Authentication and Encrypt the Stored Data](/enable-tls-between-components.md) +- [Enable encrypted transmission for communication between TiDB client servers](/encrypted-connections-with-tls-protocols.md) From 9a91b8bead276a290a2e03fba2a1da2d5d27d002 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 9 Jun 2020 13:34:48 +0800 Subject: [PATCH 02/10] add Reverse Proxy document --- dashboard/dashboard-ops-deploy.md | 4 +- dashboard/dashboard-ops-reverse-proxy.md | 200 +++++++++++++++++++++++ 2 files changed, 202 insertions(+), 2 deletions(-) create mode 100644 dashboard/dashboard-ops-reverse-proxy.md diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index 0a7b946803a15..08e31257d2d4d 100644 --- a/dashboard/dashboard-ops-deploy.md +++ b/dashboard/dashboard-ops-deploy.md @@ -25,7 +25,7 @@ PD instances, when running for the first time, automatically negotiate with each When you access a PD instance that does not provide the TiDB Dashboard service, the browser receives a redirection instruction and automatically guides you to re-access the PD instance that provides the TiDB Dashboard service, so that you can use the service normally. This process is shown in the image below. -![Process Schematic](/media/dashboard/dashboard-ops-multiple-pd.svg) +![Process Schematic](/media/dashboard/dashboard-ops-multiple-pd.png) > **Note:** > @@ -41,7 +41,7 @@ If a started cluster is deployed using TiUP, you can use the `tiup cluster displ tiup cluster display CLUSTER_NAME --dashboard ``` -The sample output is as follows: +A sample output is as follows: ```bash http://192.168.0.123:2379/dashboard/ diff --git a/dashboard/dashboard-ops-reverse-proxy.md b/dashboard/dashboard-ops-reverse-proxy.md new file mode 100644 index 0000000000000..3899d01af7805 --- /dev/null +++ b/dashboard/dashboard-ops-reverse-proxy.md @@ -0,0 +1,200 @@ +--- +title: Use TiDB Dashboard Through Reverse Proxy +category: how-to +--- + +# Use TiDB Dashboard Through Reverse Proxy + +You can use a reverse proxy to safely provide the TiDB Dashboard service from the internal network to the external network. + +## Use NGINX reverse proxy + +### Step 1: Get the actual TiDB Dashboard address + +When multiple PD instances are deployed in the cluster, only one of the PD instances actually runs TiDB Dashboard. Therefore, you need to ensure that the upstream of the reverse proxy points to the correct address. For details of this mechanism, see [Deployment with multiple PD instances](/dashboard/dashboard-ops-deploy.md#deployment-with-multiple-pd-instances). + +When you use the TiUP deployment tool, execute the following command to get the actual TiDB Dashboard address (replace `CLUSTER_NAME` with the cluster name): + +{{< copyable "shell-regular" >}} + +```bash +tiup cluster display CLUSTER_NAME --dashboard +``` + +The output is the actual TiDB Dashboard address. A sample is as follows: + +```bash +http://192.168.0.123:2379/dashboard/ +``` + +> **Note:** +> +> This feature is available only in the later version of the `tiup cluster` deployment tool (v1.0.3 or later). You can upgrade `tiup cluster` with the following commands: +> +> {{< copyable "shell-regular" >}} +> +> ```bash +> tiup update --self +> tiup update cluster --force +> ``` + +### Step 2: Configure the NGINX reverse proxy + +When you use [NGINX](https://nginx.org/) as the reverse proxy, take the following steps: + +1. Use reverse proxy for TiDB Dashboard on the `80` port (for example). In the NGINX configuration file, add the following configuration: + + {{< copyable "" >}} + + ```nginx + server { + listen 80; + location /dashboard/ { + proxy_pass http://192.168.0.123:2379/dashboard/; + } + } + ``` + + Configure the URL filled in `proxy_pass` to be the actual address of the TiDB Dashboard obtained in [Step 1: Get the actual TiDB Dashboard address](#step-1-get-the-actual-tidb-dashboard-address). + + > **Warning:** + > + > Keep the `/dashboard/` path in the `proxy_pass` directive to ensure that only the services under this path are reverse proxied. Otherwise, security risks will be introduced. See [Improve TiDB Dashboard Security](/dashboard/dashboard-ops-security.md). + +2. Restart NGINX for the configuration to take effect. + +3. Test whether the reverse proxy is effective: access the `/dashboard/` address on the `80` port of the machine where NGINX is located (such as ) to access TiDB Dashboard. + +## Customize path prefix + +TiDB Dashboard provides services by default in the `/dashboard/` path, such as `http://example.com/dashboard/`, which is the case even for reverse proxies. To configure the reverse proxy to provide the TiDB Dashboard service with a non-default path, such as `http://example.com/foo` or `http://example.com/`, take the following steps. + +### Step 1: Modify PD configuration to specify the path prefix of TiDB Dashboard service + +Modify the `public-path-prefix` configuration item in the `[dashboard]` category of the PD configuration to specify the path prefix of the TiDB Dashboard service. After this item is modified, restart the PD instance for the modification to take effect. + +For example, if the cluster is deployed using TiUP and you want the service to run on `http://example.com/foo`, you can specify the following configuration: + +{{< copyable "" >}} + +```yaml +server_configs: + pd: + dashboard.public-path-prefix: /foo +``` + +If you are deploying a new cluster, you can add the configuration above to the `topology.yaml` TiUP topology file and deploy the cluster. For specific instruction, see [TiUP deployment document](/production-deployment-using-tiup.md#step-3-edit-the-initialization-configuration-file). + +For a deployed cluster: + +1. Open the configuration file of the cluster in the edit mode (replace `CLUSTER_NAME` with the cluster name). + + {{< copyable "shell-regular" >}} + + ```bash + tiup cluster edit-config CLUSTER_NAME + ``` + +2. Modify or add configuration items under the `pd` configuration of `server_configs`. If no `server_configs` exists, add it at the top level: + + {{< copyable "" >}} + + ```yaml + monitored: + ... + server_configs: + tidb: ... + tikv: ... + pd: + dashboard.public-path-prefix: /foo + ... + ``` + + The configuration file after the modification is similar to the following file: + + {{< copyable "" >}} + + ```yaml + monitored: + ... + server_configs: + tidb: ... + tikv: ... + pd: + dashboard.public-path-prefix: /foo + ... + ``` + + Or + + {{< copyable "" >}} + + ```yaml + monitored: + ... + server_configs: + tidb: ... + tikv: ... + pd: + dashboard.public-path-prefix: /foo + ``` + +3. Perform a rolling restart to all PD instances to for the modified configuration to take effect (replace `CLUSTER_NAME` with cluster name): + + {{< copyable "shell-regular" >}} + + ```bash + tiup cluster reload CLUSTER_NAME -R pd + ``` + +See [Common TiUP Operations - Modify the configuration](/maintain-tidb-using-tiup.md#modify-the-configuration) for details. + +If you want that the TiDB Dashboard service is run in the root path (such as `http://example.com/`), use the following configuration: + +{{< copyable "" >}} + +```yaml +server_configs: + pd: + dashboard.public-path-prefix: / +``` + +> **Warning:** +> +> After the modified and customized path prefix takes effect, you cannot directly access TiDB Dashboard. You can only access TiDB Dashboard through a reverse proxy that matches the path prefix. + +### Step 2: Modify the NGINX reverse proxy configuration + +Taking `http://example.com/foo` as an example, the corresponding NGINX configuration is as follows: + +{{< copyable "" >}} + +```nginx +server { + listen 80; + location /foo/ { + proxy_pass http://192.168.0.123:2379/dashboard/; + } +} +``` + +> **Warning:** +> +> Keep the `/dashboard/` path in the `proxy_pass` directive to ensure that only the services under this path are reverse proxied. Otherwise, security risks will be introduced. See [Improve TiDB Dashboard Security](/dashboard/dashboard-ops-security.md). + +Change `http://192.168.0.123:2379/dashboard/` in the configuration to the actual address of the TiDB Dashboard obtained in [Step 1: Get the actual TiDB Dashboard address](#step-1-get-the-actual-tidb-dashboard-address). + +If you want that the TiDB Dashboard service is run in the root path (such as `http://example.com/`), use the following configuration: + +{{< copyable "" >}} + +```nginx +server { + listen 80; + location / { + proxy_pass http://192.168.0.123:2379/dashboard/; + } +} +``` + +Modify the configuration and restart NGINX for the modified configuration to take effect. From c87e5b19e1b9f15d2aac947e583c2ef2a03fb776 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 9 Jun 2020 13:41:04 +0800 Subject: [PATCH 03/10] Apply suggestions from code review Co-authored-by: Ran --- dashboard/dashboard-ops-deploy.md | 12 ++++++------ dashboard/dashboard-ops-security.md | 4 ++-- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index 08e31257d2d4d..6d1b306c5845d 100644 --- a/dashboard/dashboard-ops-deploy.md +++ b/dashboard/dashboard-ops-deploy.md @@ -5,9 +5,9 @@ category: how-to # Deploy TiDB Dashboard -The TiDB Dashboard interface is built into the PD component of TiDB v4.0 or higher, and no additional deployment is required. You can just deploy a standard TiDB cluster and TiDB Dashboard is be integrated natively. +The TiDB Dashboard interface is built into the PD component of TiDB v4.0 or higher, and no additional deployment is required. You can just deploy a standard TiDB cluster, and TiDB Dashboard is integrated natively. -See to the following documents to learn how to deploy a standard TiDB cluster: +See the following documents to learn how to deploy a standard TiDB cluster: + [Quick Start Guide for the TiDB Database Platform](/quick-start-with-tidb.md#deploy-a-local-test-environment-using-tiup-playground) + [Deploy TiDB in Production Environment](/production-deployment-using-tiup.md) @@ -83,7 +83,7 @@ tiup cluster display CLUSTER_NAME --dashboard > **Warning:** > -> If you change the instance to run TiDB Dashboard, the local data stored in the previous TiDB Dashboard instance will be lost, including the traffic visualization history and historical search records. +> If you change the instance to run TiDB Dashboard, the local data stored in the previous TiDB Dashboard instance will be lost, including the traffic visualization history and search history. ## Disable TiDB Dashboard @@ -129,10 +129,10 @@ You can also re-enable TiDB Dashboard by manually specifying which PD instance p > **Warning:** > -> If the newly enabled TiDB Dashboard instance is inconsistent with the previous instance that provides the TiDB Dashboard service, the local data stored in the previous TiDB Dashboard instance will be lost, including traffic visualization history and historical search records. +> If the newly enabled TiDB Dashboard instance is inconsistent with the previous instance that provides the TiDB Dashboard service, the local data stored in the previous TiDB Dashboard instance will be lost, including traffic visualization history and search history. -## Next +## What's next -- See [Access TiDB Dashboard](/dashboard/dashboard-access.md) to learn how to access and sign into the TiDB Dashboard interface. +- See [Access TiDB Dashboard](/dashboard/dashboard-access.md) to learn how to access and log into the TiDB Dashboard interface. - See [Improve TiDB Dashboard Security](/dashboard/dashboard-ops-security.md) to learn how to enhance the security of TiDB Dashboard, such as configuring a firewall. diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md index cc31c70866dd1..838e0bc47d001 100644 --- a/dashboard/dashboard-ops-security.md +++ b/dashboard/dashboard-ops-security.md @@ -10,7 +10,7 @@ Although you need to sign into TiDB Dashboard before accessing it, TiDB Dashboar ## Set a strong password for TiDB `root` user -The account system of TiDB Dashboard is consistent with that of TiDB SQL users. By default, TiDB's `root` user has no password, so accessing TiDB Dashboard does not require password authentication, which will give the malicious visitor great privileges, including executing privileged SQL statements. +The account system of TiDB Dashboard is consistent with that of TiDB SQL users. By default, TiDB's `root` user has no password, so accessing TiDB Dashboard does not require password authentication, which will give the malicious visitor high privileges, including executing privileged SQL statements. It is recommended that you set a strong password for TiDB `root` user. See [TiDB User Account Management](/user-account-management.md) for details. @@ -38,7 +38,7 @@ In the test environment, you might need to configure the firewall to open the Ti When multiple PD instances are deployed, only one of the PD instances actually runs TiDB Dashboard, and browser redirection occurs when you access other PD instances. Therefore, you need to ensure that the firewall is configured with the correct IP address. For details of this mechanism, see [Deployment with multiple PD instances](/dashboard/dashboard-ops-deploy.md#deployment-with-multiple-pd-instances). -When using the TiUP deployment tool, you can use the following command to view the address of the PD instance that actually runs TiDB Dashboard (replace `CLUSTER_NAME` with the cluster name): +When using the TiUP deployment tool, you can view the address of the PD instance that actually runs TiDB Dashboard by running the following command (replace `CLUSTER_NAME` with the cluster name): {{< copyable "shell-regular" >}} From 18d3505f2cfc7088202e53b59f3cf0b1293e1514 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 9 Jun 2020 15:02:44 +0800 Subject: [PATCH 04/10] update access dashboard --- dashboard/dashboard-access.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/dashboard/dashboard-access.md b/dashboard/dashboard-access.md index b380b5244b915..cf1c904226103 100644 --- a/dashboard/dashboard-access.md +++ b/dashboard/dashboard-access.md @@ -8,9 +8,11 @@ category: how-to To access TiDB Dashboard, visit via your browser. Replace `127.0.0.1:2379` with the actual PD instance address and port. +If multiple PD instances are deployed in your cluster and you can directly access **every** PD instance and port, you can simply replace `127.0.0.1:2379` in the address with **any** PD instance address and port. + > **Note:** > -> If you have deployed multiple PD components in your cluster, you can use the address of only one PD component to access TiDB Dashboard, because the Dashboard operates on only one PD component. If you access via other PD components, your browser is redirected to that PD component. Therefore, if the firewall is not configured for this instance on which PD operates, you might not be able to access TiDB Dashboard. +> If a firewall or reverse proxy is configured and you cannot directly access every PD instance, you might not be able to access TiDB Dashboard. Usually, this is because the firewall or reverse proxy is not correctly configured. See [Use TiDB Dashboard behind Reverse Proxy](/dashboard/dashboard-ops-reverse-proxy.md) and [Secure TiDB Dashboard](/dashboard/dashboard-ops-security.md) to learn correctly configure the firewall or reverse proxy when multiple PD instances are deployed. ## Browser compatibility From a9a6bc8a000a933a5c649ecc3b1b15aa8c76f360 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 9 Jun 2020 15:35:34 +0800 Subject: [PATCH 05/10] address comments from breeswish --- dashboard/dashboard-faq.md | 22 ++++++++-------- dashboard/dashboard-intro.md | 2 +- dashboard/dashboard-ops-deploy.md | 32 ++++++++++++------------ dashboard/dashboard-ops-reverse-proxy.md | 6 ++--- dashboard/dashboard-ops-security.md | 4 +-- 5 files changed, 33 insertions(+), 33 deletions(-) diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index 901f7b45ac28f..d719266c30e78 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -8,7 +8,7 @@ category: how-to This document summarizes the frequently asked questions (FAQs) and answers about TiDB Dashboard. -## Access TiDB Dashboard +## Access-related FAQ ### When the firewall or reverse proxy is configured, I am redirected to an internal address other than TiDB Dashboard @@ -18,19 +18,19 @@ When multiple PD instances are deployed in a cluster, only one of the PD instanc - See [Use TiDB Dashboard through Reverse Proxy](/dashboard/dashboard-ops-reverse-proxy.md) to learn how to correctly configure reverse proxy. - See [Improve TiDB Dashboard Security](/dashboard/dashboard-ops-security.md) to learn how to correctly configure the firewall. -### When dual network cards are deployed, TiDB Dashboard cannot be accessed using another network card +### When TiDB Dashboard is deployed with dual network interface cards (NICs), TiDB Dashboard cannot be accessed using another NIC -For security reasons, TiDB Dashboard on PD only monitors the IP addresses specified during deployment (that is, it only listens on one network card), nsot on `0.0.0.0`. Therefore, when multiple network cards are installed on the host, you cannot access TiDB Dashboard using another network card. +For security reasons, TiDB Dashboard on PD only monitors the IP addresses specified during deployment (that is, it only listens on one NIC), not on `0.0.0.0`. Therefore, when multiple NICs are installed on the host, you cannot access TiDB Dashboard using another NIC. -If you have deployed TiDB using the `tiup cluster` or `tiup playground` command, currently this problem cannot be solved. It is recommended that you use a reverse proxy to safely expose TiDB Dashboard to another network card. For details, see [Use TiDB Dashboard through Reverse Proxy](/dashboard/dashboard-ops-reverse-proxy.md). +If you have deployed TiDB using the `tiup cluster` or `tiup playground` command, currently this problem cannot be solved. It is recommended that you use a reverse proxy to safely expose TiDB Dashboard to another NIC. For details, see [Use TiDB Dashboard through Reverse Proxy](/dashboard/dashboard-ops-reverse-proxy.md). -## Interface feature +## UI-related FAQ ### `prometheus_not_found` error is shown in **QPS** and **Latency** sections on the Overview page -Monitoring metrics in **QPS** and **Latency** sections on the **Overview** page rely on the Prometheus monitoring instance that should have been deployed properly in the cluster. Errors are shown if Prometheus is not deployed. You can address this problem by deploying new Prometheus instance in the cluster. +The **QPS** and **Latency** sections on the **Overview** page require a cluster with Prometheus deployed. Otherwise, the error is shown. You can solve this problem by deploying a Prometheus instance in the cluster. -If the Prometheus monitoring instance has been deployed but this error persists, the possible reason is that the version of your deployment tool (TiUP, TiDB Operator or TiDB Ansible) is old, and this tool does report monitoring addresses automatically, which makes TiDB Dashboard unable to perceive and query monitoring data. You can upgrade you deployment tool to the latest version and try again. +If you still encounter this problem when the Prometheus instance has been deployed, the possible reason is that your deployment tool is out of date (TiUP, TiDB Operator, or TiDB Ansible), and your tool does not automatically report metrics addresses, which makes TiDB Dashboard unable to query metrics. You can upgrade you deployment tool to the latest version and try again. If your deployment tool is TiUP, take the following steps to solve this problem. For other deployment tools, refer to the corresponding documents of those tools. @@ -43,9 +43,9 @@ If your deployment tool is TiUP, take the following steps to solve this problem. tiup update cluster --force ``` -2. After the upgrade, when a new cluster is deployed with monitoring nodes, the monitoring metrics can be shown normally. +2. After the upgrade, when a new cluster is deployed with Prometheus instances, the metrics can be displayed normally. -3. For an existing cluster, you can restart this cluster to report the monitoring addresses. Replace `CLUSTER_NAME` with the actual cluster name: +3. For an existing cluster, you can restart this cluster to report the metrics addresses. Replace `CLUSTER_NAME` with the actual cluster name: {{< copyable "shell-regular" >}} @@ -53,8 +53,8 @@ If your deployment tool is TiUP, take the following steps to solve this problem. tiup cluster start CLUSTER_NAME ``` - Even if the cluster has been started, still execute this command. This command does not affect the normal application in the cluster, but refreshes and reports the monitoring addresses, so that the monitoring metrics can be shown normally in TiDB Dashboard. + Even if the cluster has been started, still execute this command. This command does not affect the normal application in the cluster, but refreshes and reports the metrics addresses, so that the monitoring metrics can be displayed normally in TiDB Dashboard. ### `invalid connection` error is shown in **Top SQL Statements** and **Recent Slow Queries** on the Overview page -The possible reason is that you have enabled the `prepared-plan-cache` feature of TiDB. As an experimental feature, `prepared-plan-cache` might not function properly in some TiDB versions, which might cause this problem in TiDB Dashboard (and other applications) after being enabled. Disable `prepared-plan-cache` in [TiDB Configuration file](/tidb-configuration-file.md#prepared-plan-cache). \ No newline at end of file +The possible reason is that you have enabled the `prepared-plan-cache` feature of TiDB. As an experimental feature, when enabled, `prepared-plan-cache` might not function properly in specific TiDB versions, which could cause this problem in TiDB Dashboard (and other applications). You can disable `prepared-plan-cache` by updating [TiDB Configuration file](/tidb-configuration-file.md#prepared-plan-cache) to solve this problem. \ No newline at end of file diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md index 9dd1bb80e1588..d48010a18c1c9 100644 --- a/dashboard/dashboard-intro.md +++ b/dashboard/dashboard-intro.md @@ -6,7 +6,7 @@ category: how-to # TiDB Dashboard Introduction -TiDB Dashboard is a graphical interface provided by TiDB since v4.0, which is used to monitor and diagnose TiDB clusters. TiDB Dashboard is built into the PD component of TiDB and does not require independent deployment. +TiDB Dashboard is a Web UI for monitoring, diagnosing, and managing the TiDB cluster, which is available since v4.0. It is built into the PD component and does not require an independent deployment. ![TiDB Dashboard interface](/media/dashboard/dashboard-intro.gif) diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index 6d1b306c5845d..da22310dad414 100644 --- a/dashboard/dashboard-ops-deploy.md +++ b/dashboard/dashboard-ops-deploy.md @@ -5,7 +5,7 @@ category: how-to # Deploy TiDB Dashboard -The TiDB Dashboard interface is built into the PD component of TiDB v4.0 or higher, and no additional deployment is required. You can just deploy a standard TiDB cluster, and TiDB Dashboard is integrated natively. +The TiDB Dashboard UI is built into the PD component for v4.0 or higher versions, and no additional deployment is required. Simply deploy a standard TiDB cluster, and TiDB Dashboard will be there. See the following documents to learn how to deploy a standard TiDB cluster: @@ -19,21 +19,21 @@ See the following documents to learn how to deploy a standard TiDB cluster: ## Deployment with multiple PD instances -When multiple PD instances are deployed in the cluster, only one of these instances provides the TiDB Dashboard service. +When multiple PD instances are deployed in the cluster, only one of these instances serves the TiDB Dashboard. -PD instances, when running for the first time, automatically negotiate with each other and choose one instance to provide the TiDB Dashboard service. After the negotiation is completed, the TiDB Dashboard service will always run on the chosen instance no matter it is restarted or scaled out, unless this instance is manually scaled in. TiDB Dashboard will not run on other PD instances. This negotiation process can be completed automatically without user intervention. +When PD instances are running for the first time, they automatically negotiate with each other to choose one instance to serve the TiDB Dashboard. TiDB Dashboard will not run on other PD instances. The TiDB Dashboard service will be always run on the chosen PD instance no matter PD instances are restarted or new PD instances are joined. However there will be a re-negotiation when the PD instance that serves TiDB Dashboard is removed from the cluster (scaled-in). The negotiation process does not need user intervention. -When you access a PD instance that does not provide the TiDB Dashboard service, the browser receives a redirection instruction and automatically guides you to re-access the PD instance that provides the TiDB Dashboard service, so that you can use the service normally. This process is shown in the image below. +When you access a PD instance that does not serve TiDB Dashboard, the browser will be redirected automatically to guide you to access the PD instance that serves the TiDB Dashboard, so that you can access the service normally. This process is illustrated in the image below. ![Process Schematic](/media/dashboard/dashboard-ops-multiple-pd.png) > **Note:** > -> The PD instance that provides the TiDB Dashboard service might not be consistent with the PD leader. +> The PD instance that serves TiDB Dashboard might not be a PD leader. -### Check the PD instance that actually provides the TiDB Dashboard service +### Check the PD instance that actually serves TiDB Dashboard -If a started cluster is deployed using TiUP, you can use the `tiup cluster display` command to check which PD node provides the TiDB Dashboard service. Replace `CLUSTER_NAME` with the cluster name. +For a running cluster deployed using TiUP, you can use the `tiup cluster display` command to see which PD instance serves TiDB Dashboard. Replace `CLUSTER_NAME` with the cluster name. {{< copyable "shell-regular" >}} @@ -58,9 +58,9 @@ http://192.168.0.123:2379/dashboard/ > tiup update cluster --force > ``` -### Switch to another PD instance to provide TiDB Dashboard service +### Switch to another PD instance to serve TiDB Dashboard -If a started cluster is deployed using TiUP, you can use the `tiup ctl pd` command to change the PD instance that provides the TiDB Dashboard service, or re-specify a PD instance to provide the TiDB Dashboard service with TiDB Dashboard disabled: +For a running cluster deployed using TiUP, you can use the `tiup ctl pd` command to change the PD instance that serves TiDB Dashboard, or re-specify a PD instance to serve TiDB Dashboard when it is disabled: {{< copyable "shell-regular" >}} @@ -73,7 +73,7 @@ In the command above: - Replace `127.0.0.1:2379` with the IP and port of any PD instance. - Replace `9.9.9.9:2379` with the IP and port of the new PD instance that you desire to run the TiDB Dashboard service. -After the modification above, you can use the `tiup cluster display` command to confirm whether the modification takes effect (replace `CLUSTER_NAME` with the cluster name): +You can use the `tiup cluster display` command to see whether the modification is taking effect (replace `CLUSTER_NAME` with the cluster name): {{< copyable "shell-regular" >}} @@ -83,11 +83,11 @@ tiup cluster display CLUSTER_NAME --dashboard > **Warning:** > -> If you change the instance to run TiDB Dashboard, the local data stored in the previous TiDB Dashboard instance will be lost, including the traffic visualization history and search history. +> If you change the instance to run TiDB Dashboard, the local data stored in the previous TiDB Dashboard instance will be lost, including the Key Visualize history and search history. ## Disable TiDB Dashboard -If a started cluster is deployed using TiUP, use the `tiup ctl pd` command to disable TiDB Dashboard on all PD instances (replace `127.0.0.1:2379` with the IP and port of any PD instance): +For a running cluster deployed using TiUP, use the `tiup ctl pd` command to disable TiDB Dashboard on all PD instances (replace `127.0.0.1:2379` with the IP and port of any PD instance): {{< copyable "shell-regular" >}} @@ -109,7 +109,7 @@ Dashboard is not started. ## Re-enable TiDB Dashboard -If a started cluster is deployed using TiUP, use the `tiup ctl pd` command to request PD to renegotiate an instance to run TiDB Dashboard (replace `127.0.0.1:2379` with the IP and port of any PD instance) : +For a running cluster deployed using TiUP, use the `tiup ctl pd` command to request PD to renegotiate an instance to run TiDB Dashboard (replace `127.0.0.1:2379` with the IP and port of any PD instance): {{< copyable "shell-regular" >}} @@ -117,7 +117,7 @@ If a started cluster is deployed using TiUP, use the `tiup ctl pd` command to re tiup ctl pd -u http://127.0.0.1:2379 config set dashboard-address auto ``` -After executing the command above, use the `tiup cluster display` command to view the TiDB Dashboard instance address automatically negotiated by PD (replace `CLUSTER_NAME` with the cluster name): +After executing the command above, you can use the `tiup cluster display` command to view the TiDB Dashboard instance address automatically negotiated by PD (replace `CLUSTER_NAME` with the cluster name): {{< copyable "shell-regular" >}} @@ -125,11 +125,11 @@ After executing the command above, use the `tiup cluster display` command to vie tiup cluster display CLUSTER_NAME --dashboard ``` -You can also re-enable TiDB Dashboard by manually specifying which PD instance provides the TiDB Dashboard service. For specific operations, see [Switch to another PD instance to provide TiDB Dashboard service](#switch-to-another-pd-instance-to-provide-tidb-dashboard-service). +You can also re-enable TiDB Dashboard by manually specifying the PD instance that serves TiDB Dashboard. See [Switch to another PD instance to serve TiDB Dashboard](#switch-to-another-pd-instance-to-serve-tidb-dashboard). > **Warning:** > -> If the newly enabled TiDB Dashboard instance is inconsistent with the previous instance that provides the TiDB Dashboard service, the local data stored in the previous TiDB Dashboard instance will be lost, including traffic visualization history and search history. +> If the newly enabled TiDB Dashboard instance is different with the previous instance that served the TiDB Dashboard, the local data stored in the previous TiDB Dashboard instance will be lost, including Key Visualize history and search history. ## What's next diff --git a/dashboard/dashboard-ops-reverse-proxy.md b/dashboard/dashboard-ops-reverse-proxy.md index 3899d01af7805..f53472b5ca03a 100644 --- a/dashboard/dashboard-ops-reverse-proxy.md +++ b/dashboard/dashboard-ops-reverse-proxy.md @@ -1,11 +1,11 @@ --- -title: Use TiDB Dashboard Through Reverse Proxy +title: Use TiDB Dashboard behind a Reverse Proxy category: how-to --- -# Use TiDB Dashboard Through Reverse Proxy +# Use TiDB Dashboard behind a Reverse Proxy -You can use a reverse proxy to safely provide the TiDB Dashboard service from the internal network to the external network. +You can use a reverse proxy to safely expose the TiDB Dashboard service from the internal network to the external. ## Use NGINX reverse proxy diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md index 838e0bc47d001..b7c3660d841e6 100644 --- a/dashboard/dashboard-ops-security.md +++ b/dashboard/dashboard-ops-security.md @@ -1,10 +1,10 @@ --- -title: Improve TiDB Dashboard Security +title: Secure TiDB Dashboard summary: Learn how to improve the security of TiDB Dashboard. category: how-to --- -# Improve TiDB Dashboard Security +# Secure TiDB Dashboard Although you need to sign into TiDB Dashboard before accessing it, TiDB Dashboard is designed to be accessed by trusted user entities by default. When you want to provide TiDB Dashboard to external network users or untrusted users for access, take the following measures to avoid security vulnerabilities. From b04b34e84cf8f013c872e6f881f85f478461f844 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 9 Jun 2020 15:40:25 +0800 Subject: [PATCH 06/10] address comments from cc Co-authored-by: Caitin <34535727+CaitinChen@users.noreply.github.com> --- dashboard/dashboard-intro.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md index d48010a18c1c9..cff78b752f7d1 100644 --- a/dashboard/dashboard-intro.md +++ b/dashboard/dashboard-intro.md @@ -16,17 +16,17 @@ This document introduces the main features of TiDB Dashboard. You can click link ## Show the overall running status of TiDB cluster -You can use TiDB Dashboard to learn the TiDB cluster's queries per second (QPS), execution duration, the SQL types that consume the most resources, and other overview information. +You can use TiDB Dashboard to learn the TiDB cluster's queries per second (QPS), execution time, the types of SQL statements that consume the most resources, and other overview information. See [TiDB Dashboard Overview](/dashboard/dashboard-overview.md) for details. -## Show the running status of components and host +## Show the running status of components and hosts You can use TiDB Dashboard to view the running status of TiDB, TiKV, PD, TiFlash components in the entire cluster and the running status of the host on which these components are located. See [TiDB Dashboard Cluster Information Page](/dashboard/dashboard-cluster-info.md) for details. -## Show distribution and trend of read and write traffic +## Show distribution and trends of read and write traffic The Key Visualizer feature of TiDB Dashboard visually shows the change of read and write traffic over time in the entire cluster in the form of heatmap. You can use this feature to timely discover changes of application modes or locate hotspot issues with uneven performance. @@ -34,30 +34,30 @@ See [Key Visualizer Page](/dashboard/dashboard-key-visualizer.md) for details. ## Show a list of execution information of all SQL statements -The execution information of all SQL statements is listed on the SQL Statements page. You can use this page to learn the execution duration and total execution times at all stages, which helps you analyze and locate the SQL queries that consume the most resource and improve the overall cluster performance. +The execution information of all SQL statements is listed on the SQL Statements page. You can use this page to learn the execution time and total executions at all stages, which helps you analyze and locate the SQL queries that consume the most resources and improve the overall cluster performance. See [SQL Statements Page of TiDB Dashboard](/dashboard/dashboard-statement-list.md) for details. ## Learn the detailed execution information of slow queries -The Slow Queries page of TiDB Dashboard shows a list of all SQL statements that take a long time to execute, including the SQL texts and execution information. This page helps you locate the cause of slow SQL performance or performance jitter. +The Slow Queries page of TiDB Dashboard shows a list of all SQL statements that take a long time to execute, including the SQL texts and execution information. This page helps you locate the cause of slow queries or performance jitter. See [Slow Queries Page](/dashboard/dashboard-slow-query.md) for details. ## Diagnose common cluster problems and generate reports -The diagnostic feature of TiDB Dashboard automatically determines whether some common risks (such as inconsistent configurations) or problems exist in the cluster, generates reports and gives operation suggestions, or compares the status of each cluster metric in different time ranges for you to analyze the possible problems. +The diagnostic feature of TiDB Dashboard automatically determines whether some common risks (such as inconsistent configurations) or problems exist in the cluster, generates reports, and gives operation suggestions, or compares the status of each cluster metric in different time ranges for you to analyze possible problems. See [TiDB Dashboard Cluster Diagnostics Page](/dashboard/dashboard-diagnostics-access.md) for details. ## Query logs of all components -On the Search Logs page of TiDB Dashboard, you can quickly search logs of all running instances in the cluster by keywords, time range, and other conditions, and download these logs to your local. +On the Search Logs page of TiDB Dashboard, you can quickly search logs of all running instances in the cluster by keywords, time range, and other conditions, package these logs, and download them to your local machine. -See [Search Logs Page](/dashboard/dashboard-log-search.md) for details。 +See [Search Logs Page](/dashboard/dashboard-log-search.md) for details. -## Collect performance data of each component +## Collect profiling data for each instance -Advanced debugging feature: Profiles each component online, and analyze internal operations (executed during the analysis period) and proportions of component instances without a third-party tools. +This is an advanced debugging feature that lets you profile each instance online and analyze various internal operations an instance performed during the profiling data collection period and the proportion of the operation execution time in this period without third-party tools. See [Profile Instances Page](/dashboard/dashboard-profiling.md) for details. From fbc0eb9e0bfcdb4ec0559132a796e6f69be0236c Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 9 Jun 2020 15:41:22 +0800 Subject: [PATCH 07/10] Apply suggestions from code review Co-authored-by: Caitin <34535727+CaitinChen@users.noreply.github.com> --- dashboard/dashboard-faq.md | 8 ++++---- dashboard/dashboard-intro.md | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index d719266c30e78..f7e3cf3432d1a 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -15,7 +15,7 @@ This document summarizes the frequently asked questions (FAQs) and answers about When multiple PD instances are deployed in a cluster, only one of the PD instances actually runs the TiDB Dashboard service. If you access other PD instances than this Dashboard-running one, your browser redirects you to another address. If the firewall or reverse proxy is not properly configured for accessing TiDB Dashboard, after the visiting the Dashboard, you might be redirected to an internal address that is protected by the firewall or reverse proxy. - See [TiDB Dashboard Multi-PD Instance Deployment](/dashboard/dashboard-ops-deploy.md#) to learn the working principle of TiDB Dashboard with multiple PD instances. -- See [Use TiDB Dashboard through Reverse Proxy](/dashboard/dashboard-ops-reverse-proxy.md) to learn how to correctly configure reverse proxy. +- See [Use TiDB Dashboard through a Reverse Proxy](/dashboard/dashboard-ops-reverse-proxy.md) to learn how to correctly configure a reverse proxy. - See [Improve TiDB Dashboard Security](/dashboard/dashboard-ops-security.md) to learn how to correctly configure the firewall. ### When TiDB Dashboard is deployed with dual network interface cards (NICs), TiDB Dashboard cannot be accessed using another NIC @@ -26,7 +26,7 @@ If you have deployed TiDB using the `tiup cluster` or `tiup playground` command, ## UI-related FAQ -### `prometheus_not_found` error is shown in **QPS** and **Latency** sections on the Overview page +### A `prometheus_not_found` error is shown in **QPS** and **Latency** sections on the Overview page The **QPS** and **Latency** sections on the **Overview** page require a cluster with Prometheus deployed. Otherwise, the error is shown. You can solve this problem by deploying a Prometheus instance in the cluster. @@ -55,6 +55,6 @@ If your deployment tool is TiUP, take the following steps to solve this problem. Even if the cluster has been started, still execute this command. This command does not affect the normal application in the cluster, but refreshes and reports the metrics addresses, so that the monitoring metrics can be displayed normally in TiDB Dashboard. -### `invalid connection` error is shown in **Top SQL Statements** and **Recent Slow Queries** on the Overview page +### An `invalid connection` error is shown in **Top SQL Statements** and **Recent Slow Queries** on the Overview page -The possible reason is that you have enabled the `prepared-plan-cache` feature of TiDB. As an experimental feature, when enabled, `prepared-plan-cache` might not function properly in specific TiDB versions, which could cause this problem in TiDB Dashboard (and other applications). You can disable `prepared-plan-cache` by updating [TiDB Configuration file](/tidb-configuration-file.md#prepared-plan-cache) to solve this problem. \ No newline at end of file +The possible reason is that you have enabled the `prepared-plan-cache` feature of TiDB. As an experimental feature, when enabled, `prepared-plan-cache` might not function properly in specific TiDB versions, which could cause this problem in TiDB Dashboard (and other applications). You can disable `prepared-plan-cache` by updating [TiDB Configuration file](/tidb-configuration-file.md#prepared-plan-cache) to solve this problem. diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md index cff78b752f7d1..de237d7a1ac02 100644 --- a/dashboard/dashboard-intro.md +++ b/dashboard/dashboard-intro.md @@ -10,11 +10,11 @@ TiDB Dashboard is a Web UI for monitoring, diagnosing, and managing the TiDB clu ![TiDB Dashboard interface](/media/dashboard/dashboard-intro.gif) -TiDB Dashboard is open-sourced on [Github](https://github.com/pingcap-incubator/tidb-dashboard). +TiDB Dashboard is open-sourced on [GitHub](https://github.com/pingcap-incubator/tidb-dashboard). This document introduces the main features of TiDB Dashboard. You can click links in the following sections to learn more details. -## Show the overall running status of TiDB cluster +## Show the overall running status of the TiDB cluster You can use TiDB Dashboard to learn the TiDB cluster's queries per second (QPS), execution time, the types of SQL statements that consume the most resources, and other overview information. From 8cd38e69f8660fde9225b0be7a31bfe2752946ca Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 9 Jun 2020 22:20:57 +0800 Subject: [PATCH 08/10] Apply suggestions from code review Co-authored-by: Caitin <34535727+CaitinChen@users.noreply.github.com> Co-authored-by: Ran --- dashboard/dashboard-faq.md | 2 +- dashboard/dashboard-ops-deploy.md | 7 ++++--- dashboard/dashboard-ops-security.md | 2 +- 3 files changed, 6 insertions(+), 5 deletions(-) diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index f7e3cf3432d1a..aa6edbf3f3186 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -12,7 +12,7 @@ This document summarizes the frequently asked questions (FAQs) and answers about ### When the firewall or reverse proxy is configured, I am redirected to an internal address other than TiDB Dashboard -When multiple PD instances are deployed in a cluster, only one of the PD instances actually runs the TiDB Dashboard service. If you access other PD instances than this Dashboard-running one, your browser redirects you to another address. If the firewall or reverse proxy is not properly configured for accessing TiDB Dashboard, after the visiting the Dashboard, you might be redirected to an internal address that is protected by the firewall or reverse proxy. +When multiple Placement Driver (PD) instances are deployed in a cluster, only one of the PD instances actually runs the TiDB Dashboard service. If you access other PD instances instead of this one, your browser redirects you to another address. If the firewall or reverse proxy is not properly configured for accessing TiDB Dashboard, when you visit the Dashboard, you might be redirected to an internal address that is protected by the firewall or reverse proxy. - See [TiDB Dashboard Multi-PD Instance Deployment](/dashboard/dashboard-ops-deploy.md#) to learn the working principle of TiDB Dashboard with multiple PD instances. - See [Use TiDB Dashboard through a Reverse Proxy](/dashboard/dashboard-ops-reverse-proxy.md) to learn how to correctly configure a reverse proxy. diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index da22310dad414..0c7686a282b1b 100644 --- a/dashboard/dashboard-ops-deploy.md +++ b/dashboard/dashboard-ops-deploy.md @@ -1,5 +1,6 @@ --- title: Deploy TiDB Dashboard +summary: Learn how to deploy TiDB Dashboard. category: how-to --- @@ -21,7 +22,7 @@ See the following documents to learn how to deploy a standard TiDB cluster: When multiple PD instances are deployed in the cluster, only one of these instances serves the TiDB Dashboard. -When PD instances are running for the first time, they automatically negotiate with each other to choose one instance to serve the TiDB Dashboard. TiDB Dashboard will not run on other PD instances. The TiDB Dashboard service will be always run on the chosen PD instance no matter PD instances are restarted or new PD instances are joined. However there will be a re-negotiation when the PD instance that serves TiDB Dashboard is removed from the cluster (scaled-in). The negotiation process does not need user intervention. +When PD instances are running for the first time, they automatically negotiate with each other to choose one instance to serve the TiDB Dashboard. TiDB Dashboard will not run on other PD instances. The TiDB Dashboard service will always be provided by the chosen PD instance no matter PD instances are restarted or new PD instances are joined. However, there will be a re-negotiation when the PD instance that serves TiDB Dashboard is removed from the cluster (scaled-in). The negotiation process does not need user intervention. When you access a PD instance that does not serve TiDB Dashboard, the browser will be redirected automatically to guide you to access the PD instance that serves the TiDB Dashboard, so that you can access the service normally. This process is illustrated in the image below. @@ -133,6 +134,6 @@ You can also re-enable TiDB Dashboard by manually specifying the PD instance tha ## What's next -- See [Access TiDB Dashboard](/dashboard/dashboard-access.md) to learn how to access and log into the TiDB Dashboard interface. +- To learn how to access and log into the TiDB Dashboard UI, see [Access TiDB Dashboard](/dashboard/dashboard-access.md). -- See [Improve TiDB Dashboard Security](/dashboard/dashboard-ops-security.md) to learn how to enhance the security of TiDB Dashboard, such as configuring a firewall. +- To learn how to enhance the security of TiDB Dashboard, such as configuring a firewall, see [Improve TiDB Dashboard Security](/dashboard/dashboard-ops-security.md). diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md index b7c3660d841e6..aefb027955d15 100644 --- a/dashboard/dashboard-ops-security.md +++ b/dashboard/dashboard-ops-security.md @@ -69,7 +69,7 @@ In this example, the firewall needs to be configured with inbound access for the ## Reverse proxy only for TiDB Dashboard -As mentioned in [Use a firewall to block untrusted access](#use-a-firewall-to-block-untrusted access), the services provided under the PD client port include not only TiDB Dashboard (located at ), but also other privileged interfaces in PD (such as ). Therefore, when using a reverse proxy to provide TiDB Dashboard to the external network, ensure that the services **ONLY** with the `/dashboard` prefix are provided (**NOT** all services under the port) to avoid that the external network can access the privileged interface in PD through the reverse proxy . +As mentioned in [Use a firewall to block untrusted access](#use-a-firewall-to-block-untrusted access), the services provided under the PD client port include not only TiDB Dashboard (located at ), but also other privileged interfaces in PD (such as ). Therefore, when using a reverse proxy to provide TiDB Dashboard to the external network, ensure that the services **ONLY** with the `/dashboard` prefix are provided (**NOT** all services under the port) to avoid that the external network can access the privileged interface in PD through the reverse proxy. It is recommended that you see [Use TiDB Dashboard through Reverse Proxy](/dashboard/dashboard-ops-reverse-proxy.md) to learn a safe and recommended reverse proxy configuration. From 0f0cd79f2552ad8dc47fc2c95aca3e28f28df3d7 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 9 Jun 2020 22:30:58 +0800 Subject: [PATCH 09/10] Update dashboard/dashboard-ops-security.md --- dashboard/dashboard-ops-security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md index aefb027955d15..46ec762c268be 100644 --- a/dashboard/dashboard-ops-security.md +++ b/dashboard/dashboard-ops-security.md @@ -76,4 +76,4 @@ It is recommended that you see [Use TiDB Dashboard through Reverse Proxy](/dashb ## Other recommended safety measures - [Enable TLS Authentication and Encrypt the Stored Data](/enable-tls-between-components.md) -- [Enable encrypted transmission for communication between TiDB client servers](/encrypted-connections-with-tls-protocols.md) +- [Enable TLS Between TiDB Clients and Servers](/enable-tls-between-clients-and-servers.md) From 910f71db21a4880c7996d85e5b5e52bb8a5deb53 Mon Sep 17 00:00:00 2001 From: yikeke Date: Wed, 10 Jun 2020 11:24:34 +0800 Subject: [PATCH 10/10] Update dashboard-ops-reverse-proxy.md --- dashboard/dashboard-ops-reverse-proxy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/dashboard/dashboard-ops-reverse-proxy.md b/dashboard/dashboard-ops-reverse-proxy.md index f53472b5ca03a..ad87fe9d8e1b0 100644 --- a/dashboard/dashboard-ops-reverse-proxy.md +++ b/dashboard/dashboard-ops-reverse-proxy.md @@ -13,7 +13,7 @@ You can use a reverse proxy to safely expose the TiDB Dashboard service from the When multiple PD instances are deployed in the cluster, only one of the PD instances actually runs TiDB Dashboard. Therefore, you need to ensure that the upstream of the reverse proxy points to the correct address. For details of this mechanism, see [Deployment with multiple PD instances](/dashboard/dashboard-ops-deploy.md#deployment-with-multiple-pd-instances). -When you use the TiUP deployment tool, execute the following command to get the actual TiDB Dashboard address (replace `CLUSTER_NAME` with the cluster name): +When you use the TiUP tool for deployment, execute the following command to get the actual TiDB Dashboard address (replace `CLUSTER_NAME` with your cluster name): {{< copyable "shell-regular" >}} @@ -55,11 +55,11 @@ When you use [NGINX](https://nginx.org/) as the reverse proxy, take the followin } ``` - Configure the URL filled in `proxy_pass` to be the actual address of the TiDB Dashboard obtained in [Step 1: Get the actual TiDB Dashboard address](#step-1-get-the-actual-tidb-dashboard-address). + Configure the URL filled in `proxy_pass` to be the actual address of the TiDB Dashboard obtained in [Step 1](#step-1-get-the-actual-tidb-dashboard-address). > **Warning:** > - > Keep the `/dashboard/` path in the `proxy_pass` directive to ensure that only the services under this path are reverse proxied. Otherwise, security risks will be introduced. See [Improve TiDB Dashboard Security](/dashboard/dashboard-ops-security.md). + > You must keep the `/dashboard/` path in the `proxy_pass` directive to ensure that only the services under this path are reverse proxied. Otherwise, security risks will be introduced. See [Improve TiDB Dashboard Security](/dashboard/dashboard-ops-security.md). 2. Restart NGINX for the configuration to take effect. @@ -139,7 +139,7 @@ For a deployed cluster: dashboard.public-path-prefix: /foo ``` -3. Perform a rolling restart to all PD instances to for the modified configuration to take effect (replace `CLUSTER_NAME` with cluster name): +3. Perform a rolling restart to all PD instances for the modified configuration to take effect (replace `CLUSTER_NAME` with your cluster name): {{< copyable "shell-regular" >}}