Grafana を使用して TiDB を監視するためのベスト プラクティス

トポロジー構成に Grafana と Prometheus をTiUP を使用して TiDB クラスターをデプロイする追加すると、TiDB クラスター内のさまざまなコンポーネントとマシンのメトリックを収集して表示するために、 Grafana + Prometheus 監視プラットフォームのセットが同時にデプロイされます。このドキュメントでは、Grafana を使用して TiDB を監視するためのベスト プラクティスについて説明します。メトリックを使用して TiDB クラスターのステータスを分析し、問題を診断するのに役立つことを目的としています。

監視アーキテクチャ

プロメテウスは、多次元データ モデルと柔軟なクエリ言語を備えた時系列データベースです。 グラファナは、メトリクスを分析および視覚化するためのオープンソースの監視システムです。

The monitoring architecture in the TiDB cluster

TiDB 2.1.3 以降のバージョンでは、TiDB モニタリングはプル方式をサポートしています。これは、次の利点がある優れた調整です。

  • Prometheus を移行する必要がある場合、TiDB クラスター全体を再起動する必要はありません。調整前に、Prometheus を移行するには、ターゲット アドレスを更新する必要があるため、クラスター全体を再起動する必要があります。
  • Grafana + Prometheus 監視プラットフォーム (高可用性ではない) の 2 つの個別のセットを展開して、単一ポイントの監視を防ぐことができます。
  • 単一障害点になる可能性のある Pushgateway が削除されます。

監視データのソースと表示

TiDB の 3 つのコア コンポーネント (TiDBサーバー、TiKVサーバー、および PDサーバー) は、HTTP インターフェイスを介してメトリックを取得します。これらのメトリックはプログラム コードから収集され、ポートは次のとおりです。

成分ポート
TiDBサーバー10080
TiKVサーバー20181
PDサーバー2379

次のコマンドを実行して、HTTP インターフェイスを介して SQL ステートメントの QPS を確認します。例として TiDBサーバーを取り上げます。

curl http://__tidb_ip__:10080/metrics |grep tidb_executor_statement_total
# Check the real-time QPS of different types of SQL statements. The numbers below are the cumulative values of counter type (scientific notation). tidb_executor_statement_total{type="Delete"} 520197 tidb_executor_statement_total{type="Explain"} 1 tidb_executor_statement_total{type="Insert"} 7.20799402e+08 tidb_executor_statement_total{type="Select"} 2.64983586e+08 tidb_executor_statement_total{type="Set"} 2.399075e+06 tidb_executor_statement_total{type="Show"} 500531 tidb_executor_statement_total{type="Use"} 466016

上記のデータは Prometheus に保存され、Grafana に表示されます。パネルを右クリックし、次の図に示す [編集] ボタンをクリックします (またはEキーを直接押します)。

The Edit entry for the Metrics tab

[編集] ボタンをクリックすると、[メトリック] タブにtidb_executor_statement_totalメトリック名のクエリ式が表示されます。パネル上の一部の項目の意味は次のとおりです。

  • rate[1m] : 1 分間の成長率。カウンタ型のデータにのみ使用できます。
  • sum : 値の合計。
  • by type : 合計されたデータは、元のメトリック値のタイプ別にグループ化されます。
  • Legend format : メトリック名の形式。
  • Resolution : ステップ幅のデフォルトは 15 秒です。解像度とは、複数のピクセルに対して 1 つのデータ ポイントを生成するかどうかを意味します。

[メトリクス] タブのクエリ式は次のとおりです。

The query expression on the Metrics tab

Prometheus は、多くのクエリ式と関数をサポートしています。詳細については、 プロメテウス公式サイトを参照してください。

グラファナのヒント

このセクションでは、Grafana を効率的に使用して TiDB のメトリックを監視および分析するための 7 つのヒントを紹介します。

ヒント 1: すべてのディメンションを確認し、クエリ式を編集する

監視データのソースと表示節に示した例では、データはタイプ別にグループ化されています。他のディメンションでグループ化できるかどうかを知りたい場合、および使用可能なディメンションをすばやく確認するには、次の方法を使用できます:クエリ式でメトリック名のみを保持し、計算を行わず、 Legend formatフィールドを空白のままにします。このようにして、元のメトリックが表示されます。たとえば、次の図は、3 つの次元 ( instancejob 、およびtype ) があることを示しています。

Edit query expression and check all dimensions

次に、 typeの後にinstanceディメンションを追加し、 Legend formatフィールドに{{instance}}を追加して、クエリ式を変更できます。このようにして、各 TiDBサーバーで実行されるさまざまなタイプの SQL ステートメントの QPS を確認できます。

Add an instance dimension to the query expression

ヒント 2: Y 軸の目盛りを切り替える

