徹底理解Prometheus查詢語法

寫在前面

主要參考:https://github.com/yunlzheng/prometheus-book

本文檔主要分爲兩部分,分別講解PromQL和Grafana的基礎使用,在閱讀PromQL部分時,建議不要聯想Grafana中要怎麼使用這些查詢表達式,又是怎麼根據查詢結果繪圖的,因爲PromQL對於Grafana來說和SQL並沒有區別,都是查詢出結果,然後根據各種指定配置進行繪圖,所以閱讀和理解PromQL部分,應關注查詢結果是什麼樣的,不要關注這些結果在Grafana中是怎麼繪圖的。

1、理解時間序列

1.1指標

​ 指標就是要監控的目標。

​ 在形式上,所有的指標(Metric)都通過如下格式標示:

<metric name>{<label name>=<label value>, ...}

​ 指標名稱(metric name)一般反映被監控樣本的含義(比如,http_request_total - 表示當前系統接收到的HTTP請求總量)。

​ 標籤(label)反映了當前樣本的特徵維度,通過這些維度可以對樣本數據進行過濾,聚合等。

1.2樣本

​ Prometheus會定時到指定的Exportor上pull當前的樣本數據,然後根據pull的時間以時間序列的方式保存在內存數據庫中,並且定時持久化到硬盤上,Exportor只維護指標的值。每條時間序列由指標名稱(metrics)和一組標籤集(labelset)確定並命令,也就是說一個指標名稱可能對應很多條時間序列。

​ 可以將時間序列理解爲一個以時間爲軸的矩陣,如下所示,有三個時間序列在時間軸上分別對應不同的值:

  ^
  │     . . . . . . . . . .   node_cpu{cpu="cpu0",mode="idle"}
  │     . . . . . . . . . .   node_cpu{cpu="cpu0",mode="system"}
  │     . . . . . . . . . .   node_load1{}
  v
    <------- 時間 ---------->

​ 每一個點稱爲一個樣本(sample),樣本由以下三部分組成:

  • 指標(metric):metric name和描述當前樣本特徵的labelsets;
  • 時間戳(timestamp):一個精確到毫秒的時間戳;
  • (value):表示該時間的樣本的值。
<--------------- metric ---------------------><-timestamp -><-value->
http_request_total{status="200", method="GET"}@1434417560938 => 94355
http_request_total{status="200", method="GET"}@1434417561287 => 94334
http_request_total{status="404", method="GET"}@1434417560938 => 38473
http_request_total{status="404", method="GET"}@1434417561287 => 38544
http_request_total{status="200", method="POST"}@1434417560938 => 4748
http_request_total{status="200", method="POST"}@1434417561287 => 4785

​ 所以查詢值的where條件就是指標、標籤和時間戳(區間)。

2、查詢語法

2.1指標查詢(瞬時向量查詢)

通過指標名稱和標籤進行查詢,可以查詢該指標下的所有時間序列距離當前系統時間最新的值,無時間概念,所以查詢的結果稱爲瞬時向量(instant vector),如下圖所示:

在這裏插入圖片描述
而且可以看到查詢到的多條時間序列都包含指定的標籤。單獨使用指標名稱,相當於不使用標籤進行過濾,同樣獨單使用標籤查詢也可以。

標籤過濾支持使用=!=兩種完全匹配模式:

  • 通過使用label=value可以選擇那些標籤滿足表達式定義的時間序列;
  • 反之使用label!=value則可以根據標籤匹配排除時間序列;

除了使用完全匹配的方式對時間序列進行過濾以外,還支持使用正則表達式作爲匹配條件,多個正則表達式之間使用|進行分離:

  • 使用label=~regx表示選擇符合正則表達式定義的時間序列;
  • 反之使用label=!~regx進行反向選擇;

例如,如果想查詢多個環境下的請求數統計,可以使用如下表達式:

http_requests_total{environment=~"prodect|test|development",method!="GET"}

每個正則表達式就是簡單的字符串。

2.2時間範圍查詢(區間向量查詢)

​ 如果我們想過去一段時間範圍內的樣本數據時,我們則需要使用區間向量表達式。區間向量表達式和瞬時向量表達式之間的差異在於需要定義時間範圍,通過時間範圍選擇器[]進行定義。例如查詢距離當前系統時間最近5分鐘內的所有樣本數據

