grafana面板配置opentsdb

新增面板：
这里add-panel:

如果不是想新增面板而是想新增一行条目，则点击convert to row:

在新增的面板这里可以看到选择数据源

Aggregator：聚合条件，区分下第一行和第二行的aggregator，第一个是对指标值的聚合，第二个是对采样周期里的聚合
Alias：别名，根据需要进行自定义
这里的filter是用于过滤数据，主要有几种：
literal_or
获取单个文字值或一个 | 管道分隔的值列表，并以区分大小写的方式返回与结果匹配的任何时间序列。 这是一个非常有效的过滤器，因为它可以将字符串解析为 UID 并将其发送到存储层进行预过滤。 在 SQL 中，这类似于 IN 或 = 谓词。
Examples
host=literal_or(web01|web02|web03) In SQL: WHERE host IN (‘web01’, ‘web02’, ‘web03’)
host=literal_or(web01) In SQL: WHERE host = ‘web01’
iliteral_or
与 literal_or 相同，但不区分大小写。 请注意，这不像文字那样有效，或者因为它必须对存储中的所有行进行后处理。
not_literal_or
区分大小写的 literal_or 将返回与给定值列表 NOT 匹配的系列。 高效，因为它可以通过存储进行预处理。
not_iliteral_or
不区分大小写的not_literal_or。
regexp： tagv的过滤规则: 正则表达式匹配
wildcard： tagv的过滤规则: 通配符匹配，大小写敏感
iwildcard： tagv的过滤规则: 通配符匹配，忽略大小写

在使用 OpenTSDB 2.2 数据源时，请确保使用 Filters 或 Tags，因为它们是互斥的。如果同时使用，可能会得到奇怪的结果。
面板的json数据：

变量

name: 变量名，比如我这里取名为ip，到时候要使用这个变量名就用$ip来调用。

type: 变量类型，变量类型有多种，其中query表示这个变量是一个查询语句，type也可以是datasource，datasource就表示该变量代表一个数据源，如果是datasource你可以用该变量修改整个DashBoard的数据源，变量类型还可以是时间间隔Interval等等。这里我们选择query。

label: 是对应下拉框的名称，默认就是变量名，选择默认即可。

hide: 有三个值，分别为空，label，variable。选择label，表示不显示下拉框的名字。选择variable表示隐藏该变量，该变量不会在DashBoard上方显示出来。默认选择为空，这里也选默认。

Query options

Data source: 数据源

Refresh: 何时去更新变量的值，变量的值是通过查询数据源获取到的，但是数据源本身也会发生变化，所以要时不时的去更新变量的值，这样数据源的改变才会在变量对应的下拉框中显示出来。Refresh有三个值可以选择，Never：永不更新。On Dashboard Load：在DashBoard加载时更新。On Time Range Change：在时间范围变化时更新。此处，选择On Dashboard Load，当数据源发生更新是，刷新一下当前DashBoard，变量的值也会跟着发生更新。

Query：查询表达式，不同的数据源查询表达式都不同（这些可以到官网上查询：http://docs.grafana.org/features/datasources/）。

Regex：正则表达式，用来对抓取到的数据进行过滤，这里默认不过滤。

Sort：排序，对下拉框中的变量值做排序，排序的方式挺多的，默认是disable，表示查询结果是怎样下拉框就怎样显示。此处选disable。

上面图中的suggest_tagv() 是一个函数，用于在变量配置中动态生成标签值（Tag Values）的建议列表。这个函数通常用于 Prometheus 数据源，帮助用户在配置变量时自动填充标签值的选项。
作用
suggest_tagv() 函数的作用是根据指定的标签键（Tag Key）生成一个标签值的列表。这些标签值可以作为变量的选项，供用户在 Grafana 的仪表板中选择。
使用场景
假设你有一个 Prometheus 指标，其中包含多个标签，例如：

