i18n(ja): fix mistranslations and dropped particles across the dashboard/ directory

dashboard/continuous-profiling.md

@@ -48,7 +48,7 @@ summary: TiDB Dashboardの継続的プロファイリングにより、専門家
 
 > **Note:**
 >
-> 継続的プロファイリングを使用するには、クラスターを最新バージョンのTiUP （v1.9.0以上）またはTiDB Operator （v1.3.0以上）でデプロイまたはアップグレードする必要があります。以前のバージョンのTiUPまたはTiDB Operatorを使用してクラスターをアップグレードした場合は、手順[FAQ](/dashboard/dashboard-faq.md#a-required-component-ngmonitoring-is-not-started-error-is-shown)ご覧ください。
+> 継続的プロファイリングを使用するには、クラスターを最新バージョンのTiUP （v1.9.0以上）またはTiDB Operator （v1.3.0以上）でデプロイまたはアップグレードする必要があります。以前のバージョンのTiUPまたはTiDB Operatorを使用してクラスターをアップグレードした場合は、手順については[FAQ](/dashboard/dashboard-faq.md#a-required-component-ngmonitoring-is-not-started-error-is-shown)をご覧ください。
 
 継続的プロファイリングを有効にすると、Webページを常にアクティブにしておくことなく、バックグラウンドで継続的にパフォーマンスデータを収集できます。収集されたデータは一定期間保存され、期限切れのデータは自動的に削除されます。
 

dashboard/dashboard-access.md

@@ -13,7 +13,7 @@ TiDB Dashboardにアクセスするには、ブラウザから[http://127.0.0.1:
 
 ## 複数のPDインスタンスがデプロイされている場合にTiDB Dashboardにアクセスする {#access-tidb-dashboard-when-multiple-pd-instances-are-deployed}
 
-クラスターに複数の PD インスタンスがデプロイされていて、**すべての**PD インスタンスとポートに直接アクセスできる場合は、アドレス[http://127.0.0.1:2379/dashboard/](http://127.0.0.1:2379/dashboard/)の`127.0.0.1:2379`**任意の**PD インスタンスのアドレスとポートに置き換えるだけです。
+クラスターに複数の PD インスタンスがデプロイされていて、**すべての**PD インスタンスとポートに直接アクセスできる場合は、アドレス[http://127.0.0.1:2379/dashboard/](http://127.0.0.1:2379/dashboard/)の`127.0.0.1:2379`を**任意の**PD インスタンスのアドレスとポートに置き換えるだけです。
 
 > **Note:**
 >
@@ -36,15 +36,15 @@ TiDB Dashboardは、比較的新しいバージョンの次の一般的なデス
 TiDB Dashboardにアクセスすると、ユーザー ログイン インターフェイスに移動します。
 
 - TiDB `root`アカウントを使用して TiDB Dashboardにサインインできます。
-- TiDB Dashboardには、シングルサインオン（SSO）経由でサインインすることもできます。詳細については、 [TiDB DashboardのSSOを構成する](/dashboard/dashboard-session-sso.md)ご覧ください。
+- TiDB Dashboardには、シングルサインオン（SSO）経由でサインインすることもできます。詳細については、 [TiDB DashboardのSSOを構成する](/dashboard/dashboard-session-sso.md)をご覧ください。
 - [ユーザー定義のSQLユーザー](/dashboard/dashboard-user.md)を作成した場合は、このアカウントと対応するパスワードを使用してサインインできます。
 
 次のいずれかの状況が存在する場合、ログインが失敗する可能性があります。
 
 - TiDB `root`ユーザーが存在しません。
 - PD が起動していないか、アクセスできません。
 - TiDB が起動されていないか、アクセスできません。
-- パスワードが`root`間違っています。
+- `root`のパスワードが間違っています。
 
 サインイン後、セッションは24時間有効です。サインアウトの方法については、 [ログアウト](#logout)セクションをご覧ください。
 

dashboard/dashboard-cluster-info.md

@@ -36,15 +36,15 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体
 
 インスタンスは次のいずれかのステータスで実行できます。
 
-- 稼働中: インスタンスは正常に実行されています。
-- ダウンまたは到達不能: インスタンスが実行されていないか、対応するホストにネットワークの問題が発生しています。
-- tombstone: インスタンス上のデータが完全に移行され、スケールインが完了しました。このステータスは、TiKV またはTiFlashインスタンスにのみ存在します。
-- 離脱中: インスタンス上のデータが移行中で、スケールインが進行中です。このステータスは、TiKV またはTiFlashインスタンスでのみ表示されます。
-- 不明: インスタンスの実行状態は不明です。
+- `Up`: インスタンスは正常に実行されています。
+- `Down` または`Unreachable`: インスタンスが実行されていないか、対応するホストにネットワークの問題が発生しています。
+- `Tombstone`: インスタンス上のデータが完全に移行され、スケールインが完了しました。このステータスは、TiKV またはTiFlashインスタンスにのみ存在します。
+- `Leaving`: インスタンス上のデータが移行中で、スケールインが進行中です。このステータスは、TiKV またはTiFlashインスタンスでのみ表示されます。
+- `Unknown`: インスタンスの実行状態は不明です。
 
 > **Note:**
 >
-> - TiDB Dashboardの`Leaving` 、PD API によって返される`Offline` 、およびTiUPの`Pending Offline`同じステータスを示します。
+> - TiDB Dashboardの`Leaving` 、PD API によって返される`Offline` 、およびTiUPの`Pending Offline`は同じステータスを示します。
 > - テーブル内の一部の列は、インスタンスが起動している場合にのみ表示できます。
 
 インスタンスのステータスはPDのスケジュール情報から取得されます。詳細については[情報収集](/tidb-scheduling.md#information-collection)を参照してください。

dashboard/dashboard-diagnostics-access.md

@@ -43,8 +43,8 @@ TiDB Dashboardのクラスタ診断機能は、指定された時間範囲内で
 
 特定の時点でシステム例外が発生した場合（例えば、QPSジッターやレイテンシーの上昇など）、診断レポートを生成できます。このレポートでは、異常な時間帯のシステムと正常な時間帯のシステムを比較します。例えば、
 
-- 異常時間範囲: `2022-05-21 14:40:00` - `2022-05-21 14:45:00`この時間範囲内では、システムは異常です。
-- 正常な時間範囲: `2022-05-21 14:30:00` - `2022-05-21 14:35:00`この時間範囲内では、システムは正常です。
+- 異常な時間範囲: `2022-05-21 14:40:00` - `2022-05-21 14:45:00`。この時間範囲内では、システムは異常です。
+- 正常な時間範囲: `2022-05-21 14:30:00` - `2022-05-21 14:35:00`。この時間範囲内では、システムは正常です。
 
 前の 2つの時間範囲の比較レポートを生成するには、次の手順に従います。
 

dashboard/dashboard-diagnostics-report.md

@@ -32,7 +32,7 @@ summary: TiDB Dashboard診断レポートでは、基本情報、診断情報、
 
 すべての監視メトリックは、基本的にTiDB Grafana監視ダッシュボードのメトリックと一致しています。モジュールに異常が見つかった場合は、TiDB Grafanaで詳細な監視情報を確認できます。
 
-また、このレポートのメトリック`TOTAL_TIME`と`TOTAL_COUNT` Prometheus から読み取ったデータを監視しているため、統計に計算上の不正確さが存在する可能性があります。
+また、このレポートのメトリック`TOTAL_TIME`と`TOTAL_COUNT`は、Prometheusから読み取った監視データであるため、統計に計算上の不正確さが存在する可能性があります。
 
 このレポートの各部分は次のように紹介されています。
 
@@ -144,7 +144,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド
 
 - `METRIC_NAME` : 監視メトリックの名前。
 - `Label` : 監視メトリックのラベル情報。**展開を**クリックすると、メトリックの各ラベルの詳細な監視情報が表示されます。
-- `TIME_RATIO` : この監視メトリックによって消費された合計時間と、監視行の合計時間の比率（ `TIME_RATIO`は`1`です。たとえば、 `kv_request`の合計消費時間は`tidb_query`の`1.65`倍（つまり`38325.58` / `23223.86` ）です。KVリクエストは同時に実行されるため、すべてのKVリクエストの合計時間は、クエリの合計実行時間（ `tidb_query` ）を超える可能性があります。
+- `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時間。
@@ -174,7 +174,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド
 
 上記の部分のうち、KV リクエスト時間には次の部分が含まれます。
 
-- ネットワークのリクエスト送受信にかかった時間です。現在、この項目の監視指標はありません。KVリクエスト時間から`tikv_grpc_message`差し引くことで、この項目のおおよその見積もりが可能です。
+- ネットワークのリクエスト送受信にかかった時間です。現在、この項目の監視指標はありません。KVリクエスト時間から`tikv_grpc_message`の時間を差し引くことで、この項目のおおよその見積もりが可能です。
 - 消費時間`tikv_grpc_message` 。
 
 上記の部品のうち、 `tikv_grpc_message`回の消費量に含まれる部品は以下のとおりです。
@@ -193,7 +193,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド
 上記のメトリックのうち、 `tikv_storage_async_request`の書き込み時間の消費は、次の部分を含むRaft KV の書き込み時間の消費を指します。
 
 - `tikv_raft_propose_wait`
-- `tikv_raft_process` 、主に`tikv_raft_append_log`含む
+- `tikv_raft_process` 、主に`tikv_raft_append_log`を含む
 - `tikv_raft_commit_log`
 - `tikv_raft_apply_wait`
 - `tikv_raft_apply_log`
@@ -202,13 +202,13 @@ TiDBには自動診断結果が組み込まれています。各フィールド
 
 > **Note:**
 >
-> Raft KVへ`tikv_raft_commit_log`書き込みは1つのバッチで処理される可能性があるため、各モジュールの消費時間を`TOTAL_TIME`で測定することは、 Raft KVへの書き込みに関連するメトリクス（具体的には`tikv_raft_process` `tikv_raft_apply_wait` `tikv_raft_append_log`監視には適していませ`tikv_raft_apply_log` 。このような状況では、各モジュールの消費時間をP999とP99の時間と比較する方が合理的です。
+> Raft KVへの書き込みは1つのバッチで処理される可能性があるため、各モジュールの消費時間を`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件ある場合、 Raft KVは内部的に10件のリクエストをバッチ実行にまとめ、その実行時間は1秒だからです。そのため、各リクエストの実行時間は1秒で、10件のリクエストの合計時間は10秒ですが、 Raft KVの処理時間の合計は1秒です。消費時間を`TOTAL_TIME`計測すると、残りの9秒がどこに費やされているのかが分からなくなってしまう可能性があります。また、リクエストの総数（ `TOTAL_COUNT` ）からも、 Raft KVの監視メトリクスとこれまでの監視メトリクスの違いが分かります。
+> その理由は、非同期書き込みリクエストが10件ある場合、 Raft KVは内部的に10件のリクエストをバッチ実行にまとめ、その実行時間は1秒だからです。そのため、各リクエストの実行時間は1秒で、10件のリクエストの合計時間は10秒ですが、 Raft KVの処理時間の合計は1秒です。消費時間を`TOTAL_TIME`で計測すると、残りの9秒がどこに費やされているのかが分からなくなってしまう可能性があります。また、リクエストの総数（ `TOTAL_COUNT` ）からも、 Raft KVの監視メトリクスとこれまでの監視メトリクスの違いが分かります。
 
 #### 各コンポーネントでエラーが発生しました {#errors-occurred-in-each-component}
 
-表`Errors Occurred in Each Component`は、TiDBとTiKVにおけるエラーの総数を示しています。binlogへのbinlog失敗、 `tikv server is busy`などです。各エラーの具体的な意味については`TiKV channel full`行のコメント`tikv write stall`を参照してください。
+表`Errors Occurred in Each Component`は、TiDBとTiKVにおけるエラーの総数を示しています。例えば、binlogの書き込み失敗、 `tikv server is busy`、 `TiKV channel full`、 `tikv write stall`などです。各エラーの具体的な意味については、行のコメントを参照してください。
 
 ![Errors Occurred in Each Component report](/media/dashboard/dashboard-diagnostics-error.png)
 
@@ -247,7 +247,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド
 
 ![TiDB DDL Owner Report](/media/dashboard/dashboard-diagnostics-tidb-ddl.png)
 
-上記の表は、 `2020-05-21 14:40:00`から5ノード目にあるクラスタの`DDL OWNER`ノード`10.0.1.13:10080`であることを示しています。所有者が変更された場合、上記の表には複数のデータ行が存在し、 `Min_Time`列は対応する既知の所有者の最小時間を示します。
+上記の表は、 `2020-05-21 14:40:00`から、クラスターの`DDL OWNER`が`10.0.1.13:10080`ノードにあることを示しています。所有者が変更された場合、上記の表には複数のデータ行が存在し、 `Min_Time`列は対応する既知の所有者の最小時間を示します。
 
 > **Note:**
 >
@@ -347,9 +347,9 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり
 
 `DIFF_RATIO` : 2つの時間範囲の差の値を示します。以下の値があります。
 
-- 監視メトリックの値が`t2`以内のみで、 `t1`以内の値がない場合は、 `DIFF_RATIO`の値は`1`なります。
-- 監視メトリックの値が`t1`内のみにあり、 `t2`時間範囲内に値がない場合は、 `DIFF_RATIO`の値は`-1`なります。
-- `t2`の値が`t1`より大きい場合、 `DIFF_RATIO` = `(t2.value / t1.value)-1`なります。
+- 監視メトリックの値が`t2`以内のみで、 `t1`以内の値がない場合は、 `DIFF_RATIO`の値は`1`になります。
+- 監視メトリックの値が`t1`内のみにあり、 `t2`時間範囲内に値がない場合は、 `DIFF_RATIO`の値は`-1`になります。
+- `t2`の値が`t1`より大きい場合、 `DIFF_RATIO` = `(t2.value / t1.value)-1`になります。
 - `t2`の値が`t1`の値より小さい場合、 `DIFF_RATIO` = `1-(t1.value / t2.value)`
 
 たとえば、上の表では、 `t2`の`tidb`ノードの平均 CPU 使用率は`t1`の 2.02 倍、つまり`2.02` = `1240/410-1`です。

dashboard/dashboard-diagnostics-usage.md

@@ -36,7 +36,7 @@ T2: `2020-03-10 13:24:30` ～ `2020-03-10 13:27:30` 。この範囲ではQPSが
 - `tidb_cop_duration` : P999 コプロセッサリクエストの処理レイテンシーが 2.48 倍に増加しました。
 - `tidb_kv_write_num` : P999 TiDB トランザクションで書き込まれた KV の数は 7.61 倍に増加しました。
 - `tikv_cop_scan_keys_total_nun` : TiKVコプロセッサーによってスキャンされるキー/値の数が 3つの TiKV インスタンスで大幅に改善されました。
-- `pd_operator_step_finish_total_count`では、転属リーダー数が2.45倍に増加しており、異常時間帯のスケジュールが正常時間帯のスケジュールよりも高くなっていることがわかります。
+- `pd_operator_step_finish_total_count`では、移行したリーダー数が2.45倍に増加しており、異常時間帯のスケジューリングの頻度が正常時間帯よりも高くなっていることがわかります。
 - このレポートは、スロークエリが存在する可能性があることを示しており、SQL文を使用してスロークエリを照会できることを示しています。SQL文の実行結果は次のとおりです。
 
 ```sql