Grafana ワークスペースコンソールの開始方法 - Amazon Managed Grafana

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Grafana ワークスペースコンソールの開始方法

このセクションでは、Amazon Managed Grafana ワークスペース内の Grafana コンソールの概要を説明します。Grafana コンソールの使用方法を学ぶのに適した場所です。

Grafana とは

Grafana はオープンソースの可視化および分析ソフトウェアです。メトリクスの保存場所に関係なく、メトリクスのクエリ、視覚化、アラート、探索に使用できます。

例えば、アプリケーションのメトリクス、ログ、トレースデータを表示する場合は、ダッシュボードを作成できます。企業管理者であり、複数のチームの Grafana を管理している場合は、プロビジョニングと認証の設定が必要になる場合があります。

以下のセクションでは、Grafana データベースとリンクで実行できる操作の概要を説明します。これにより、詳細を確認できます。

メトリクスとログを調べる

1 回限りのクエリまたはアドホッククエリを使用してデータを探索し、動的にドリルダウンします。ビューを分割し、さまざまな時間範囲、クエリ、データソースを並べて比較できます。

詳細については、「探索」を参照してください。

アラート

Grafana アラートを使用している場合は、次のようなさまざまなアラート通知機能を使用してアラートを送信できます。

  • Amazon SNS

  • PagerDuty

  • VictorOps

  • OpsGenie

  • Slack

詳細については、「Grafana アラート」を参照してください。

‏注釈

さまざまなデータソースからの豊富なイベントでグラフに注釈を付けます。イベントで一時停止すると、イベントメタデータとタグ全体が表示されます。

この機能は、Grafana でグラフマーカーとして表示されるため、問題が発生した場合にデータを関連付けるのに役立ちます。グラフを選択し、テキストを入力するときに Ctrl キーを押して、注釈を手動で作成できます。または、任意のデータソースからデータを取得することもできます。

詳細については、「‏注釈」を参照してください。

ダッシュボード変数

テンプレート変数を使用して、さまざまなユースケースで再利用できるダッシュボードを作成します。これらのテンプレートでは、値はハードコーディングされません。つまり、ダッシュボードは複数のサーバーに使用できます。例えば、本番サーバーとテストサーバーがある場合は、両方に同じダッシュボードを使用できます。

テンポラリングは、データをドリルダウンするのに役立ちます。例えば、すべてのデータから北米のデータにドリルダウンしたり、メキシコのデータにドリルダウンしたりできます。これらのダッシュボードは、組織内のチーム間で共有することもできます。一般的なデータソース用の優れたダッシュボードテンプレートを作成する場合は、コミュニティ全体に提供してカスタマイズして使用することもできます。

詳細については、「テンプレートと変数」を参照してください。

ダッシュボードの作成

Grafana コンソールでダッシュボードを作成するには、次の手順に従います。

最初のダッシュボードを作成するには
  1. 左パネルの + アイコンを選択し、ダッシュボードの作成 を選択し、新しいパネルの追加 を選択します。

  2. 新しいダッシュボード/パネルの編集ビューで、クエリタブを選択します。

  3. クエリを実行するデータソースを選択して、クエリを設定します。例えば、TestDB をデータソースとして追加した場合、ランダムチュートリアルダッシュボードと呼ばれるサンプルダッシュボードが生成されます。

時系列の概要

外の温度が 1 日を通してどのように変化するか知りたいとしましょう。1 時間に 1 回、温度をチェックし、現在の温度とともに時刻を書き留めます。しばらくすると、次のようなデータが得られます。

時間
09:00 24 インチC
10:00 26 インチC
11:00 27 インチC

このような温度データは、時系列の一例です。時系列で順序付けられた一連の測定値です。表の各行は、特定の時刻における 1 つの個別の測定を表します。

テーブルは、個々の測定値を識別したいが、全体像を見るのが困難になる可能性がある場合に便利です。時系列の一般的な視覚化はグラフ であり、各測定を時間軸に沿って配置します。グラフなどのビジュアル表現を使用すると、表示が難しいデータのパターンや特徴を簡単に見つけることができます。

