INSPECTION_RESULT

TiDBには、システムの障害や隠れた問題を検出するための診断ルールが組み込まれています。

INSPECTION_RESULTの診断機能は、問題をすばやく見つけて、繰り返しの手作業を減らすのに役立ちます。 select * from information_schema.inspection_resultステートメントを使用して、内部診断をトリガーできます。

information_schema.inspection_result診断結果表information_schema.inspection_resultの構成は次のとおりです。

USE information_schema; DESC inspection_result;
+----------------+--------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------------+--------------+------+------+---------+-------+ | RULE | varchar(64) | YES | | NULL | | | ITEM | varchar(64) | YES | | NULL | | | TYPE | varchar(64) | YES | | NULL | | | INSTANCE | varchar(64) | YES | | NULL | | | STATUS_ADDRESS | varchar(64) | YES | | NULL | | | VALUE | varchar(64) | YES | | NULL | | | REFERENCE | varchar(64) | YES | | NULL | | | SEVERITY | varchar(64) | YES | | NULL | | | DETAILS | varchar(256) | YES | | NULL | | +----------------+--------------+------+------+---------+-------+ 9 rows in set (0.00 sec)

フィールドの説明:

  • RULE :診断ルールの名前。現在、次のルールを使用できます。
    • config :構成が一貫していて適切かどうかを確認します。同じ構成が異なるインスタンスで矛盾している場合、 warningの診断結果が生成されます。
    • version :バージョンの整合性チェック。同じバージョンが異なるインスタンスで一貫していない場合、 warningの診断結果が生成されます。
    • node-load :サーバーの負荷を確認します。現在のシステム負荷が高すぎる場合、対応するwarningの診断結果が生成されます。
    • critical-error :システムの各モジュールは重大なエラーを定義します。対応する期間内に重大なエラーがしきい値を超えると、警告診断結果が生成されます。
    • threshold-check :診断システムは主要なメトリックのしきい値をチェックします。しきい値を超えると、対応する診断情報が生成されます。
  • ITEM :各ルールは異なるアイテムを診断します。このフィールドは、各ルールに対応する特定の診断項目を示します。
  • TYPE :診断のインスタンスタイプ。オプションの値はtidb 、およびpd tikv
  • INSTANCE :診断されたインスタンスの特定のアドレス。
  • STATUS_ADDRESS :インスタンスのHTTPAPIサービスアドレス。
  • VALUE :特定の診断項目の値。
  • REFERENCE :この診断項目の基準値(しきい値)。 VALUEがしきい値を超えると、対応する診断情報が生成されます。
  • SEVERITY :重大度レベル。オプションの値はwarningcriticalです。
  • DETAILS :診断の詳細。さらに診断するためのSQLステートメントまたはドキュメントリンクが含まれている場合があります。

診断例

クラスタに現在存在する問題を診断します。

SELECT * FROM information_schema.inspection_result\G
***************************[ 1. row ]*************************** RULE | config ITEM | log.slow-threshold TYPE | tidb INSTANCE | 172.16.5.40:4000 VALUE | 0 REFERENCE | not 0 SEVERITY | warning DETAILS | slow-threshold = 0 will record every query to slow log, it may affect performance ***************************[ 2. row ]*************************** RULE | version ITEM | git_hash TYPE | tidb INSTANCE | VALUE | inconsistent REFERENCE | consistent SEVERITY | critical DETAILS | the cluster has 2 different tidb version, execute the sql to see more detail: select * from information_schema.cluster_info where type='tidb' ***************************[ 3. row ]*************************** RULE | threshold-check ITEM | storage-write-duration TYPE | tikv INSTANCE | 172.16.5.40:23151 VALUE | 130.417 REFERENCE | < 0.100 SEVERITY | warning DETAILS | max duration of 172.16.5.40:23151 tikv storage-write-duration was too slow ***************************[ 4. row ]*************************** RULE | threshold-check ITEM | rocksdb-write-duration TYPE | tikv INSTANCE | 172.16.5.40:20151 VALUE | 108.105 REFERENCE | < 0.100 SEVERITY | warning DETAILS | max duration of 172.16.5.40:20151 tikv rocksdb-write-duration was too slow

上記の診断結果から、次の問題を検出できます。

  • 最初の行は、TiDBのlog.slow-thresholdの値が0に構成されていることを示しています。これは、パフォーマンスに影響を与える可能性があります。
  • 2行目は、2つの異なるTiDBバージョンがクラスタに存在することを示しています。
  • 3行目と4行目は、TiKVの書き込み遅延が長すぎることを示しています。予想される遅延は0.1秒以内ですが、実際の遅延は予想よりはるかに長くなります。