http_requests_total{host=“server1”, method=“get”, status=“200”}
http_requests_total{host=“server2”, method=“post”, status=“200”}
http_requests_total{host=“server1”, method=“get”, status=“404”}
如果你想要创建一个变量 $host，其值为所有唯一的 host 标签值，你可以使用 suggest_tagv() 函数来动态生成这些值。

Prometheus指标类型

1、计数器（Counter）
Counter类型指标被用于单调增加的测量结果。因此它们总是累积的数值，值只能上升。唯一的例外是Counter重启，在这种情况下，它的值会被重置为零。
Counter的实际值通常本身并不十分有用。一个计数器的值经常被用来计算两个时间戳之间的delta或者随时间变化的速率。
例如，Counter的一个典型用例是记录API调用次数，这是一个总是会增加的测量值。

# HELP http_requests_total Total number of http api requests
# TYPE http_requests_total counter

http_requests_total{api=“add_product”} 4633433
指标名称是http_requests_total，它有一个名为api的标签，值为add_product，Counter的值为4633433。这意味着自从上次服务启动或Counter重置以来，add_product的API已经被调用了4633433次。按照惯例，Counter类型的指标通常以_total为后缀。

这个绝对数字并没有给我们提供多少信息，但当与PromQL的rate函数（或其他监控后端的类似函数）一起使用时，它可以帮助我们了解该API每秒收到的请求数。下面的PromQL查询计算了过去5分钟内每秒的平均请求数。
rate(http_requests_total{api=“add_product”}[5m])
为了计算一段时期内的绝对变化，我们将使用delta函数，在PromQL中称为increate()：
increase(http_requests_total{api=“add_product”}[5m])
这将返回过去5分钟内的总请求数，这相当于用每秒的速率乘以间隔时间的秒数

2、仪表（Gauge）
Gauge指标用于可以任意增加或减少的测量。这是你可能更熟悉的指标类型，因为即使没有经过额外处理的实际值也是有意义的，它们经常被使用到。例如，测量温度、CPU和内存使用的指标，或者队列的大小都是Gauge。
例如，为了测量一台主机的内存使用情况，我们可以使用一个Gauge指标，比如：

# HELP node_memory_used_bytes Total memory used in the node in bytes
# TYPE node_memory_used_bytes gauge

node_memory_used_bytes{hostname=“host1.domain.com”} 943348382
上面的指标表明，在测量时，节点host1.domain.com使用的内存约为900 MB。该指标的值是有意义的，不需要任何额外的计算，因为它告诉我们该节点上消耗了多少内存。
与使用Counter指标时不同，rate和delta函数对Gauge没有意义。然而，计算特定时间序列的平均数、最大值、最小值或百分比的函数经常与Gauge一起使用。在Prometheus中，这些函数的名称是avg_over_time、max_over_time、min_over_time和quantile_over_time。要计算过去10分钟内在host1.domain.com上使用的平均内存，你可以这样做：
avg_over_time(node_memory_used_bytes{hostname=“host1.domain.com”}[10m])
要使用Prometheus客户端库在Python中创建一个Gauge指标，你可以这样做：
from prometheus_client import Gauge
memory_used = Gauge(
‘node_memory_used_bytes’,
‘Total memory used in the node in bytes’,
[‘hostname’]
)
memory_used.labels(hostname=‘host1.domain.com’).set(943348382)
3、直方图（Histogram）
Histogram指标对于表示测量的分布很有用。它们经常被用来测量请求持续时间或响应大小。
直方图将整个测量范围划分为一组区间，称为桶，并计算每个桶中有多少测量值。
一个直方图指标包括几个项目：
一个包含测量次数的Counter。指标名称使用_count后缀。
一个包含所有测量值之和的Counter。指标名称使用_sum后缀。
直方图桶被暴露为一系列的Counter，使用指标名称的后缀_bucket和表示桶的上限的le label。Prometheus中的桶是包含桶的边界的，即一个上限为N的桶（即le label）包括所有数值小于或等于N的数据点。
例如，测量运行在host1.domain.com实例上的add_productAPI端点实例的响应时间的Histogram指标可以表示为：

