最初のダッシュボードを作成する - Amazon Managed Grafana
ダッシュボードの作成

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

最初のダッシュボードを作成する

ダッシュボードの作成

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

最初のダッシュボードを作成するには

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

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

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

時系列の概要

外の温度が 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 つに結合する必要があります。

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

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

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

  • 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 がサポートされています。

  • Graphite

  • InfluxDB

  • Prometheus 

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

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

コレクターの例を次に示します。

コレクターは、データをデータベースにプッシュするか、データベースがコレクターからデータをプルできるようにします。各アプローチには、独自の長所と短所のセットが付属しています。

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

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

時系列ディメンション

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

一般的なケースは、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

テーブル形式は長い形式の時系列で、Tall とも呼ばれます。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 (ヒストグラムメトリクスタイプとフォーマットをオプションとしてヒートマップに設定）

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

生データと集計データ

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

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

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