その他の時系列の例は次のとおりです。

  • CPU とメモリの使用量

  • センサーデータ

  • 株式市場インデックス

これらの各例は時系列に順序付けられた一連の測定値ですが、他の属性も共有します。

  • 新しいデータは、09:00、10:00、11:00 など、一定の間隔で最後に追加されます。

  • 測定値は、追加後に更新されることはほとんどありません。例えば、週末の温度は変わりません。

時系列は強力です。いつでもシステムの状態を分析できるようにすることで、過去の状態を理解するのに役立ちます。時系列では、空きディスク容量がゼロになった直後にサーバーがクラッシュしたことを示している可能性があります。

時系列は、データの傾向を検出することで、将来の予測にも役立ちます。例えば、登録済みユーザーの数が過去数か月間に毎月 4% 増加している場合、ユーザーベースが月末にどれだけ大きくなるかを予測できます。

一部の時系列には、既知の期間にわたって繰り返されるパターンがあります。例えば、温度は通常、夜間に急上昇する前に、その日中に高くなります。これらの定期的または季節的な の時系列を特定することで、次の期間について確実に予測を行うことができます。システムの負荷が毎日 18:00 前後にピークが発生することがわかっている場合は、直前にマシンを追加できます。

時系列の集計

測定する内容によっては、データが大きく異なる場合があります。測定値の間隔よりも長い期間を比較する場合はどうなりますか? 温度を 1 時間に 1 回測定すると、1 日あたり 24 データポイントになります。8 月の温度を長年比較するには、31 倍の 24 個のデータポイントを 1 つにまとめる必要があります。

測定値のコレクションの組み合わせは、集計 と呼ばれます。時系列データを集計する方法は複数あります。一般的なものをいくつか示します。

  • 平均は、すべての値の合計を値の合計で割った値を返します。

  • 最小最大は、コレクション内の最小値と最大値を返します。

  • Sum は、コレクション内のすべての値の合計を返します。

  • Count は、コレクション内の値の数を返します。

例えば、1 か月のデータを集計することで、2017 年 8 月が平均して前年よりも早いことを判断できます。温度が最も高い月を確認するには、各月の最大温度を比較します。

時系列データの集計方法は重要な決定であり、データに伝えるストーリーによって異なります。さまざまな集計を使用して、同じ時系列データをさまざまな方法で視覚化するのが一般的です。

時系列とモニタリング

IT 業界では、インフラストラクチャ、ハードウェア、アプリケーションイベントなどのモニタリングのために時系列データが収集されることがよくあります。マシンで生成された時系列データは通常、短い間隔で収集されるため、予期しない変更が発生した場合は、発生後すぐに対応できます。データは急速に蓄積されるため、データを効率的に保存してクエリする方法が不可欠です。その結果、時系列データ用に最適化されたデータベースは、最近数年で人気が高まっています。

時系列データベース

時系列データベース (TSDB) は、時系列データ用に明示的に設計されたデータベースです。通常のデータベースを使用して測定値を保存することは可能ですが、TSDB にはいくつかの便利な最適化があります。

最新の TSDBsでは、測定値が追加されることはなく、ほとんど更新または削除されることもありません。例えば、各測定のタイムスタンプは時間の経過とともにほぼ変化するため、冗長データが保存されます。

次の例は、Unix タイムスタンプのシーケンスを示しています。

1572524345, 1572524375, 1572524404, 1572524434, 1572524464

これらのタイムスタンプを見ると、すべてのタイムスタンプが で始まり1572524、ディスク容量の使用率が低下します。代わりに、次の例に示すように、後続の各タイムスタンプを最初のタイムスタンプとの差分 または差分 として保存できます。

1572524345, +30, +29, +30, +30

次の例に示すように、これらの差分の差分の差分を計算することで、さらに手順を実行することもできます。

1572524345, +30, -1, +1, +0

測定値を定期的に行うと、そのほとんどは 0 delta-of-deltas になります。このような最適化により、TSDBs他のデータベースよりも大幅に少ない領域を使用します。