また、「2020-03-2600:03:00」から「2020-03-2600:08:00」など、指定した範囲内に存在する問題を診断することもできます。時間範囲を指定するには、SQLヒント/*+ time_range() */を使用します。次のクエリ例を参照してください。

select /*+ time_range("2020-03-26 00:03:00", "2020-03-26 00:08:00") */ * from information_schema.inspection_result\G
***************************[ 1. row ]*************************** RULE | critical-error ITEM | server-down TYPE | tidb INSTANCE | 172.16.5.40:4009 VALUE | REFERENCE | SEVERITY | critical DETAILS | tidb 172.16.5.40:4009 restarted at time '2020/03/26 00:05:45.670' ***************************[ 2. row ]*************************** RULE | threshold-check ITEM | get-token-duration TYPE | tidb INSTANCE | 172.16.5.40:10089 VALUE | 0.234 REFERENCE | < 0.001 SEVERITY | warning DETAILS | max duration of 172.16.5.40:10089 tidb get-token-duration is too slow

上記の診断結果から、次の問題を検出できます。

  • 最初の行は、 172.16.5.40:4009つのTiDBインスタンスが2020/03/26 00:05:45.670で再起動されることを示しています。
  • 2番目の行は、 172.16.5.40:10089のTiDBインスタンスの最大get-token-duration時間が0.234秒であることを示していますが、予想される時間は0.001秒未満です。

たとえば、条件を指定して、 criticalレベルの診断結果を照会することもできます。

select * from information_schema.inspection_result where severity='critical';

critical-errorのルールの診断結果のみを照会します。

select * from information_schema.inspection_result where rule='critical-error';

診断ルール

診断モジュールには一連のルールが含まれています。これらのルールは、既存の監視テーブルとクラスタ情報テーブルにクエリを実行した後、結果をしきい値と比較します。結果がしきい値を超えると、 warningまたはcriticalの診断が生成され、対応する情報がdetails列に表示されます。

inspection_rulesのシステムテーブルをクエリすることにより、既存の診断ルールをクエリできます。

select * from information_schema.inspection_rules where type='inspection';
+-----------------+------------+---------+ | NAME | TYPE | COMMENT | +-----------------+------------+---------+ | config | inspection | | | version | inspection | | | node-load | inspection | | | critical-error | inspection | | | threshold-check | inspection | | +-----------------+------------+---------+

config診断ルール

configつの診断ルールでは、 CLUSTER_CONFIGのシステムテーブルを照会することにより、次の2つの診断ルールが実行されます。

  • 同じコンポーネントの構成値が一貫しているかどうかを確認します。すべての構成アイテムにこの整合性チェックがあるわけではありません。整合性チェックの許可リストは次のとおりです。

    // The allowlist of the TiDB configuration consistency check port status.status-port host path advertise-address status.status-port log.file.filename log.slow-query-file tmp-storage-path // The allowlist of the PD configuration consistency check advertise-client-urls advertise-peer-urls client-urls data-dir log-file log.file.filename metric.job name peer-urls // The allowlist of the TiKV configuration consistency check server.addr server.advertise-addr server.status-addr log-file raftstore.raftdb-path storage.data-dir storage.block-cache.capacity
  • 次の構成項目の値が期待どおりかどうかを確認してください。

    成分Configuration / コンフィグレーション項目期待値
    TiDBlog.slow-threshold0より大きい
    TiKVraftstore.sync-logtrue

version診断ルール

version診断ルールは、 CLUSTER_INFOシステムテーブルをクエリすることにより、同じコンポーネントのバージョンハッシュが一貫しているかどうかをチェックします。次の例を参照してください。

SELECT * FROM information_schema.inspection_result WHERE rule='version'\G
***************************[ 1. row ]*************************** RULE | version ITEM | git_hash TYPE | tidb INSTANCE | VALUE | inconsistent REFERENCE | consistent SEVERITY | critical DETAILS | the cluster has 2 different tidb versions, execute the sql to see more detail: SELECT * FROM information_schema.cluster_info WHERE type='tidb'

critical-error診断ルール

