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 : 診断のインスタンス タイプ。オプションの値はtidbpd 、およびtikvです。
  • INSTANCE : 診断されたインスタンスの特定のアドレス。
  • STATUS_ADDRESS : インスタンスの HTTP API サービス アドレス。
  • 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-26 00:03:00」から「2020-03-26 00:08:00」など、指定した範囲内の問題も診断できます。時間範囲を指定するには、SQL Hint of /*+ 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番目の診断ルールでは、次の 2 つの診断ルールがCLUSTER_CONFIGシステム テーブルをクエリすることによって実行されます。

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

    // 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-しきい値0より大きい
    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_countTiDB でパニックが発生します。
    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_countTiKVで「チャンネルフル」エラーが発生。
    TiKVtikv_engine_write_stalltikv_engine_write_stallTiKV で「ストール」エラーが発生します。
  • metrics_schema.up監視テーブルとCLUSTER_LOGシステム テーブルをクエリして、コンポーネントが再起動されているかどうかを確認します。

threshold-check診断ルール

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

成分モニタリング指標監視テーブル期待値説明
TiDBtso-期間pd_tso_wait_duration< 50msトランザクションの TSO を取得するための待機時間。
TiDB取得トークン期間tidb_get_token_duration< 1msトークンの取得にかかる時間を照会します。関連する TiDB 構成アイテムはtoken-limitです。
TiDBロードスキーマ期間tidb_load_schema_duration< 1 秒TiDB がスキーマ メタデータを更新するのにかかる時間。
TiKVscheduler-cmd-durationtikv_scheduler_command_duration< 0.1 秒TiKV が KV cmdリクエストを実行するのにかかる時間。
TiKVハンドル スナップショット期間tikv_handle_snapshot_duration30代未満TiKV がスナップショットを処理するのにかかる時間。
TiKVストレージ書き込み期間tikv_storage_async_request_duration< 0.1 秒TiKV の書き込みレイテンシー。
TiKVストレージ スナップショット期間tikv_storage_async_request_duration< 50msTiKV がスナップショットを取得するのにかかる時間。
TiKVrocksdb-書き込み期間tikv_engine_write_duration< 100msTiKV RocksDB の書き込みレイテンシー。
TiKVrocksdb-get-durationtikv_engine_max_get_duration< 50msTiKV RocksDB の読み取りレイテンシー。
TiKVrocksdb-シーク期間tikv_engine_max_seek_duration< 50ms実行する TiKV RocksDB のレイテンシーseek .
TiKVscheduler-pending-cmd-counttikv_scheduler_pending_commands< 1000TiKV で停止したコマンドの数。
TiKVインデックス ブロック キャッシュ ヒットtikv_block_index_cache_hit0.95TiKVのインデックスブロックキャッシュのヒット率。
TiKVフィルター ブロック キャッシュ ヒットtikv_block_filter_cache_hit0.95TiKV のフィルタ ブロック キャッシュのヒット率。
TiKVデータ ブロック キャッシュ ヒットtikv_block_data_cache_hit0.80TiKVのデータブロックキャッシュのヒット率。
TiKVリーダースコアバランスpd_scheduler_store_status< 0.05各 TiKV インスタンスのリーダー スコアが均衡しているかどうかを確認します。インスタンス間の予想差は 5% 未満です。
TiKV地域スコアバランスpd_scheduler_store_status< 0.05各 TiKV インスタンスのリージョンスコアが均衡しているかどうかを確認します。インスタンス間の予想差は 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
  • コプロセッサー高 CPU
  • コプロセッサ-低-cpu
  • grpc-cpu
  • raftstore-cpu
  • 適用-CPU
  • storage-readpool-normal-cpu
  • storage-readpool-high-cpu
  • storage-readpool-low-cpu
  • スプリットチェックCPU

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

エコシステム
TiDB
TiKV
TiSpark
Chaos Mesh
© 2022 PingCAP. All Rights Reserved.