在這裏插入圖片描述
可以看到結果中每個時間序列都有5個值並且@了不同的時間戳(因爲該prometheus每分鐘pull一次,所以5分鐘有5個結果)。

除了使用m表示分鐘以外,PromQL的時間範圍選擇器支持其它時間單位:

  • s - 秒
  • m - 分鐘
  • h - 小時
  • d - 天
  • w - 周
  • y - 年

2.3時間位移

在瞬時向量表達式或者區間向量表達式中,都是以prometheus當前系統時間爲基準進行查詢:

http_request_total{} # 瞬時向量表達式,選擇當前最新的數據
http_request_total{}[5m] # 區間向量表達式,選擇以當前時間爲基準過去5分鐘內的所有數據

而如果我們想查詢5分鐘之前的最新數據,或者想查詢昨天的所有數據呢?

這個時候我們就可以使用位移操作,位移操作的關鍵字爲offset,例如:

 http_request_total{} offset 5m
 http_request_total{}[1d] offset 1d

2.4操作符

除了能夠方便的查詢和過濾時間序列以外,還支持豐富的操作符,用戶可以使用這些操作符進一步的對事件序列進行二次加工。這些操作符包括:數學運算符,邏輯運算符,布爾運算符等等。

數學運算符

操作數可以是一個常數,也可以是一個查詢表達式,比如:

bet_amount_total / 100 : bet_amount是投注金額的總計,經常單位是分,爲了轉成元,可以除以100

http_requests_total{api="/bet“} + http_requests_total{api="/login“} 計算投注和登錄請求的和

支持的所有數學運算符如下所示:

  • + (加法)
  • - (減法)
  • * (乘法)
  • / (除法)
  • % (求餘)
  • ^ (冪運算)

布爾運算符

通過布爾運算對時間序列進行過濾,例如如下想查詢node_cpu_seconds_total{mode=“idle”} > 22000的時間序列,不大於的時間序列會被過濾掉。

