Grafana を使用した TiDB 監視のベストプラクティス
トポロジ構成にGrafanaとPrometheusを追加すると、 TiUPを使用して TiDB クラスタを展開する Grafana + Prometheus 監視プラットフォームのツールセットが同時にデプロイされ、TiDBクラスター内の様々なコンポーネントとマシンのメトリクスを収集・表示します。このドキュメントでは、Grafanaを用いたTiDBの監視に関するベストプラクティスについて説明します。メトリクスを用いてTiDBクラスターの状態を分析し、問題を診断するのに役立つことを目的としています。
監視アーキテクチャ
プロメテウス 、多次元データ モデルと柔軟なクエリ言語を備えた時系列データベースです。2 グラファナ 、メトリックを分析および視覚化するためのオープン ソースの監視システムです。

TiDB 2.1.3以降のバージョンでは、TiDBモニタリングはプル方式をサポートしています。これは以下の利点を持つ優れた調整です。
- Prometheus を移行する必要がある場合、TiDB クラスター全体を再起動する必要はありません。調整前に Prometheus を移行するには、ターゲットアドレスを更新する必要があるため、クラスター全体を再起動する必要があります。
- 監視ポイントが単一になるのを防ぐために、Grafana + Prometheus 監視プラットフォーム (高可用性ではない) の 2 つの個別のセットを展開できます。
- 単一障害点となる可能性のある Pushgateway が削除されます。
監視データのソースと表示
TiDBの3つのコアコンポーネント(TiDBサーバー、TiKVサーバー、PDサーバー)は、HTTPインターフェースを介してメトリクスを取得します。これらのメトリクスはプログラムコードから収集され、デフォルトのポートは次のとおりです。
| 成分 | ポート |
|---|---|
| TiDBサーバー | 10080 |
| TiKVサーバー | 20180 |
| 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キーを押します。

「編集」ボタンをクリックすると、「メトリクス」タブにtidb_executor_statement_totalメトリクス名を含むクエリ式が表示されます。パネル上のいくつかの項目の意味は以下のとおりです。
rate[1m]: 1分間の成長率。カウンター型のデータにのみ使用できます。sum: 値の合計。by type: 合計データは元のメトリック値でタイプ別にグループ化されます。Legend format: メトリック名の形式。Resolution: ステップ幅はデフォルトで15秒です。解像度は、複数のピクセルに対して1つのデータポイントを生成するかどうかを指定します。
[メトリック]タブのクエリ式は次のとおりです。

Prometheusは多くのクエリ式と関数をサポートしています。詳細については、 プロメテウス公式サイトを参照してください。
Grafanaのヒント
このセクションでは、Grafana を使用して TiDB のメトリックを効率的に監視および分析するための 7 つのヒントを紹介します。
ヒント1: すべてのディメンションをチェックしてクエリ式を編集する
セクション監視データのソースと表示に示した例では、データはタイプ別にグループ化されています。他のディメンションでグループ化できるかどうか、また利用可能なディメンションを素早く確認したい場合は、クエリ式にメトリック名のみを入力し、計算は行わず、 Legend formatフィールドを空白のままにしておくjob方法があります。こうすることで、元のメトリックが表示されます。例えば、次の図は3 typeのディメンション( instance )があることを示しています。

次に、クエリ式を修正し、 type後にinstanceディメンションを追加し、 Legend formatフィールドに{{instance}}追加します。これにより、各TiDBサーバーで実行される様々な種類のSQL文のQPSを確認できます。

ヒント2: Y軸のスケールを切り替える
クエリ実行時間を例に挙げると、Y軸はデフォルトで2進対数スケール(log 2 n)に設定されており、表示の差が小さくなります。変化を強調したい場合は、線形スケールに切り替えることができます。以下の2つの図を比較すると、表示の違いが簡単にわかり、SQL文の実行速度が遅い時間帯を特定できます。
もちろん、線形スケールはあらゆる状況に適しているわけではありません。例えば、1か月間のパフォーマンスの傾向を観察する場合、線形スケールではノイズが発生し、観察が困難になる可能性があります。
Y 軸は、デフォルトで 2 進対数スケールを使用します。

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

ヒント:
ヒント 2 とヒント 1 を組み合わせると、
SELECTステートメントとUPDATEステートメントのどちらが遅いかをすぐに分析するのに役立つsql_typeディメンションを見つけることができます。また、遅い SQL ステートメントを含むインスタンスを見つけることもできます。
ヒント3: Y軸のベースラインを変更して変化を強調する
線形スケールに切り替えても、トレンドがまだ見えない場合があります。例えば、次の図では、クラスターをスケーリングした後のStore sizeのリアルタイムの変化を観察したいのですが、ベースラインが大きいため、小さな変化が見えません。このような状況では、Y軸のベースラインを0からautoに変更して、上部を拡大表示することができます。下の2つの図を確認すると、データ移行が始まっていることがわかります。
ベースラインのデフォルトは0です。

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

ヒント4: 共有のクロスヘアまたはツールチップを使用する
設定パネルには、デフォルトでDefaultに設定されているグラフツールチップパネルオプションがあります。

以下の図に示すように、共有クロスヘアと共有ツールチップをそれぞれ使用して効果をテストできます。スケールは連動して表示されるため、問題を診断する際に2つの指標の相関関係を確認するのに便利です。
グラフィック プレゼンテーション ツールを共有クロスヘアに設定します。

グラフィカル プレゼンテーション ツールを共有ツールチップに設定します。

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

ヒント6: Avg関数を使用する
通常、凡例にはデフォルトでMaxとCurrent関数のみが表示されます。指標が大きく変動する場合は、 Avg関数などの他のサマリー関数を凡例に追加して、一定期間の全体的な傾向を確認できます。
Avg関数などの集計関数を追加します。

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

ヒント7: PrometheusのAPIを使用してクエリ式の結果を取得する
GrafanaはPrometheusのAPIを介してデータを取得します。このAPIを使用して情報を取得することもできます。さらに、以下の用途もあります。
- クラスターのサイズやステータスなどの情報を自動的に取得します。
- 1 日あたりの QPS の合計量、1 日あたりの QPS のピーク値、1 日あたりの応答時間のカウントなど、レポートの情報を提供するために式に小さな変更を加えます。
- 重要な指標について定期的な健全性検査を実行します。
Prometheus の API は次のようになります。

curl -u user:pass 'http://__grafana_ip__:3000/api/datasources/proxy/1/api/v1/query_range?query=sum(tikv_engine_size_bytes%7Binstancexxxxxxxxx20180%22%7D)%20by%20(instance)&start=1565879269&end=1565882869&step=30' |python -m json.tool
{
"data": {
"result": [
{
"metric": {
"instance": "xxxxxxxxxx:20180"
},
"values": [
[
1565879269,
"1006046235280"
],
[
1565879299,
"1006057877794"
],
[
1565879329,
"1006021550039"
],
[
1565879359,
"1006021550039"
],
[
1565882869,
"1006132630123"
]
]
}
],
"resultType": "matrix"
},
"status": "success"
}
まとめ
Grafana + Prometheus 監視プラットフォームは非常に強力なツールです。これを有効活用することで効率が向上し、TiDB クラスターの状態分析にかかる時間を大幅に節約できます。さらに重要なのは、問題の診断にも役立つことです。このツールは、特に大量のデータを扱う場合、TiDB クラスターの運用と保守に非常に役立ちます。