TSDB のもう 1 つの機能は、タグ を使用して測定値をフィルタリングできることです。各データポイントには、測定が行われた場所などのコンテキスト情報を追加するタグが付けられます。

Grafana では、次の TSDBs がサポートされています。

  • グラフ

  • InfluxDB

  • Prometheus

    weather,location=us-midwest temperature=82 1465839830100400200 | -------------------- -------------- | | | | | | | | | +-----------+--------+-+---------+-+---------+ |measurement|,tag_set| |field_set| |timestamp| +-----------+--------+-+---------+-+---------+
時系列データの収集

時系列を保存する場所ができたら、実際に測定値はどのように収集しますか? 時系列データを収集するには、通常、モニタリングするデバイス、マシン、またはインスタンスにコレクターをインストールします。一部のコレクターは特定のデータベースを念頭に置いて作成され、一部のコレクターは異なる出力先をサポートします。

コレクターの例をいくつか示します。

コレクターは、データをデータベースにプッシュするか、データベースがコレクターからデータを取得できるようにします。各アプローチには、独自の長所と短所があります。

長所 短所
プッシュする 複数の送信先にデータをレプリケートする方が簡単です。 TSDB には、送信されるデータの量を制御することはできません。
プル データの取り込み量とデータの信頼性をより詳細に制御できます。 ファイアウォール、VPNs、またはロードバランサーは、エージェントへのアクセスを困難にする可能性があります。

すべての測定値をデータベースに書き込むのは非効率であるため、コレクターはデータを事前に集計し、一定の間隔で TSDB に書き込みます。

時系列ディメンション

時系列データでは、多くの場合、データは複数の時系列のセットです。多くの Grafana データソースは、このタイプのデータをサポートしています。

一般的なケースは、1 つ以上の追加プロパティをディメンションとして測定に対して 1 つのクエリを発行することです。例えば、位置プロパティとともに温度測定値をクエリできます。この場合、1 つのクエリから複数のシリーズが返され、各シリーズにはディメンションとして一意の場所があります。

一連の時系列内の一意のシリーズを識別するために、Grafana はディメンションをラベル に保存します。

ラベル

Grafana の各時系列には、オプションでラベルがあります。ラベルは、ディメンションを識別するためのキーと値のペアのセットです。ラベルの例は {location=us}または です{country=us,state=ma,city=boston}。時系列のセット内では、名前とラベルの組み合わせによって各シリーズが識別されます。例えば、「temperature {country=us,state=ma,city=boston}」と入力します。

時系列データのさまざまなソースには、ネイティブに保存されたディメンション、またはデータをディメンションに抽出できる一般的なストレージパターンがあります。

通常、TSDBs次元をネイティブにサポートします。Prometheus は、ラベル にディメンションを保存します。Graphite や TSDBs などの TSDB では、代わりにタグという用語が使用されます。 OpenTSDB

SQL などのテーブルデータベースでは、これらのディメンションは通常、クエリのGROUP BYパラメータです。

テーブル形式の複数のディメンション

テーブルレスポンスを返す SQL または SQL のようなデータベースでは、追加のディメンションは通常、クエリレスポンステーブルの列です。

単一ディメンション

例えば、次の例のようなクエリがあるとします。

SELECT BUCKET(StartTime, 1h), AVG(Temperature) AS Temp, Location FROM T GROUP BY BUCKET(StartTime, 1h), Location ORDER BY time asc

クエリは、3 つの列を持つテーブルを返す場合があります。

StartTime Temp ロケーション
09:00 24 LGA
09:00 20 BOS
10:00 26 LGA
10:00 22 BOS

テーブル形式は長い形式の時系列で、高さは とも呼ばれます。Location では、タイムスタンプと値を繰り返しています。この場合、セット内の 2 つの時系列が Temp {Location=LGA}および として識別されますTemp {Location=BOS}