critical-errorつの診断ルールでは、次の2つの診断ルールが実行されます。

  • メトリックスキーマ内の関連する監視システムテーブルをクエリして、クラスタに次のエラーがあるかどうかを検出します。

    成分エラー名モニタリングテーブルエラーの説明
    TiDBパニックカウントtidb_panic_count_total_countパニックはTiDBで発生します。
    TiDBbinlog-エラーtidb_binlog_error_total_countTiDBがbinlogを書き込むときにエラーが発生します。
    TiKVクリティカル・エラーtikv_critical_error_total_counTiKVの重大なエラー。
    TiKVスケジューラーは忙しいtikv_scheduler_is_busy_total_countTiKVスケジューラがビジー状態であるため、TiKVが一時的に使用できなくなります。
    TiKVコプロセッサーはビジーですtikv_coprocessor_is_busy_total_countTiKVコプロセッサーがビジーすぎます。
    TiKVチャネルがいっぱいですtikv_channel_full_total_count「チャネルフル」エラーはTiKVで発生します。
    TiKVtikv_engine_write_stalltikv_engine_write_stall「ストール」エラーはTiKVで発生します。
  • metrics_schema.upの監視テーブルとCLUSTER_LOGのシステムテーブルを照会して、コンポーネントが再起動されているかどうかを確認します。

threshold-check診断ルール

threshold-check診断ルールは、メトリックスキーマ内の関連する監視システムテーブルをクエリすることにより、クラスタの次のメトリックがしきい値を超えているかどうかをチェックします。

成分モニタリングメトリックモニタリングテーブル期待値説明
TiDBtso-期間pd_tso_wait_duration<50msトランザクションのTSOを取得するための待機時間。
TiDBget-token-durationtidb_get_token_duration<1msトークンの取得にかかる時間を照会します。関連するTiDB構成アイテムはtoken-limitです。
TiDBload-schema-durationtidb_load_schema_duration<1秒TiDBがスキーマメタデータを更新するのにかかる時間。
TiKVスケジューラー-cmd-期間tikv_scheduler_command_duration<0.1秒TiKVがcmd要求を実行するのにかかる時間。
TiKVハンドル-スナップショット-期間tikv_handle_snapshot_duration<30秒TiKVがスナップショットを処理するのにかかる時間。
TiKVストレージ-書き込み-期間tikv_storage_async_request_duration<0.1秒TiKVの書き込みレイテンシ。
TiKVストレージ-スナップショット-期間tikv_storage_async_request_duration<50msTiKVがスナップショットを取得するのにかかる時間。
TiKVrocksdb-書き込み-期間tikv_engine_write_duration<100msTiKVRocksDBの書き込みレイテンシ。
TiKVrocksdb-get-durationtikv_engine_max_get_duration<50msTiKVRocksDBの読み取りレイテンシ。
TiKVrocksdb-seek-durationtikv_engine_max_seek_duration<50msTiKVRocksDBがseekを実行するまでの待ち時間。
TiKVスケジューラー保留中のcmd-countikv_scheduler_pending_commands<1000TiKVで停止したコマンドの数。
TiKVindex-block-cache-hittikv_block_index_cache_hit0.95TiKVのインデックスブロックキャッシュのヒット率。
TiKVfilter-block-cache-hittikv_block_filter_cache_hit0.95TiKVのフィルターブロックキャッシュのヒット率。
TiKVdata-block-cache-hittikv_block_data_cache_hit0.80TiKVのデータブロックキャッシュのヒット率。
TiKVリーダー-スコア-バランスpd_scheduler_store_status<0.05各TiKVインスタンスのリーダースコアのバランスが取れているかどうかを確認します。インスタンス間の予想される差異は5%未満です。
TiKVリージョンスコアバランスpd_scheduler_store_status<0.05各TiKVインスタンスのRegionスコアのバランスが取れているかどうかを確認します。インスタンス間の予想される差異は5%未満です。
TiKV店舗利用可能残高pd_scheduler_store_status<0.2各TiKVインスタンスの使用可能なストレージのバランスが取れているかどうかを確認します。インスタンス間の予想される差異は20%未満です。
TiKVリージョンカウントpd_scheduler_store_status<20000各TiKVインスタンスのリージョン数を確認します。 1つのインスタンスで予想されるリージョンの数は20,000未満です。
PD地域の健康pd_region_health<100クラスタでスケジューリング中のリージョンの数を検出します。予想される数は合計で100未満です。

さらに、このルールは、TiKVインスタンス内の次のスレッドのCPU使用率が高すぎるかどうかもチェックします。

  • スケジューラー-ワーカー-CPU
  • コプロセッサー-通常-CPU
  • コプロセッサー-high-cpu
  • コプロセッサー-low-cpu
  • grpc-cpu
  • raftstore-cpu
  • apply-cpu
  • storage-readpool-normal-cpu
  • storage-readpool-high-cpu
  • storage-readpool-low-cpu
  • split-check-cpu

組み込みの診断ルールは常に改善されています。より多くの診断ルールがある場合は、 tidbリポジトリでPRまたは問題を作成することを歓迎します。

このページは役に立ちましたか?