本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 建立您的第一個儀表板
## 建立儀表板
請依照下列步驟，在 Grafana 主控台中建立儀表板。
**建立您的第一個儀表板**
1. 選擇左側面板上的 \$1 圖示，選擇**建立儀表板**，然後選擇**新增面板**。
1. 在**新儀表板/編輯面板**檢視中，選擇**查詢**索引標籤。
1. 選取您要查詢的資料來源，以設定您的查詢。例如，如果您已將 **TestDB** 新增為資料來源，則會產生名為 Random Walk 儀表板的範例儀表板。
### 時間序列簡介
假設您想要知道外部溫度在一天當中的變化。每小時檢查一次溫度計，並記下時間與目前溫度。一段時間後，您會有類似下列的資料。
| 時間 | Value |
| --- | --- |
| 09：00 | 24°C |
| 10：00 | 26°C |
| 11：00 | 27°C |
像這樣的溫度資料是*時間序列*的一個範例：測量序列，按時間排序。資料表中的每一列代表特定時間的一個個別測量。
當您想要識別個別度量時，資料表非常有用，但它們可能會使得難以看到大局。時間序列的更常見視覺化是*圖形*，它會沿著時間軸放置每個測量。圖形等視覺化呈現方式可讓您更輕鬆地探索難以看到的資料模式和功能。
時間序列的其他範例包括：
+ CPU 和記憶體用量
+ 感應器資料
+ 股票市場索引
雖然每個範例都是依時間順序排序的一系列測量，但它們也會共用其他屬性：
+ 新資料會在結尾以固定間隔附加，例如每小時 09：00、10：00、11：00 等。
+ 很少會在新增後更新測量。例如，昨天的溫度不會變更。
時間序列功能強大。它們可讓您隨時分析系統的狀態，協助您了解過去。時間序列可以告訴您，在可用磁碟空間下降到零之後，伺服器損毀的時刻。
時間序列也可以透過發現資料中的趨勢來協助您預測未來。例如，如果在過去幾個月內，已註冊的使用者數量每月增加 4%，您可以預測您的使用者群在年底將達到多大。
某些時間序列具有在已知期間內自行重複的模式。例如，在夜間下降之前，溫度通常在一天中較高。透過識別這些定期或*季節性*的時間序列，您可以對下一個期間進行可信的預測。如果您知道系統每天大約 18：00 負載峰值，則可以在此之前新增更多機器。
#### 彙總時間序列
視您測量的內容而定，資料可能會有很大的差異。如果您想要比較比測量之間間隔更長的期間，該怎麼辦？ 如果您每小時測量一次溫度，您最後每天會有 24 個資料點。若要比較這幾年 8 月的溫度，您必須將 31 倍 24 個資料點合併為一個。
結合測量的集合稱為*彙總*。有多種方法可以彙總時間序列資料。以下是一些常見的：
+ **平均值**會傳回所有值的總和除以值的總數。
+ **最小值**和**最大值**會傳回集合中的最小和最大值。
+ **總**和會傳回集合中所有值的總和。
+ **Count** 會傳回集合中的值數目。
例如，透過在一個月內彙總資料，您可以判斷 2017 年 8 月平均比前一年更暖。如果您想要查看哪個月份的溫度最高，您可以比較每個月的最高溫度。
如何彙總時間序列資料是一項重要的決策，取決於您想要使用資料來告知的故事。使用不同的彙總以不同方式視覺化相同的時間序列資料是很常見的。
#### 時間序列和監控
在 IT 產業中，通常會收集時間序列資料來監控基礎設施、硬體或應用程式事件等物件。機器產生的時間序列資料通常會以短間隔收集，因此您可以在發生意外變更的時刻做出反應。資料會以快速的速度累積，因此擁有有效存放和查詢資料的方法至關重要。因此，針對時間序列資料最佳化的資料庫近幾年來越來越熱門。
##### 時間序列資料庫
時間序列資料庫 (TSDB) 是專門針對時間序列資料設計的資料庫。雖然可以使用任何一般資料庫來存放測量，但 TSDB 隨附一些有用的最佳化。
現代 TSDBs會利用只附加測量，且很少更新或移除的事實。例如，每個測量的時間戳記會隨著時間而變化很小，這會導致儲存冗餘資料。
下列範例顯示一系列的 Unix 時間戳記。
```
1572524345, 1572524375, 1572524404, 1572524434, 1572524464
```
查看這些時間戳記，它們都從 開始`1572524`，導致磁碟空間使用率不佳。相反地，您可以將每個後續時間戳記儲存為第一個時間戳記的差異或*差異*，如下列範例所示。
```
1572524345, +30, +29, +30, +30
```
您甚至可以透過計算這些差異的差異來進一步採取步驟，如下列範例所示。
```
1572524345, +30, -1, +1, +0
```
如果定期進行測量，這些delta-of-deltas的大部分都會是 0。由於這類最佳化，TSDBs 使用的空間比其他資料庫小得多。
TSDB 的另一個功能是能夠使用*標籤*篩選測量結果。每個資料點都會標記一個標籤，以新增內容資訊，例如測量的位置。
Grafana 支援下列 TSDBs：
+ [石榴](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|
+-----------+--------+-+---------+-+---------+
```
##### 收集時間序列資料
現在您有存放時間序列的位置，如何實際收集測量結果？ 若要收集時間序列資料，您通常會在要監控的裝置、機器或執行個體上安裝*收集器*。有些收集器是以特定資料庫為考量，有些則支援不同的輸出目的地。
以下是收集器的一些範例：
+ [已收集](https://collectd.org/)
+ [統計](https://github.com/statsd/statsd)
+ [Prometheus 匯出工具](https://prometheus.io/docs/instrumenting/exporters/)
+ [Telegraf](https://github.com/influxdata/telegraf)
收集器*會將資料推送*至資料庫，或讓資料庫從收集器*提取*資料。每個方法都有自己的一組優缺點。
| | 優點 | 缺點 |
| --- | --- | --- |
| 推送 | 更輕鬆地將資料複寫到多個目的地。 | TSDB 無法控制傳送的資料量。 |
| 提取 | 進一步控制資料擷取量和資料真實性。 | 防火牆、VPNs或負載平衡器可能會使存取代理程式變得困難。 |
由於將每個測量寫入資料庫效率低，收集器會預先彙總資料，並定期寫入 TSDB。
### 時間序列維度
使用時間序列資料時，資料通常是一組多個時間序列。許多 Grafana 資料來源支援這種類型的資料。
常見案例是以一個或多個額外的屬性做為維度，為測量發出單一查詢。例如，您可以查詢溫度測量以及位置屬性。在此情況下，會從該單一查詢傳回多個序列，而且每個序列都有唯一的位置做為維度。
若要識別一組時間序列內的唯一序列，Grafana 會將維度存放在*標籤*中。
#### 標籤
Grafana 中的每個時間序列都有標籤。標籤是一組用於識別維度的鍵值對。範例標籤為 `{location=us}`或 `{country=us,state=ma,city=boston}`。在一組時間序列中，其名稱和標籤的組合會識別每個序列。例如 `temperature {country=us,state=ma,city=boston}`。
不同的時間序列資料來源具有原生儲存的維度，或可讓資料擷取為維度的常見儲存模式。
通常，TSDBs原生支援維度。Prometheus 會將維度存放在*標籤*中。在 Graphite 或 OpenTSDB 等 TSDBs 中，會改用術語*標籤*。
在 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
```
查詢可能會傳回具有三個資料欄的資料表。
| StartTime | 暫存 | Location |
| --- | --- | --- |
| 09：00 | 24 | 拉瓜迪亞 |
| 09：00 | 20 | BOS |
| 10：00 | 26 | 拉瓜迪亞 |
| 10：00 | 22 | BOS |
資料表格式是*長*格式的時間序列，也稱為*高*。它具有重複的時間戳記，以及位置中的重複值。在這種情況下，集合中的兩個時間序列會識別為 `Temp {Location=LGA}`和 `Temp {Location=BOS}`。
使用下列維度擷取集合中的個別時間序列：
+ 時間類型欄`StartTime`作為時間序列的時間索引
+ `Temp` 做為序列名稱的數字類型欄
+ 要建置標籤之字串類型`Location`資料欄的名稱和值，例如 Location=LGA
##### 多個維度
如果查詢已更新為選取並依多個字串欄分組 （例如 `GROUP BY BUCKET(StartTime, 1h), Location, Sensor`)，則會新增額外的維度。
| StartTime | 暫存 | Location | 感測器 |
| --- | --- | --- | --- |
| 09：00 | 24 | 拉瓜迪亞 | A |
| 09：00 | 24.1 | 拉瓜迪亞 | B |
| 09：00 | 20 | BOS | A |
| 09：00 | 20.2 | BOS | B |
| 10：00 | 26 | 拉瓜迪亞 | A |
| 10：00 | 26.1 | 拉瓜迪亞 | B |
| 10：00 | 22 | BOS | A |
| 10：00 | 22.2 | BOS | B |
在此情況下，代表維度的標籤具有兩個以兩個字串類型欄為基礎的索引鍵，`Location`以及 `Sensor`。資料會產生四個序列：
+ `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 和記憶體造成繁重負載。如果資料點的數量變得不合理，可能會導致停滯和當機。