セットの個々の時系列は、次のディメンションを使用して抽出されます。

  • 時系列の時間インデックスStartTimeとして入力された時間型列

  • シリーズ名Tempとしての数値型列

  • Location=LGA など、ラベルを構築するための文字列型Location列の名前と値

複数のディメンション

複数の文字列列 ( などGROUP BY BUCKET(StartTime, 1h), Location, Sensor) を選択してグループ化するようにクエリが更新されると、ディメンションが追加されます。

StartTime Temp ロケーション センサー
09:00 24 LGA A
09:00 24.1 LGA B
09:00 20 BOS A
09:00 20.2 BOS B
10:00 26 LGA A
10:00 26.1 LGA B
10:00 22 BOS A
10:00 22.2 BOS B

この場合、ディメンションを表すラベルには、2 つの文字列型列 Locationおよび に基づく 2 つのキーがありますSensor。データは 4 つのシリーズになります。

  • Temp {Location=LGA,Sensor=A}

  • Temp {Location=LGA,Sensor=B}

  • Temp {Location=BOS,Sensor=A}

  • Temp {Location=BOS,Sensor=B}

注記

注: Grafana の複数のアラートに対応する方法では、複数のディメンションはサポートされていません。代わりに、1 つのアラートに対して複数の条件として扱われます。

複数の値

SQL のようなデータソースの場合、複数の数値列を選択できます。追加の文字列列はディメンションとして使用できます。例えば、 などですAVG(Temperature) AS AvgTemp, MAX(Temperature) AS MaxTemp。これにより、複数のディメンションと組み合わせると、多数のシリーズが発生する可能性があります。複数の値の選択は、現在、視覚化でのみ使用されるように設計されています。

ヒストグラムとヒートマップの概要

ヒストグラムは、数値データの分布をグラフィカルに表現したものです。値をバケット (ビンとも呼ばれます) にグループ化します。次に、各バケットに含まれる値をカウントします。

ヒストグラムは、実際の値をグラフ化する代わりに、バケットをグラフ化します。各バーはバケットを表し、バーの高さは、そのバケットの間隔に入る値の頻度 (カウントなど) を表します。

ヒストグラムは、特定の時間範囲における値の分布のみを調べます。ヒストグラムの問題は、時間の経過とともに分布の傾向や変化を確認できないことです。ここでは、ヒートマップが役立ちます。

ヒートマップ

ヒートマップは時間の経過に伴うヒストグラムのようなもので、各タイムスライスは独自のヒストグラムを表します。頻度を表すために棒の高さを使用する代わりに、セルを使用し、バケット内の値の数に比例してセルを色付けします。

バケット化されたデータ

次のような多くのデータソースが経時的なヒストグラムをサポートしています。

  • Amazon OpenSearch Service (ヒストグラムバケット集計を使用)

  • Prometheus (ヒストグラムメトリクスタイプ と Format as オプションをヒートマップ に設定)

通常、バケットバインドを表す名前のシリーズを返すデータソースや、バインドによって昇順にソートされたシリーズを返すデータソースを使用できます。

未加工データ対集計データ

通常の時系列データ (バケット化されていない) でヒートマップを使用する場合は、データが時系列バックエンドによってすでに集計されていることが多いことに注意してください。ほとんどの時系列クエリは raw サンプルデータを返しません。代わりに、グループごとの時間間隔または集計関数 (通常は平均) と組み合わされた maxDataPoints 制限が含まれます。

クエリの時間範囲によって異なります。重要な点は、Grafana が実行するヒストグラムバケット化が、すでに集計および平均化されたデータに対して行われる可能性があることを知っておくことです。より正確なヒートマップを行うには、メトリクスの収集中にバケット化を行うか OpenSearch、データを または生データに対してヒストグラムバケット化の実行をサポートする他のデータソースに保存することをお勧めします。

クエリでグループを時間単位で削除または下げる (または を増やす maxDataPoints) と、より多くのデータポイントを返す場合、ヒートマップはより正確になります。ただし、CPU とメモリに負荷がかかることもあります。データポイントの数が過度に大きくなると、停止やクラッシュが発生する可能性があります。