過濾前:
在這裏插入圖片描述
過濾後:
在這裏插入圖片描述
目前,Prometheus支持以下布爾運算符如下:

  • == (相等)
  • != (不相等)
  • > (大於)
  • < (小於)
  • >= (大於等於)
  • <= (小於

獲取布爾運算結果

布爾運算的默認行爲是對時間序列進行過濾。而有時候我們需要的是的運算結果。例如,只需要知道當前HTTP請求量是否>=1000,如果大於等於1000則返回1否則返回0。這時可以使用bool修飾符改變布爾運算的默認行爲。 例如:

http_requests_total > bool 1000

使用bool修飾符後,布爾運算不會對時間序列進行過濾,而是直接依次對各個樣本數據進行比較,結果是0或者1。從而形成一條新的時間序列,如下圖value等於0或者1:
在這裏插入圖片描述

2.5聚合函數

查詢可能會返回多條滿足指定標籤的時間序列,可是有時候我們並不希望分開查看,恰恰大多數情況其實是想查詢一條時間序列的結果,例如查詢請求總數時想要的結果是:

http_requests_total{} 170

而並不是想要:

http_requests_total{environment="product“} 30

http_requests_total{environment="test“} 60

http_requests_total{environment="developement“} 80

爲了實現這個需求,PromQL提供的聚合操作可以用來對這些時間序列進行處理,通過處理形成一條新的時間序列,上述需求的表達式應該是:sum(http_requests_total),例如下圖會自動將所有時間序列的值相加後形成一條新的時間序列作爲結果。
在這裏插入圖片描述
sum函數非常常用,因爲常常不知道查詢到時間序列究竟又多少條,注意不要再誤認爲sum是求指標在某個時間段的和。

有下面這些聚合操作符:

  • sum:求和。
  • min:最小值。
  • max:最大值
  • avg:平均值
  • stddev:標準差
  • stdvar:方差
  • count:元素個數
  • count_values:等於某值的元素個數
  • bottomk:最小的 k 個元素
  • topk:最大的 k 個元素
  • quantile:分位數

部分聚合

有時候,聚合並不想完全聚合,想根據某個標籤進行區分時候,可以使用by進行拆分,比如監控每個cpu累計的空閒時間:sum(node_cpu_seconds_total{mode=“idle”} )by (cpu),並設置了時間序列的名稱模式爲:cpu-{{cpu}}

圖示:
在這裏插入圖片描述

2.6內置函數

爲了方便查詢,Prometheus 內置了一些函數來輔助計算,下面介紹一些典型的。

  • instant-vector abs(instant-vector):絕對值
  • instant-vector sqrt(instant-vector)):平方根
  • instant-vector exp(instant-vector ):指數計算
  • instant-vector ln(instant-vector ):自然對數
  • instant-vector ceil(instant-vector ):向上取整
  • instant-vector floor(instant-vector ):向下取整
  • instant-vector round(instant-vector ):四捨五入取整
  • instant-vector delta(range-vector):計算區間向量裏最大最小的差值
  • instant-vector increase(range-vector):計算區間向量裏最後一個值和第一個值的差值
  • instant-vector rate(range-vector):計算區間向量裏的平均增長率

然而在實際使用中,發現increase函數計算有誤差,比如一分鐘的前值和後值分別是1和183,差值應該是182,但是increase(metric[1m])185使{metric}[1m])的結果是185,使用{metric} - ${metric} offset 1的結果卻是正確的182。誤差原因目前還沒有確定。

3、指標分類(瞭解)

Prometheus根據目標功能和內容的不同,把指標分了4種類型(metric type):Counter(計數器)、Gauge(儀表盤)、Histogram(直方圖)、Summary(摘要);但是本質上都是指標,都是時間序列,只是進行了簡單的分類,更方便理解和溝通。

3.1Counter:只增不減的計數器

Counter類型的指標其工作方式和計數器一樣,只增不減(除非系統發生重置)。常見的監控指標,如http_requests_total,node_cpu都是Counter類型的監控指標。

Counter是一個簡單但有強大的工具,例如我們可以在應用程序中記錄某些事件發生的次數,通過以時序的形式存儲這些數據,我們可以輕鬆的瞭解該事件產生速率的變化。PromQL內置的聚合函數可以用戶對這些數據進行進一步的分析:

例如,通過rate()函數獲取HTTP請求量的增長率:

rate(http_requests_total[5m])

查詢當前系統中,訪問量前10的HTTP地址:

topk(10, http_requests_total)

3.2Gauge:可增可減的儀表盤

與Counter不同,Gauge類型的指標側重於反應系統的當前狀態。因此這類指標的樣本數據可增可減。常見指標如:node_memory_MemFree(主機當前空閒的內容大小)、node_memory_MemAvailable(可用內存大小)都是Gauge類型的監控指標。

通過Gauge指標,用戶可以直接查看系統的當前狀態:

node_memory_MemFree

對於Gauge類型的監控指標,通過PromQL內置函數delta()可以獲取樣本在一段時間返回內的變化情況。例如,計算CPU溫度在兩個小時內的差異:

delta(cpu_temp_celsius{host="zeus"}[2h])

3.3Histogram和Summary:數據分佈

除了Counter和Gauge類型的監控指標以外,Prometheus還定義分別定義Histogram和Summary的指標類型,主用用於統計和分析樣本的分佈情況。

在大多數情況下,我們都傾向於使用某些量化指標的平均值,例如CPU的平均使用率、頁面的平均響應時間。這種方式的問題很明顯,以系統API調用的平均響應時間爲例:如果大多數API請求都維持在100ms的響應時間範圍內,而個別請求的響應時間需要5s,那麼就會導致某些WEB頁面的響應時間落到中位數的情況,而這種現象被稱爲長尾問題。

爲了區分是平均的慢還是長尾的慢,最簡單的方式就是按照請求延遲的範圍進行分組。例如,統計延遲在010ms之間的請求數有多少而1020ms之間的請求數又有多少。通過這種方式可以快速分析系統慢的原因。Histogram和Summary都是爲了能夠解決這樣問題的存在,通過Histogram和Summary類型的監控指標,我們可以快速瞭解監控樣本的分佈情況。

例如,Prometheus自身監控的指標【prometheus_tsdb_wal_fsync_duration_seconds】的指標類型爲Summary。 它記錄了Prometheus Server中wal_fsync操作的耗時,通過訪問Prometheus Server的/metrics地址,可以獲取到以下監控樣本數據(當前時間的樣本):

# HELP prometheus_tsdb_wal_fsync_duration_seconds Duration of WAL fsync.
# TYPE prometheus_tsdb_wal_fsync_duration_seconds summary
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173
prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002
prometheus_tsdb_wal_fsync_duration_seconds_count 216

從上面的樣本中可以得知當前Prometheus Server進行wal_fsync操作的總次數爲216次,總耗時爲2.888716127000002s,並且50%操作耗時不超過0.012352463秒,90%的操作耗時不超過0.014458005s,99%的操作耗時不超過0.017316173s。

在Prometheus自身監控中,我們還能找到類型爲Histogram的監控指標:prometheus_tsdb_compaction_chunk_range_bucket。

# HELP prometheus_tsdb_compaction_chunk_range Final time range of chunks on their first compaction
# TYPE prometheus_tsdb_compaction_chunk_range histogram
prometheus_tsdb_compaction_chunk_range_bucket{le="100"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="400"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="1600"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="6400"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="25600"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="102400"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="409600"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="1.6384e+06"} 260
prometheus_tsdb_compaction_chunk_range_bucket{le="6.5536e+06"} 780
prometheus_tsdb_compaction_chunk_range_bucket{le="2.62144e+07"} 780
prometheus_tsdb_compaction_chunk_range_bucket{le="+Inf"} 780
prometheus_tsdb_compaction_chunk_range_sum 1.1540798e+09
prometheus_tsdb_compaction_chunk_range_count 780

從上面的樣本中可以得知當前Prometheus Server tsdb數據庫的壓縮後數據庫共有780個,總大小是1.1540798e+09,小於等於100/400/1600/…/409600的有0

與Summary類型的指標相似之處在於Histogram類型的樣本同樣會反應當前指標的記錄的總數(以_count作爲後綴)以及其值的總量(以_sum作爲後綴)。不同在於Histogram指標直接反應了在不同區間內樣本的個數,區間通過標籤len進行定義。

同時對於Histogram的指標,我們還可以通過histogram_quantile()函數計算出其值的分位數。和Summary不同在於Histogram通過histogram_quantile函數在服務器端計算的分位數,即prometheus計算; 而Sumamry的分位數則是由客戶端計算,prometheus直接pull即可。因此對於分位數的計算而言,Summary在通過PromQL進行查詢時有更好的性能表現,而Histogram則會消耗更多的資源;反之對於客戶端而言Histogram消耗的資源更少。

# 查詢 prometheus_tsdb_compaction_chunk_range 95 百分位

histogram_quantile(0.95, prometheus_tsdb_compaction_chunk_range_bucket)

4、HTTP API

4.1Grafana查詢報錯

比如想在Grafana繪製折線圖(Graph),因爲需要很多時間點的值,似乎應該使用時間範圍查詢或者說是區間查詢,因爲指標查詢(瞬時查詢)只能查詢的當前的最新值,讓我們試一試:
在這裏插入圖片描述
紅色歎號錯誤提示:

“invalid expression type “range vector” for range query, must be Scalar or instant Vector”

非法的表達式類型:區間向量用於區間查詢,必須是標量(常數)或者瞬時向量。

這是因爲在Grafana查詢需要調用prometheus的http api,所以首先了解prometheus的http api是什麼?

4.query

通過使用如下API我們可以查詢PromQL表達式在指定時間點下的計算結果。

GET /api/v1/query

URL請求參數:

  • query=:PromQL表達式。
  • time=:指定時間戳。可選參數,默認情況下使用Prometheus當前系統時間。

例如:

$ curl 'http://192.168.40.161:9090/api/v1/query?query=node_cpu_seconds_total{mode="idle"}&time=1587690566.034'
{
  "status": "success",
  "data": {
    "resultType": "vector",
    "result": [
      {
        "metric": {
          "__name__": "node_cpu_seconds_total",
          "cpu": "0",
          "instance": "192.168.40.161:9100",
          "job": "linux",
          "mode": "idle"
        },
        "value": [
          1587690566.034,
          "24745.92"
        ]
      },
      {
        "metric": {
          "__name__": "node_cpu_seconds_total",
          "cpu": "1",
          "instance": "192.168.40.161:9100",
          "job": "linux",
          "mode": "idle"
        },
        "value": [
          1587690566.034,
          "24846.7"
        ]
      }
    ]
  }
}

響應數據類型

當API調用成功後,Prometheus會返回JSON格式的響應內容,格式如上小節所示。並且在data節點中返回查詢結果。data節點格式如下:

{
  "resultType": "matrix" | "vector",
  "result": <value>
}

PromQL表達式可能返回多種數據類型,在響應內容中使用resultType表示當前返回的數據類型,包括:

  • 瞬時向量:vector

當返回數據類型resultType爲vector時,result響應格式如下:

[
  {
    "metric": { "<label_name>": "<label_value>", ... },
    "value": [ <unix_time>, "<sample_value>" ]
  },
  ...
]

其中metrics表示當前時間序列的特徵維度,value只包含一個唯一的樣本。

  • 區間向量:matrix

當返回數據類型resultType爲matrix時,result響應格式如下:

[
  {
    "metric": { "<label_name>": "<label_value>", ... },
    "values": [ [ <unix_time>, "<sample_value>" ], ... ]
  },
  ...
]

其中metrics表示當前時間序列的特徵維度,values包含當前事件序列的一組樣本,例如:

$ curl 'http://192.168.40.161:9090/api/v1/query?query=node_cpu_seconds_total{mode="idle"}[5m]&time=1587690566.034'

{
  "status": "success",
  "data": {
    "resultType": "matrix",
    "result": [
      {
        "metric": {
          "__name__": "node_cpu_seconds_total",
          "cpu": "0",
          "instance": "192.168.40.161:9100",
          "job": "linux",
          "mode": "idle"
        },
        "values": [
          [
            1587690266.034,
            "24499.47"
          ],
          [
            1587690326.034,
            "24548.82"
          ],
          [
            1587690386.034,
            "24598.17"
          ],
          [
            1587690446.034,
            "24648.21"
          ],
          [
            1587690506.034,
            "24697.37"
          ],
          [
            1587690566.034,
            "24745.92"
          ]
        ]
      },
      {
        "metric": {
          "__name__": "node_cpu_seconds_total",
          "cpu": "1",
          "instance": "192.168.40.161:9100",
          "job": "linux",
          "mode": "idle"
        },
        "values": [
          [
            1587690266.034,
            "24600.32"
          ],
          [
            1587690326.034,
            "24649.97"
          ],
          [
            1587690386.034,
            "24698.96"
          ],
          [
            1587690446.034,
            "24747.99"
          ],
          [
            1587690506.034,
            "24797.52"
          ],
          [
            1587690566.034,
            "24846.7"
          ]
        ]
      }
    ]
  }
}

4.3query_range

使用如下API,我們可以查詢PromQL表達式一段時間內的數據。

GET /api/v1/query_range

URL請求參數:

  • query=: PromQL表達式。
  • start=: 起始時間。
  • end=: 結束時間。
  • step=: 查詢步長。

返回結果一定是一個區間向量:

{
  "resultType": "matrix",
  "result": <value>
}

比如

$ curl 'http://192.168.40.161:9090/api/v1/query_range?query=node_cpu_seconds_total{mode="idle"}&start=1587693926.035&end=1587694166.034&step=2m'

{
  "status": "success",
  "data": {
    "resultType": "matrix",
    "result": [
      {
        "metric": {
          "__name__": "node_cpu_seconds_total",
          "cpu": "0",
          "instance": "192.168.40.161:9100",
          "job": "linux",
          "mode": "idle"
        },
        "values": [
          [
            1587693926.035,
            "27510.45"
          ],
          [
            1587694046.035,
            "27607.39"
          ]
        ]
      },
      {
        "metric": {
          "__name__": "node_cpu_seconds_total",
          "cpu": "1",
          "instance": "192.168.40.161:9100",
          "job": "linux",
          "mode": "idle"
        },
        "values": [
          [
            1587693926.035,
            "27645.27"
          ],
          [
            1587694046.035,
            "27743.97"
          ]
        ]
      }
    ]
  }
}

需要注意的是,只能使用瞬時向量類型的表達式

這是因爲區間數據查詢實現,首先根據時間範圍和步長計算時間點集合,比如

start=1s & end=60s & setp=10s,

那麼時間點集合是:1s 、11s、21s、31s、41s、51s

因爲下一個時間點應該是61s,不在時間範圍內。

然後查詢距離每個時間點最近的值作爲該時間點的值。

而如果使用區間向量表達式,那麼每個時間點計算結果將是一個區間,而目標查詢結果也是區間,並且兩個區間的含義不相同,所以無法融合在一塊。

4.4Grafana報錯原因

Grafana默認調用的api是query_range api,可通過【Query Inspector】按鈕展開查詢請求和結果,如下圖:
在這裏插入圖片描述
所以Graph中不能直接使用區間向量查詢,而應該使用瞬時向量,然後調用區間數據查詢API來查詢指定時間範圍的值(時間範圍是Grafana面板右上角選擇的時間範圍,步長默認15秒,可通過Min step設置)。
在這裏插入圖片描述
Graph通過查詢結果中的各個時間點的值繪製成線。
可以通過開啓Instant開關,使Grafana調用瞬時數據查詢API,例如:
在這裏插入圖片描述
可以看到api改成了query,並且prometheus返回了5個時間點的值,此時Graph不會連接成線。

4.5區間向量的應用

前面說到通過瞬時向量查詢+query_rangw API可以查詢到指定時間範圍的值,那麼區間向量查詢似乎沒啥用了?
區間向量可用於計算某個時間點的附近的狀態,通過內置函數可以將區間向量轉成瞬時向量,就能用在Graph圖中了;比如返回時間範圍內中每個時間點的過去1分鐘內 HTTP 請求數:increase(http_requests_total[1m])

5、Grafana配置方法

通過前面的學習,我們知道如何編寫Prometheus查詢表達式,也知道Grafana通過調用HTTP API接口來查詢時間序列的,可能查到很多條時間序列,查詢結果中每個時間序列可能只有最新的值,也可能包含一個時間範圍內很多個值。接下來,講解Grafana提供了那些數據展示方法,以及如何使用查詢結構。

5.1Graph

Graph默認以時間爲X軸展示所有查詢到的時間序列,如下圖所示,查詢到兩條時間序列:
在這裏插入圖片描述
右上角按鈕【Last 5 minutes】指定時間範圍,可以改爲其他的時間範圍。注意這裏的Last 5 Time的時間基準是Grafana頁面所在PC機的當前時間,如果PC機的時間異常,可能查詢到的並不是目標時間範圍的數據,比如系統當前時間是12:05:00,那麼Last 5 minutes的時間範圍會轉換成:start=12:00:00&end=12:05:00。具體的請求和響應信息,可以通過按鈕【Query Inspector】展示。

通過按鈕【Add Query】可以添加查詢表達式,需要注意的是一條查詢語句可以展示多條線,這取決於查詢結果中有多少條時間序列。

通過指定【Min step】可以修改步長,可以改變查詢結果中時間點的密度,即步長越大,則相同時間範圍的時間點就越少,密度就越小,那麼折線可能更陡峭。

5.2SingleStat

顯示查詢結果中最新的一個值,查詢結果不能包含多條時間序列,否者提示錯誤。如果未開啓Instant,則可顯示指定時間範圍內的變化曲線,如果開啓Instant則僅顯示一個數值;
在這裏插入圖片描述
支持設置閾值來顯示不同的顏色,例如大於0.5顯示紅色:
在這裏插入圖片描述
Stat和SingStat基本一樣,不同的是Stat支持查詢並顯示多條時間序列的變化曲線和值。

5.4Gauge

和SingleStat一樣,也是顯示查詢結果中最新的一個值,支持一次查詢多條時間序列,例如下圖一個表達式返回兩條時間序列:
在這裏插入圖片描述
也可以設置閾值來顯示不同的顏色,例如上圖小於0.5時顯示綠色,大於0.5時內邊填充黃色,更加醒目,並且在儀表盤的邊上根據值的分佈動態顯示綠色和黃色的比例。

5.5Table

默認情況下,表格顯示所有時間序列在不同時間點上的值,最左列是時間戳對應的時間,後邊就是所有指標對用的值:
在這裏插入圖片描述
如果開啓Instant,則只顯示最新的時間戳和最新的值:
在這裏插入圖片描述
可通過【Column Styles】對列進行設置:

(1)隱藏列:設置列的Type是Hidden
在這裏插入圖片描述
(2)設置列的值:比如設置某列爲查詢表達式B的值,設置名稱正則【Apply to columns named】爲 Value #B
在這裏插入圖片描述
如果想顯示某個標籤的值,那麼【Apply to columns named】就是標籤的名字。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章