重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

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

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

監視アーキテクチャ

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

The monitoring architecture in the TiDB cluster

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

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

モニタリングデータのソースと表示

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のヒント

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

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

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

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軸のスケールを切り替える

クエリ期間を例にとると、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を組み合わせると、 sql_type次元を見つけることができ、 SELECTステートメントまたはUPDATEステートメントのどちらが遅いかをすぐに分析するのに役立ちます。遅い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つのメトリックの相関関係を確認するのに便利です。

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

Set the graphical presentation tool to Shared crosshair

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

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クラスターの操作と保守に非常に役立ちます。