http_request_duration_seconds_sum{api="add_product" instance="host1.domain.com"} 8953.332
http_request_duration_seconds_count{api="add_product" instance="host1.domain.com"} 27892
http_request_duration_seconds_bucket{api="add_product" instance="host1.domain.com" le="0"}
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.01"} 0
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.025"} 8
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.05"} 1672
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.1"} 8954
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.25"} 14251
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="0.5"} 24101
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="1"} 26351
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="2.5"} 27534
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="5"} 27814
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="10"} 27881
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="25"} 27890
http_request_duration_seconds_bucket{api="add_product", instance="host1.domain.com", le="+Inf"} 27892

4、汇总（Summary）
像直方图一样，Summary指标对于测量请求持续时间和响应体大小很有用。
像直方图一样，汇总度量对于测量请求持续时间和响应大小很有用。
一个Summary指标包括这些指标：
一个包含总测量次数的Counter。指标名称使用_count后缀。
一个包含所有测量值之和的Counter。指标名称使用_sum后缀。可以选择使用带有分位数标签的指标名称，来暴露一些测量值的分位数指标。由于你不希望这些量值是从应用程序运行的整个时间内测得的，Prometheus客户端库通常会使用流式的分位值，这些分位值是在一个滑动的（通常是可配置的）时间窗口上计算得到的。
例如，测量在host1.domain.com上运行的add_productAPI端点实例的响应时间的Summary指标可以表示为：

# HELP http_request_duration_seconds Api requests response time in seconds
# TYPE http_request_duration_seconds summary
http_request_duration_seconds_sum{api="add_product" instance="host1.domain.com"} 8953.332
http_request_duration_seconds_count{api="add_product" instance="host1.domain.com"} 27892
http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0"}
http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0.5"} 0.232227334
http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0.90"} 0.821139321
http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0.95"} 1.528948804
http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="0.99"} 2.829188272
http_request_duration_seconds{api="add_product" instance="host1.domain.com" quantile="1"} 34.283829292

上面这个例子包括总和和计数以及五个分位数。分位数0相当于最小值，分位数1相当于最大值。分位数0.5是中位数，分位数0.90、0.95和0.99相当于在host1.domain.com上运行的add_product API端点响应时间的第90、95和99个百分位。
像直方图一样，Summary指标包括总和和计数，可用于计算随时间的平均值以及不同时间序列的平均值。
Summary提供了比Histogram更精确的百分位计算结果，但这些百分位有三个主要缺点：
首先，客户端计算百分位是很昂贵的。这是因为客户端库必须保持一个有序的数据点列表，以进行这种计算。在Prometheus SDK中的实现限制了内存中保留和排序的数据点的数量，这降低了准确性以换取效率的提高。注意，并非所有的Prometheus客户端库都支持汇总指标中的量值。例如，Python SDK就不支持。
第二，你要查询的量值必须由客户端预先定义。只有那些已经提供了指标的量值才能通过查询返回。没有办法在查询时计算其他百分位。增加一个新的百分位指标需要修改代码，该指标才可以被使用。
第三，也是最重要的一点，不可能把多个Summary指标进行聚合计算。这使得它们对动态现代系统中的大多数用例毫无用处，在这些用例中，通常我们对一个特定的组件感兴趣，这个视角是全局的，它不与特定的实例关联。
因此，想象一下，在我们的例子中，add_product的API端点运行在10个主机上，在这些服务之前有一个负载均衡器。我们没有任何聚合函数可以用来计算add_product API接口在所有请求中响应时间的第99百分位数，无论这些请求被发送到哪个后端实例上。我们只能看到每个主机的第99个百分点。同样地，我们也只能知道某个接口，比如add_productAPI端点的（在某个实例上的）第99百分位数，而不能对不同的接口进行聚合。