pingcap · yahonda · Sep 10, 2026 · Sep 10, 2026 · Sep 10, 2026 · Sep 10, 2026
diff --git a/alert-rules.md b/alert-rules.md
@@ -49,7 +49,7 @@ summary: TiDB クラスターのアラートルールについて学習します
 
 - 解決：
 
-    リーダーのバランスは、[**TiKV-Details**&gt;**クラスタ**ダッシュボード](/grafana-tikv-dashboard.md#cluster)で確認します。
+    リーダーのバランスは、[**TiKV-Details**&gt;**Cluster**ダッシュボード](/grafana-tikv-dashboard.md#cluster)で確認します。
 
 #### `TiDB_domain_load_schema_total` {#tidb_domain_load_schema_total}
 
@@ -411,7 +411,7 @@ summary: TiDB クラスターのアラートルールについて学習します
 - 解決：
 
     - [**TiKV-Details**&gt; **PD**ダッシュボード](/grafana-tikv-dashboard.md#pd)を監視し、ストア低速スコアのメトリックを確認します。メトリック値が80を超えるノードを特定し、低速ノードとして検出します。
-    - [**TiKV-詳細**&gt; **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。
+    - [**TiKV-Details**&gt; **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。
     - レイテンシーのタイムアウト制限を増やすには、 [`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)設定項目を大きな値に設定します。
     - アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#storage-async-write-duration-store-duration-and-apply-duration)を参照してください。
 
@@ -482,8 +482,8 @@ summary: TiDB クラスターのアラートルールについて学習します
 - 解決：
 
     1. [**TiKV-Details**&gt; **Raft Propose**ダッシュボード](/grafana-tikv-dashboard.md#raft-propose)を監視し、アラートが発生した TiKV ノードのRaftプロポーズが他の TiKV ノードよりも大幅に高いかどうかを確認します。もしそうであれば、この TiKV に 1つ以上のホットスポットがあることを意味します。ホットスポットのスケジューリングが適切に機能するかどうかを確認する必要があります。
-    2. [**TiKV-詳細**&gt; **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。
-    3. [**TiKV-Details**&gt;**Raftプロセス**ダッシュボード](/grafana-tikv-dashboard.md#raft-process)を見て、 `tick duration`ハイかどうかを確認してください。ハイなら、 [`raftstore.raft-base-tick-interval`](/tikv-configuration-file.md#raft-base-tick-interval)を `"2s"`に設定する必要があります。
+    2. [**TiKV-Details**&gt; **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。
+    3. [**TiKV-Details**&gt;**Raft process**ダッシュボード](/grafana-tikv-dashboard.md#raft-process)を見て、 `tick duration`ハイかどうかを確認してください。ハイなら、 [`raftstore.raft-base-tick-interval`](/tikv-configuration-file.md#raft-base-tick-interval)を `"2s"`に設定する必要があります。
 
 #### `TiKV_write_stall` {#tikv_write_stall}
 
@@ -537,7 +537,7 @@ summary: TiDB クラスターのアラートルールについて学習します
 
 - 解決：
 
-    1. [**TiKV-Details**&gt; **Raft提案**ダッシュボード](/grafana-tikv-dashboard.md#raft-propose)を監視し、アラート対象の TiKV ノードの**サーバーあたりの 99% Propose 待機期間**メトリックが他の TiKV ノードと比べて大幅に高いかどうかを確認します。高い場合、この TiKV ノードにホットスポットが存在することを示し、ホットスポットのスケジューリングが適切に機能しているかどうかを確認する必要があります。
+    1. [**TiKV-Details**&gt; **Raft Propose**ダッシュボード](/grafana-tikv-dashboard.md#raft-propose)を監視し、アラート対象の TiKV ノードの**サーバーあたりの 99% Propose 待機期間**メトリックが他の TiKV ノードと比べて大幅に高いかどうかを確認します。高い場合、この TiKV ノードにホットスポットが存在することを示し、ホットスポットのスケジューリングが適切に機能しているかどうかを確認する必要があります。
     2. [**TiKV-Details**&gt; **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。
     3. アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#storage-async-write-duration-store-duration-and-apply-duration)を参照してください。
 
@@ -739,7 +739,7 @@ summary: TiDB クラスターのアラートルールについて学習します
 
 - 解決：
 
-    [**TiKV-Details**&gt;**タスク**ダッシュボード](/grafana-tikv-dashboard.md#task)のうち`Worker pending tasks`メトリックから、どの種類のタスクの値が高いかを確認します。
+    [**TiKV-Details**&gt;**Task**ダッシュボード](/grafana-tikv-dashboard.md#task)のうち`Worker pending tasks`メトリックから、どの種類のタスクの値が高いかを確認します。
 
 #### `TiKV_low_space` {#tikv_low_space}
 

diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md
@@ -35,9 +35,9 @@ Raftstore のワークフロー図から、各リージョンのメッセージ
 
 ### パフォーマンス監視 {#performance-monitoring}
 
-Grafana の**TiKV ダッシュボード**では、次の監視メトリックを確認できます。
+Grafana の**TiKV-Details**ダッシュボードでは、次の監視メトリックを確認できます。
 
-- **スレッドCPU**パネルの`Raft store CPU`
+- **Thread CPU**パネルの`Raft store CPU`
 
     基準値： `raftstore.store-pool-size * 85%`未満。
 

diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md
@@ -62,15 +62,15 @@ tikv:
 
 既存のデプロイメントプランではCPUリソースが限られており、実際のリクエスト数も少ないため、監視パネルを監視し、 [`server.grpc-concurrency`](/tikv-configuration-file.md#grpc-concurrency)の値を下げて使用率を80%未満に保つことができます。
 
-このテストでは、このパラメータの値は`2`に設定されています。gRPC**ポーリング CPU**パネルを確認すると、使用率が約 80% であることがわかります。
+このテストでは、このパラメータの値は`2`に設定されています。**gRPC poll CPU**パネルを確認すると、使用率が約 80% であることがわかります。
 
 ![gRPC Pool CPU](/media/best-practices/three-nodes-grpc-pool-usage.png)
 
 #### `storage.scheduler-worker-pool-size` {#storage-scheduler-worker-pool-size}
 
 TiKVがマシンのCPUコア数が`16`以上であることを検出すると、このパラメータ値はデフォルトで`8`に設定されます。CPUコア数が`16`未満の場合、このパラメータ値はデフォルトで`4`に設定されます。スケジューラスレッドプールは、TiKVが複雑なトランザクションリクエストを単純なキー値の読み取りまたは書き込みに変換するために使用されます。ただし、スケジューラスレッドプール自体は書き込み操作を実行しません。
 
-理想的には、スケジューラスレッドプールの使用率は50%～75%に維持されます。gRPCスレッドプールと同様に、ハイブリッドデプロイ中はパラメータ`storage.scheduler-worker-pool-size`がデフォルトで大きな値に設定されるため、リソースの使用率が低くなりすぎます。このテストでは、このパラメータの値はベストプラクティスに沿って`2`に設定されており、これは**スケジューラワーカーCPU**パネルの対応するメトリックを観察した結果に基づいています。
+理想的には、スケジューラスレッドプールの使用率は50%～75%に維持されます。gRPCスレッドプールと同様に、ハイブリッドデプロイ中はパラメータ`storage.scheduler-worker-pool-size`がデフォルトで大きな値に設定されるため、リソースの使用率が低くなりすぎます。このテストでは、このパラメータの値はベストプラクティスに沿って`2`に設定されており、これは**Scheduler worker CPU**パネルの対応するメトリックを観察した結果に基づいています。
 
 ![Scheduler Worker CPU](/media/best-practices/three-nodes-scheduler-pool-usage.png)
 

diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md
@@ -78,7 +78,7 @@ tikv-ctl --host=<tikv-ip:port> modify-tikv-config -n backup.enable-auto-tune -v
 |^^^^**--| Because the cluster workload gets higher, auto-tune adjusts the size of the thread pool to `2`. After that, the cluster still has 2 idle CPU cores.
 ```
 
-**バックアップ CPU 使用率**パネルでは、自動調整によって調整されたスレッドプールのサイズを確認できます。
+**Backup CPU Utilization**パネルでは、自動調整によって調整されたスレッドプールのサイズを確認できます。
 
 ![Grafana dashboard example of backup auto-tune metrics](/media/br/br-auto-throttle.png)
 

diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md
@@ -9,7 +9,7 @@ summary: このドキュメントでは、ログバックアップの監視、
 
 ## スナップショットのバックアップと復元の監視 {#snapshot-backup-and-restore-monitoring}
 
-スナップショットのバックアップと復元のメトリックを表示するには、Grafana の[**TiKV-Details**&gt;**バックアップとインポート**ダッシュボード](/grafana-tikv-dashboard.md#backup--import)に移動します。
+スナップショットのバックアップと復元のメトリックを表示するには、Grafana の[**TiKV-Details**&gt;**Backup & Import**ダッシュボード](/grafana-tikv-dashboard.md#backup--import)に移動します。
 
 ## ログバックアップ監視 {#log-backup-monitoring}
 
@@ -22,8 +22,8 @@ summary: このドキュメントでは、ログバックアップの監視、
 
 ### Grafanaの設定 {#grafana-configuration}
 
-- TiUPを使用してデプロイされたクラスターの場合、ダッシュボード[Grafana](https://grafana.com/)にポイントインタイムリカバリ (PITR) パネルが表示されます。TiKV-Details ダッシュボードの**バックアップログ**パネルが PITR パネルです。
-- 手動でデプロイされたクラスターの場合は、 [Grafanaダッシュボードをインポートする](/deploy-monitoring-services.md#step-2-import-a-grafana-dashboard)を参照し、 [tikv_詳細](https://github.com/tikv/tikv/blob/release-8.5/metrics/grafana/tikv_details.json) JSON ファイルを Grafana にアップロードしてください。その後、TiKV-Details ダッシュボードの**バックアップログ**パネルを見つけてください。
+- TiUPを使用してデプロイされたクラスターの場合、ダッシュボード[Grafana](https://grafana.com/)にポイントインタイムリカバリ (PITR) パネルが表示されます。TiKV-Details ダッシュボードの**Backup Log**パネルが PITR パネルです。
+- 手動でデプロイされたクラスターの場合は、 [Grafanaダッシュボードをインポートする](/deploy-monitoring-services.md#step-2-import-a-grafana-dashboard)を参照し、 [tikv_details](https://github.com/tikv/tikv/blob/release-8.5/metrics/grafana/tikv_details.json) JSON ファイルを Grafana にアップロードしてください。その後、TiKV-Details ダッシュボードの**Backup Log**パネルを見つけてください。
 
 ### 監視メトリクス {#monitoring-metrics}
 

diff --git a/dm/dm-webui-guide.md b/dm/dm-webui-guide.md
@@ -16,11 +16,11 @@ DM WebUIは、TiDB Data Migration (DM)タスクを管理するためのWebベー
 
 DM WebUI には次のページがあります。
 
-- **移住**
+- **Migration**
     - **Task**: タスク作成のエントリを提供し、各移行タスクの詳細情報を表示します。このページでは、移行タスクの監視、作成、削除、および設定を行うことができます。
     - **Source**: 移行タスクのアップストリームデータソースの情報を設定します。このページでは、アップストリーム設定の作成と削除、アップストリーム設定に対応するタスクステータスの監視、アップストリーム設定の変更など、データ移行環境におけるアップストリーム設定を管理できます。
-    - **レプリケーション詳細**：移行タスクの詳細なステータス情報を表示します。このページでは、指定したフィルターに基づいて、上流および下流の構成情報やデータベース名、ソーステーブルとターゲットテーブルの関係など、詳細な構成情報とステータス情報を確認できます。
-- **クラスタ**
+    - **Replication Detail**：移行タスクの詳細なステータス情報を表示します。このページでは、指定したフィルターに基づいて、上流および下流の構成情報やデータベース名、ソーステーブルとターゲットテーブルの関係など、詳細な構成情報とステータス情報を確認できます。
+- **Cluster**
     - **Members**：DMクラスタ内のすべてのマスターノードとワーカーノードのリスト、およびワーカーノードとソースノード間のバインディング関係を表示します。このページでは、現在のDMクラスタの構成情報と各ワーカーのステータス情報を確認できます。また、基本的な管理機能もこのページで提供されます。
 
 インターフェースは次のとおりです。

diff --git a/follower-read.md b/follower-read.md
@@ -101,7 +101,7 @@ set [session | global] tidb_replica_read = '<target value>';
 
 ## 基本的な監視 {#basic-monitoring}
 
-[**TiDB** &gt; **KV Request**&gt;**Read Req Traffic**パネル (v8.5.4 の新機能)](/grafana-tidb-dashboard.md#kv-request)をチェックして、 Follower Read を有効にするかどうかを決定し、有効にした後のトラフィック削減効果を確認できます。
+[**TiDB** &gt; **KV Request** &gt; **Read Req Traffic**パネル (v8.5.4 の新機能)](/grafana-tidb-dashboard.md#kv-request)をチェックして、 Follower Read を有効にするかどうかを決定し、有効にした後のトラフィック削減効果を確認できます。
 
 </CustomContent>
 

diff --git a/garbage-collection-configuration.md b/garbage-collection-configuration.md
@@ -104,7 +104,7 @@ show config where type = 'tikv' and name like '%enable-compaction-filter%';
 
 > **Note:**
 >
-> 圧縮フィルター機構を使用すると、GCの進行が遅れる可能性があり、TiKVスキャンのパフォーマンスに影響する可能性があります。ワークロードに多数のコプロセッサリクエストが含まれており、パネル[**TiKV-Details &gt;コプロセッサー詳細**](/grafana-tikv-dashboard.md#coprocessor-detail)で**Total Ops Details**の呼び出し回数が`next()`または`prev()`で、呼び出し回数が`processed_keys`回の3倍を大幅に超えている場合は、以下の対策を講じることができます。
+> 圧縮フィルター機構を使用すると、GCの進行が遅れる可能性があり、TiKVスキャンのパフォーマンスに影響する可能性があります。ワークロードに多数のコプロセッサリクエストが含まれており、[**TiKV-Details &gt; Coprocessor Detail**](/grafana-tikv-dashboard.md#coprocessor-detail)パネルで**Total Ops Details**の呼び出し回数が`next()`または`prev()`で、呼び出し回数が`processed_keys`回の3倍を大幅に超えている場合は、以下の対策を講じることができます。
 >
 > - v7.1.3 より前の TiDB バージョンでは、GC を高速化するために Compaction Filter を無効にすることをお勧めします。
 > - TiDBバージョンv7.1.3からv7.5.6およびv7.6.0からv8.5.3では、TiDBは各リージョン[`region-compact-min-redundant-rows`](/tikv-configuration-file.md#region-compact-min-redundant-rows-new-in-v710)の冗長バージョンの数と冗長バージョン[`region-compact-redundant-rows-percent`](/tikv-configuration-file.md#region-compact-redundant-rows-percent-new-in-v710)の割合に基づいて自動的にコンパクションをトリガーし、コンパクションフィルタGCのパフォーマンスを向上させます。この場合、コンパクションフィルタを無効にするのではなく、これらの設定項目を調整してください。

diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md
@@ -39,14 +39,14 @@ PD ダッシュボード メトリック項目の説明は次のとおりです
 
 ## Operator {#operator}
 
-- **Schedule operator create**: タイプごとに新しく作成されるオペレーターの数
-- **Schedule operator check**: 種類ごとにチェックされるオペレーターの数。主に現在のステップが完了したかどうかをチェックし、完了している場合は次に実行するステップを返します。
-- **Schedule operator finish**: タイプごとに終了したオペレーターの数
-- **Schedule operator timeout**: タイプごとのタイムアウトオペレーターの数
-- **Schedule operator replaced or canceled**: タイプごとに交代またはキャンセルされたオペレーターの数
-- **Schedule operators count by state**: 状態ごとのオペレーター数
-- **Operator finish duration**: 終了したオペレーターの最大時間
-- **Operator step duration**: 完了したオペレーターステップの最大所要時間
+- Schedule operator create: タイプごとに新しく作成されるオペレーターの数
+- Schedule operator check: 種類ごとにチェックされるオペレーターの数。主に現在のステップが完了したかどうかをチェックし、完了している場合は次に実行するステップを返します。
+- Schedule operator finish: タイプごとに終了したオペレーターの数
+- Schedule operator timeout: タイプごとのタイムアウトオペレーターの数
+- Schedule operator replaced or canceled: タイプごとに交代またはキャンセルされたオペレーターの数
+- Schedule operators count by state: 状態ごとのオペレーター数
+- Operator finish duration: 終了したオペレーターの最大時間
+- Operator step duration: 完了したオペレーターステップの最大所要時間
 
 ![PD Dashboard - Operator metrics](/media/pd-dashboard-operator-v4.png)