TiDBダッシュボードFAQ
このドキュメントでは、TiDBダッシュボードに関するよくある質問（FAQ）と回答をまとめています。指示どおりに実行しても問題が見つからない、または解決しない場合は、PingCAPテクニカルサポートに連絡してください。
アクセス関連のFAQ
ファイアウォールまたはリバースプロキシが構成されている場合、TiDBダッシュボード以外の内部アドレスにリダイレクトされます
複数のPlacementDriver（PD）インスタンスがクラスタにデプロイされている場合、実際にTiDBダッシュボードサービスを実行しているのはPDインスタンスの1つだけです。これの代わりに他のPDインスタンスにアクセスすると、ブラウザは別のアドレスにリダイレクトします。ファイアウォールまたはリバースプロキシがTiDBダッシュボードにアクセスするように適切に構成されていない場合、ダッシュボードにアクセスすると、ファイアウォールまたはリバースプロキシによって保護されている内部アドレスにリダイレクトされる可能性があります。
- 複数のPDインスタンスを使用するTiDBダッシュボードの動作原理については、 TiDBダッシュボードマルチPDインスタンスの展開を参照してください。
- リバースプロキシを正しく構成する方法については、 リバースプロキシを介してTiDBダッシュボードを使用するを参照してください。
- ファイアウォールを正しく構成する方法については、 セキュリティTiDBダッシュボードを参照してください。
TiDBダッシュボードがデュアルネットワークインターフェイスカード（NIC）で展開されている場合、別のNICを使用してTiDBダッシュボードにアクセスすることはできません
セキュリティ上の理由から、PD上のTiDBダッシュボードは、展開中に指定されたIPアドレスのみを監視します（つまり、1つのNICでのみリッスンします） 0.0.0.0では監視しません。したがって、ホストに複数のNICがインストールされている場合、別のNICを使用してTiDBダッシュボードにアクセスすることはできません。
tiup clusterまたはtiup playgroundコマンドを使用してTiDBを展開した場合、現在この問題は解決できません。 TiDBダッシュボードを別のNICに安全に公開するには、リバースプロキシを使用することをお勧めします。詳細については、 リバースプロキシの背後でTiDBダッシュボードを使用するを参照してください。
UI関連のFAQ
prometheus_not_foundエラーは、[概要]ページの[ QPS ]セクションと[レイテンシ]セクションに表示されます
[**概要]**ページの[ QPS ]セクションと[レイテンシ]セクションには、Prometheusがデプロイされたクラスタが必要です。それ以外の場合は、エラーが表示されます。この問題は、Prometheusインスタンスをクラスタにデプロイすることで解決できます。
Prometheusインスタンスがデプロイされたときにこの問題が引き続き発生する場合、考えられる理由は、デプロイメントツールが古く（TiUPまたはTiDB Operator）、ツールがメトリックアドレスを自動的に報告しないため、TiDBダッシュボードがクエリを実行できないことです。メトリック。デプロイメントツールを最新バージョンにアップグレードして、再試行できます。
展開ツールがTiUPの場合は、次の手順を実行してこの問題を解決してください。その他の展開ツールについては、それらのツールの対応するドキュメントを参照してください。
TiUPおよびTiUPクラスターのアップグレード：
tiup update --self tiup update cluster --forceアップグレード後、Prometheusインスタンスを使用して新しいクラスタをデプロイすると、メトリックを正常に表示できます。
アップグレード後、既存のクラスタの場合、このクラスタを再起動してメトリックアドレスをレポートできます。
CLUSTER_NAMEを実際のクラスタ名に置き換えます。tiup cluster start CLUSTER_NAMEクラスタが起動している場合でも、このコマンドを実行してください。このコマンドは、クラスタの通常のアプリケーションには影響しませんが、メトリックアドレスを更新して報告するため、監視メトリックをTiDBダッシュボードに通常どおり表示できます。
invalid connectionエラーは、[概要]ページの[Top SQLステートメントと最近の低速クエリ]に表示されます。
考えられる理由は、TiDBのprepared-plan-cacheつの機能を有効にしたことです。実験的機能として、有効にすると、 prepared-plan-cacheは特定のTiDBバージョンで正しく機能しない可能性があり、TiDBダッシュボード（および他のアプリケーション）でこの問題を引き起こす可能性があります。この問題を解決するためにTiDBConfiguration / コンフィグレーションファイルを更新することにより、 prepared-plan-cacheを無効にすることができます。
unknown fieldエラーが[低速クエリ]ページに表示されます
クラスタのアップグレード後に[低速クエリ]ページにunknown fieldのエラーが表示される場合、エラーは、TiDBダッシュボードサーバーフィールド（更新される可能性があります）とユーザー設定フィールド（ブラウザーキャッシュにある）の違いによって引き起こされる互換性の問題に関連しています。 。この問題は修正されました。クラスタがv5.0.3またはv4.0.14より前の場合は、次の手順を実行して問題を解決します。
ブラウザのキャッシュをクリアするには、次の手順を実行します。
TiDBダッシュボードページを開きます。
開発者ツールを開きます。ブラウザが異なれば、開発者ツールを開く方法も異なります。メニューバーをクリックした後：
- Firefox： [メニュー] >[ Web開発者]>[ツールの切り替え]、または[ツール]>[ Web開発者]>[ツールの切り替え]。
- Chrome：その他のツール>開発者ツール。
- Safari：[開発]>[ Webインスペクターを表示]。 [開発]メニューが表示されない場合は、[ Safari ]>[設定] >[詳細設定]に移動し、[メニューバーに[開発]メニューを表示する]チェックボックスをオンにします。
次の例では、Chromeが使用されています。
[アプリケーション]パネルを選択し、[ローカルストレージ]メニューを展開して、[ TiDBダッシュボード]ページのドメインを選択します。 [すべてクリア]ボタンをクリックします。
required component NgMonitoring is not startedエラーが表示されます
NgMonitoringは、v5.4.0以降のバージョンのTiDBクラスターに組み込まれている高度な監視コンポーネントです。連続プロファイリングやTop SQLなどの機能をサポートしています。 TiUPを使用してデプロイされたTiDBクラスタでは、NgMonitoringが自動的にデプロイされます。 TiDB Operatorを使用してデプロイされたTiDBクラスタでは、 継続的なプロファイリングを有効にするを参照してNgMonitoringを手動でデプロイする必要があります。
[継続的なプロファイリング]ページにrequired component NgMonitoring is not startedが表示されている場合は、TiDBクラスタの展開方法に基づいて問題に対処します。
TiUPを使用してデプロイされたクラスター
手順1.バージョンを確認する
TiUPクラスタのバージョンを確認してください。 NgMonitoringは、TiUPがv1.9.0以降の場合にのみ使用できます。
tiup cluster --versionコマンド出力には、TiUPのバージョンが表示されます。例えば：
tiup version 1.9.0 tiup Go Version: go1.17.2 Git Ref: v1.9.0TiUPクラスタのバージョンがv1.9.0より前の場合は、TiUPおよびTiUPクラスタを最新バージョンにアップグレードします。
tiup update --all
手順2.TiUPを使用して、制御マシンにng_port構成項目を追加します。次に、Prometheusをリロードします。
クラスタ構成ファイルを編集モードで開きます。
tiup cluster edit-config ${cluster-name}monitoring_serversの下に、ng_port:${port}のパラメーターを追加します。monitoring_servers: - host: 172.16.6.6 ng_port: ${port}プロメテウスをリロード：
tiup cluster reload ${cluster-name} --role prometheus
上記の手順を実行した後、TiDBダッシュボードで継続的プロファイリングを有効にします。それでもNgMonitoringを開始できない場合は、PingCAPテクニカルサポートに問い合わせてください。
TiDB Operatorを使用してデプロイされたクラスター
継続的なプロファイリングを有効にするを参照してNgMonitoringをデプロイします。