Query Duration を例にとると、Y 軸はデフォルトで 2 進対数スケール (log 2 n) になり、表示のギャップが狭くなります。変更を増幅するために、線形スケールに切り替えることができます。次の 2 つの図を比較すると、表示の違いが簡単にわかり、SQL ステートメントの実行が遅い時間を特定できます。

もちろん、線形スケールがすべての状況に適しているわけではありません。たとえば、1 か月間のパフォーマンスの傾向を観察すると、線形スケールのノイズが発生して観察が困難になる場合があります。

Y 軸は、デフォルトで 2 進対数スケールを使用します。

The Y-axis uses a binary logarithmic scale

Y 軸を線形スケールに切り替えます。

Switch to a linear scale

ヒント:

ヒント 2 とヒント 1 を組み合わせると、 SELECT番目のステートメントとUPDATE番目のステートメントのどちらが遅いかをすぐに分析するのに役立つsql_type次元を見つけることができます。遅い SQL ステートメントを使用してインスタンスを見つけることもできます。

ヒント 3: Y 軸のベースラインを変更して変化を増幅する

線形スケールに切り替えた後も、トレンドを確認できない場合があります。たとえば、次の図では、クラスターのスケーリング後にStore sizeのリアルタイムの変化を観察したいと考えていますが、ベースラインが大きいため、小さな変化は見えません。この場合、Y 軸のベースラインを0からautoに変更して、上部を拡大できます。以下の 2 つの図を確認すると、データの移行が開始されていることがわかります。

ベースラインのデフォルトは0です。

Baseline defaults to 0

ベースラインをautoに変更します。

Change the baseline to auto

ヒント 4: 共有十字線またはツールチップを使用する

[設定]パネルには、デフォルトで [デフォルト] に設定されている [グラフ ツールチップ] パネル オプションがあります。

Graphic presentation tools

次の図に示すように、共有十字線共有ツールチップをそれぞれ使用して効果をテストできます。すると、スケールが連動して表示されるので、問題を診断する際に 2 つの指標の相関関係を確認するのに便利です。

グラフィック プレゼンテーション ツールをShared crosshairに設定します。

Set the graphical presentation tool to Shared crosshair

グラフィカル プレゼンテーション ツールをShared Tooltipに設定します。

Set the graphic presentation tool to Shared Tooltip

ヒント 5: IP address:port numberを入力して、履歴のメトリックを確認します

PD のダッシュボードには、現在のリーダーの指標のみが表示されます。履歴の PD リーダーのステータスを確認したいが、 instanceフィールドのドロップダウン リストに存在しない場合は、手動でIP address:2379を入力してリーダーのデータを確認できます。

Check the metrics in history

ヒント 6: Avg関数を使用する

通常、凡例ではデフォルトでMaxつとCurrentの関数のみが使用可能です。メトリックが大きく変動する場合は、 Avg関数などの他の集計関数を凡例に追加して、期間の全体的な傾向を確認できます。

Avg関数を追加します。

Add summary functions such as Avg

次に、全体的な傾向を確認します。

Add Avg function to check the overall trend

ヒント 7: Prometheus の API を使用してクエリ式の結果を取得する

Grafana は Prometheus の API を介してデータを取得し、この API を使用して情報を取得することもできます。さらに、次の用途もあります。

  • クラスターのサイズや状態などの情報を自動取得します。
  • 1 日あたりの QPS の合計量、1 日あたりの QPS のピーク値、および 1 日あたりの応答時間のカウントなど、レポートに情報を提供するために、式に小さな変更を加えます。
  • 重要なメトリックに対して定期的なヘルス検査を実行します。

Prometheus の API は次のように示されます。

The API of Prometheus

curl -u user:pass 'http://__grafana_ip__:3000/api/datasources/proxy/1/api/v1/query_range?query=sum(tikv_engine_size_bytes%7Binstancexxxxxxxxx20181%22%7D)%20by%20(instance)&start=1565879269&end=1565882869&step=30' |python -m json.tool
{ "data": { "result": [ { "metric": { "instance": "xxxxxxxxxx:20181" }, "values": [ [ 1565879269, "1006046235280" ], [ 1565879299, "1006057877794" ], [ 1565879329, "1006021550039" ], [ 1565879359, "1006021550039" ], [ 1565882869, "1006132630123" ] ] } ], "resultType": "matrix" }, "status": "success" }

概要

Grafana + Prometheus 監視プラットフォームは非常に強力なツールです。これをうまく活用すると、効率が向上し、TiDB クラスターのステータスを分析する時間を大幅に節約できます。さらに重要なことは、問題の診断に役立つことです。このツールは、特に大量のデータがある場合に、TiDB クラスターの運用と保守に非常に役立ちます。