翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 最初のダッシュボードの作成
## ダッシュボードの作成
Grafana コンソールでダッシュボードを作成するには、以下の手順に従います。
**最初のダッシュボードを作成する方法**
1. 左パネルの \$1 アイコンを選択して **[ダッシュボードの作成]** を選択し、**[新しいパネルを追加]** を選択します。
1. **[新しいダッシュボード/パネルの編集]** ビューで、**[クエリ]** タブを選択します。
1. クエリするデータソースを選択してクエリを設定します。例えば、データソースとして **[TestDB]** を追加する場合、ランダムウォークダッシュボードと呼ばれるサンプルダッシュボードが生成されます。
### 時系列の概要
1 日を通じた外気温の変化について知りたいとします。1 時間に 1 回温度計を確認して、現在の温度と時刻を書き留めます。しばらくすると、次のようなデータが集まります。
| Time | 値 |
| --- | --- |
| 09:00 | 24°C |
| 10:00 | 26°C |
| 11:00 | 27°C |
このような温度データは*時系列*の一例で、時間順の一連の測定です。テーブルの各行は、特定の時間の 1 つの測定値を表します。
テーブルは個々の測定値の識別に役立ちますが、全体像の確認が難しい場合があります。より一般的な時系列の視覚化は*グラフ*で、各測定値が時間軸に沿って配置されます。グラフなどの視覚的表現を使用すると、確認するのが難しいデータのパターンや特徴を簡単に発見できます。
以下のものは時系列のその他の例です。
+ CPU およびメモリの使用量
+ センサーデータ
+ 株式市場指数
これらの例は時系列順に測定された数列ですが、以下の属性も共有しています。
+ 新しいデータは、09:00、10:00、11:00 などのように、一定間隔で最後に追加されます。
+ 測定値が追加後に更新されることはほとんどありません。例えば、昨日の温度は変更されません。
時系列には説得力があります。いつでもシステムの状態を分析できるため、過去について理解するのに役立ちます。時系列を見れば、空きディスクスペースが 0 になった直後にサーバーがクラッシュしたことがわかります。
時系列を使用するとデータの傾向が明らかになり、未来の予測にも役立ちます。例えば、過去数か月間に登録されたユーザー数が毎月 4% 増加している場合、年末にユーザーベースがどの程度大きくなるかを予測できます。
一部の時系列には、既知の期間全体で繰り返すパターンがあります。例えば、通常の場合気温は日中高くなってから夜間に低下します。これらの周期的、または*季節的な*時系列を特定すると、自信をもって次の期間を予測できます。システム負荷が毎晩 6 時頃にピークに達することがわかっている場合、直前に機器を追加できます。
#### 時系列の集計
測定内容が異なると、データが大きく異なる場合があります。測定間隔よりも長い期間を比較する場合はどうしますか? 温度を 1 時間に 1 回測定する場合、1 日あたり 24 のデータポイントが集まります。長年にわたる 8 月の気温を比較するには、31 x 24 のデータポイントを 1 つに結合する必要があります。
測定値の集合を組み合わることを*集計*と呼びます。時系列データの集計方法はいくつかあります。以下は一般的な方法です。
+ **平均**は、すべての値の合計を値の数で割ったものを返します。
+ **最小**と**最大**は、コレクション内の最小値と最大値を返します。
+ **合計**はコレクションのすべての値を返します。
+ **カウント**はコレクション内の値の数を返します。
例えば、1 か月のデータを集計すると、2017 年 8 月が平均で前年より温かかったと判断できます。最も高い温度の月を確認する場合は、各月の最高温度を比較します。
時系列データの集計方法の決定は重要であり、データを使用して伝える目的によって異なります。一般的には、異なる集計を使用して、同じ時系列データを異なる方法で視覚化します。
#### 時系列およびモニタリング
IT 業界では、インフラストラクチャ、ハードウェア、アプリケーションなどの各イベントを監視するために時系列データが頻繁に収集されます。機械生成された時系列データは通常短い間隔で収集されるため、予期しない変更への対応や、発生直後の対応が可能です。データは速いペースで蓄積されるため、データを効率的に保存してクエリする方法を持つことが必要となります。その結果、時系列データ用に最適化されたデータベースの人気が近年高まっています。
##### 時系列データベース
時系列データベース (TSDB) は、時系列データのために明示的に設計されたデータベースです。通常のデータベースを使用して測定値を保存することもできますが、TSDB にはいくつかの便利な最適化が用意されています。
最新の TSDB では、測定値が追加されるのが 1 回のみで、更新または削除されることかせほとんどないという事実を活用しています。例えば、各測定のタイムスタンプは時間が経過してもほとんど変化せず、冗長データが保存されます。
次の例は Unix タイムスタンプの数列を示しています。
```
1572524345, 1572524375, 1572524404, 1572524434, 1572524464
```
これらのタイムスタンプを見ると、すべて `1572524` で始まり、ディスクスペースの使用が中途半端になります。代わりに、次の例のように、後続の各タイムスタンプを最初のタイムスタンプとの差、つまり*差分*として保存できます。
```
1572524345, +30, +29, +30, +30
```
次の例のように、これらの差分の差分を計算することもできます。
```
1572524345, +30, -1, +1, +0
```
測定が周期的に行われる場合、これらの差分の差分の大半は 0 になります。このように最適化することにより、TSDB が使用するスペースは他のデータベースよりも大幅に少なくなります。
TSDB のもう 1 つの特徴は*タグ*を使用して測定値をフィルタリングする機能です。各データポイントには、測定場所などのコンテキスト情報を追加するタグが用意されています。
Grafana では次の TSDB がサポートされています。
+ [Graphite](https://graphiteapp.org/)
+ [InfluxDB](https://www.influxdata.com/products/influxdb-overview/)
+ [Prometheus](https://prometheus.io/)
```
weather,location=us-midwest temperature=82 1465839830100400200
| -------------------- -------------- |
| | | |
| | | |
+-----------+--------+-+---------+-+---------+
|measurement|,tag_set| |field_set| |timestamp|
+-----------+--------+-+---------+-+---------+
```
##### 時系列データの収集
時系列の保存場所ができましたが、測定値はどのように収集しますか? 時系列データを収集するには、通常、モニタリングするデバイス、機器、またはインスタンスに*コレクタター*をインストールします。一部のコレクターは特定のデータベースを念頭に置いて作成されており、一部のコレクターでは異なる出力先をサポートしています。
以下のものはコレクターの例です
+ [collectd](https://collectd.org/)
+ [statsd](https://github.com/statsd/statsd)
+ [Prometheus exporters](https://prometheus.io/docs/instrumenting/exporters/)
+ [Telegraf](https://github.com/influxdata/telegraf)
コレクターは、データベースにデータを*プッシュ*するか、データベースにコレクターのデータを*プル*させます。各アプローチにはそれぞれ長所と短所があります。
| | 長所 | 短所 |
| --- | --- | --- |
| プッシュ | 複数の送信先にデータをレプリケーションする方が簡単です。 | TSDB は送信データの量を制御することはできません。 |
| プルl | データインジェストの量とデータの信頼性をより細かく制御できます。 | ファイアウォール、VPN またはロードバランサーでは、エージェントへのアクセスが難しくなる場合があります。 |
すべての測定値をデータベースに書き込むのは非効率なので、コレクターはデータを事前に集約して TSDB に周期的に書き込みます。
### 時系列のディメンション
時系列データでは、多くの場合データは複数の時系列セットです。多くの Grafana データソースでは、このタイプのデータをサポートしています。
よくある例では、ディメンションとして複数の追加プロパティを使用する測定に対して単一のクエリを発行します。例えば、ロケーションプロパティを使用して温度測定値をクエリします。この場合、その単一のクエリから複数のシリーズが返され、シリーズごとにディメンションとして一意の場所があります。
一連の時系列で一意のシリーズを識別するために、Grafana は*ラベル*にディメンションを保存します。
#### ラベル
Grafana の各時系列にはオプションのラベルがあります。ラベルはディメンションを識別するための、一組のキーと値のペアです。ラベルの例は `{location=us}` または `{country=us,state=ma,city=boston}` です。一連の時系列内では、名前とラベルの組み合わせによって各シリーズが識別されます。例えば、`temperature {country=us,state=ma,city=boston}`。
時系列データのさまざまなソースには、ネイティブに保存されるディメンションがあるか、データをディメンションに抽出するための一般的なストレージパターンがあります。
通常、TSDB はディメンションをネイティブにサポートします。Prometheus では*ラベル*でディメンションを保存します。Graphite や OpenTSDB などの TSDB では、代わりに*タグ*という用語を使用しています。
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 |
テーブル形式は*ロング*形式の時系列で、*トール*とも呼ばれます。ロケーションには繰り返しタイムスタンプと繰り返し値があります。この場合、セット内の 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 つの文字列型列に基づく 2 つのキー `Location` と `Sensor` があります。データは以下の 4 つのシリーズになります。
+ `Temp {Location=LGA,Sensor=A}`
+ `Temp {Location=LGA,Sensor=B}`
+ `Temp {Location=BOS,Sensor=A}`
+ `Temp {Location=BOS,Sensor=B}`
**注記**
**注:** Grafana で複数のアラートにマッピングする手法では、複数のディメンションをサポートしていません。代わりに、単一アラートに対する複数条件として扱われます。
##### 複数値
SQL のようなデータソースでは、ディメンションとして使用する追加文字列の列の有無にかかわらず、`AVG(Temperature) AS AvgTemp, MAX(Temperature) AS MaxTemp` のように、複数の数値列を選択できます。これにより、複数のディメンションと組み合わせると、多数のシリーズが発生する場合があります。今のところ複数値の選択は視覚化でのみ使用できます。
### ヒストグラムおよびヒートマップの概要
ヒストグラムは数値データの分布をグラフィカルに表現したものです。値をグループ化してバケット (ビンとも呼ばれる) にします。次に、各バケットに含まれる値の数を数えます。
ヒストグラムでは、実際の値をグラフ化する代わりにバケットをグラフ化します。各バーはバケットを表し、バーの高さはバケットの間隔に含まれる値の頻度 (カウントなど) を表します。
ヒストグラムは特定の時間範囲の*値分布*のみを検討します。ヒストグラムの問題は、時間が経過しても、その分布に傾向や変化が見られないことです。そこではヒートマップが役に立ちます。
#### ヒートマップ
*ヒートマップ*は経時的ヒストグラムのようなもので、各タイムスライスがそのヒストグラムを表します。頻度表現としてバーの高さの代わりにセルを使用し、バケット内の値数に比例してセルを色付けします。
#### バケット化済みデータ
多くのデータソースは、次のような経時的ヒストグラムをサポートしています。
+ Amazon OpenSearch Service (ヒストグラムバケットの集計を使用)
+ Prometheus ([ヒストグラム](https://prometheus.io/docs/concepts/metric_types/#histogram)のメトリクスタイプと *形式* オプションを **[ヒートマップ]** に設定)
通常は、バケットバウンドを表す名前のシリーズを返すデータソースや、バウンドで昇順にソートされたシリーズを返すデータソースを使用できます。
#### 未加工データ対集計データ
ヒートマップを通常の (バケット化されていない) 時系列データで使用する場合は、データが時系列バックエンドによって集計済みであることが多いことに注意してください。大抵の時系列クエリは未加工サンプルデータを返しません。代わりに、時間間隔または maxDataPoints 制限を集計関数 (通常は平均) と組み合わせたグループが含まれます。
クエリの時間範囲に応じて異なります。重要なのは、Grafana が実行するヒストグラムバケット処理が、既に集計され平均化済みのデータに対して実行される場合があることを理解することです。より正確なヒートマップを得るには、メトリクス収集中にバケット処理を行うか、OpenSearch にデータを保存するか、未加工データに対してヒストグラムバケット処理の実行をサポートする他のデータソースに保存することをお勧めします。
より多くのデータポイントを返すために、クエリ内のグループを削除または時間によって減らす (または maxDataPoints を増やす) と、ヒートマップはより正確になります。ただし CPU とメモリに負荷がかかる場合もあります。データポイントの数をむやみに多くすると、フリーズやクラッシュする場合があります。