prometheus 指标类型
Counter
Counter
类型代表一种样本数据枯燥递增的指标,即只增不减,除非监控零碎产生了重置。次要用于理解事件产生的速率的变动,通过 PromQL 函数能够提供相应的剖析, 比方以 HTTP 利用申请量。
获取 http 申请的增长率
rate(http_requests_total[5m])
拜访前 100 的 http 申请地址
topk(100,http_requests_total)
次要蕴含两个办法
// 将 Counter 值加 1
Inc()
// 将指定值加到 counter 上,如果指定值小于 0 会 panic
Add()
Guage
Guage
类型代表一种样本数据能够任意变动的指标,即可增可减。罕用于像温度或者内存使用率这种指标数据,也能够示意能随时减少或缩小的“总数”,例如:以后并发申请的数量。
通过 PromQL 函数能够提供相应的剖析
- 获取样本在一段时间内的变动状况
计算 CPU 温度在 1 小时内的差别
dalta(cpu_temp_celsius{host="zeus"}[1h])
- 基于简略线性回归的形式,对样本数据的变化趋势做出预测
基于 2 小时的样本数据,来预测主机可用磁盘空间在 4 个小时之后的残余状况
predict_linear(node_filesystem_free{job="node"}[2h], 4 * 3600) < 0
Histogram
少数状况下偏向于应用某些量化指标的平均值,例如 CPU 的均匀使用率、页面的均匀响应工夫。这种形式的问题很显著,以零碎 API 调用的均匀响应工夫为例:如果大多数 API 申请都维持在 100ms 的响应工夫范畴内,而个别申请的响应工夫须要 5s,那么就会导致页面的响应工夫平局值过大,而这种景象被称为 长尾问题
为了辨别是均匀的慢还是长尾的慢,最简略的形式就是依照申请提早的范畴进行分组。例如,统计提早在 0~10ms 之间的申请数有多少而 10~20ms 之间的申请数又有多少。
Histogram
在一段时间范畴内对数据进行采样(通常是申请持续时间或响应大小等),并将其计入可配置的存储桶(bucket)中,后续可通过指定区间筛选样本,也能够统计样本总数,最初个别将数据展现为直方图。
Histogram
指标分为三种类型
- 样本的值散布在 bucket 中的数量,命名为
_bucket{le="< 上边界 >"}
。这个值示意指标值小于等于上边界的所有样本数量
// 在总共 2 次申请当中。http 申请响应工夫 <=0.005 秒 的申请次数为 0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.005",} 0.0 // 在总共 2 次申请当中。http 申请响应工夫 <=0.01 秒 的申请次数为 0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.01",} 0.0 // 在总共 2 次申请当中。http 申请响应工夫 <=0.025 秒 的申请次数为 0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.025",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.05",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.075",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.1",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.25",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.5",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.75",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="1.0",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="2.5",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="5.0",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="7.5",} 2.0 // 在总共 2 次申请当中。http 申请响应工夫 <=10 秒 的申请次数为 2 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="10.0",} 2.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="+Inf",} 2.0
- 所有样本值的大小总和,命名为
_sum
// 理论含意:产生的 2 次 http 申请总的响应工夫为 13.107670803000001 秒 io_namespace_http_requests_latency_seconds_histogram_sum{path="/",method="GET",code="200",} 13.107670803000001
- 样本总数,命名为
_count
。值和_bucket{le="+Inf"}
雷同
// 理论含意:以后一共产生了 2 次 http 申请 io_namespace_http_requests_latency_seconds_histogram_count{path="/",method="GET",code="200",} 2.0
Summary
Summary
用于示意一段时间内的数据采样后果(通常是申请持续时间或响应大小等),但它间接存储了分位数(通过客户端计算,而后展现进去),而不是通过区间来计算。
Summary 类型的样本也会提供三种指标
- 样本值的分位数散布状况,命名为
{quantile="<φ>"}
// 含意:这 12 次 http 申请中有 50% 的申请响应工夫是 3.052404983s io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.5",} 3.052404983 // 含意:这 12 次 http 申请中有 90% 的申请响应工夫是 8.003261666s io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.9",} 8.003261666
- 所有样本值的大小总和,命名为
_sum
// 含意:这 12 次 http 申请的总响应工夫为 51.029495508s io_namespace_http_requests_latency_seconds_summary_sum{path="/",method="GET",code="200",} 51.029495508
- 样本总数,命名为
_count
// 含意:以后一共产生了 12 次 http 申请 io_namespace_http_requests_latency_seconds_summary_count{path="/",method="GET",code="200",} 12.0
Histogram 和 Summary 比照
类型 | Histogram | Summary |
---|---|---|
客户端性能消耗 | 较低,只需减少 counter | 较高,需聚合计算百分位数 |
服务端性能消耗 | 较高,须要聚合计算 | 较低,无需再聚合计算 |
工夫序列数据 | 每个 bucket 一个 | 每个百分位数一个 |
百分位数计算误差 | 依赖于桶区间粒度和数据分布,受限于桶的数量 | 受限于百分位数值自身 |
聚合 | 查问时能够灵便聚合数据 | 查问时不倡议做聚合,百分位数无奈做聚合,只能做均值和加和的聚合 |
数据的工夫范畴 | 可在查问时灵便定制 | 流动窗口内,窗口大小在申明 Metrics 后不可更改,即查问时也不可更改 |
实用场景 | 客户端监控,组件在零碎中较多,不太关怀准确的百分位数值 | 服务端监控,组件在零碎中惟一或只有个位数,须要晓得较精确的百分位数值(如性能优化场景) |
服务自定义指标
应用阐明参考 GoDoc : https://godoc.org/github.com/prometheus/client_golang/prometheus
上面以一个 Guage 类型的指标进行阐明,应用语言为golang
- 裸露服务
在服务 service 信息中减少一下信息,在 promethues 配置对应规定后对被动进行采集
apiVersion: v1
kind: Service
metadata:
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "80"
prometheus.io/scheme: "http"
prometheus.io/path: "/metrics"
- 裸露指标
要想你的程序可能被监控,你就必须要将程序运行中的各我的项目指标裸露进去,提供给 promtheus 采集信息
package main
import (
"log"
"net/http"
"github.com/prometheus/client_golang/prometheus/promhttp"
)
func main() {http.Handle("/metrics", promhttp.Handler())
log.Fatal(http.ListenAndServe(":8080", nil))
}
- 自定义指标
注册指标
prometheus.MustRegister(userMetric)
userMetric
应用用户自定义指标实例
type UserMetric struct {
// 这里以 GaugeVec 类型指标为例,其余类型相似
testMetric *prometheus.GaugeVec
}
metric 初始化
NewGaugeVec 参数是 opts,蕴含 name 和 help 信息等,第二个是定义的 Labels
userMetric := &UserMetric{
testMetric := prometheus.NewGaugeVec(
prometheus.GaugeOpts{
Name: "testMetric",
Help: "test metric",
},
labelNames,
),
}
接口实现
注册的指标必须实现 Collector
接口,接口阐明如下
type Collector interface {
// 用于传递所有可能的指标的定义描述符
// 能够在程序运行期间增加新的形容,收集新的指标信息
// 反复的描述符将被疏忽。两个不同的 Collector 不要设置雷同的描述符
Describe(chan<- *Desc)
// Prometheus 的注册器调用 Collect 执行理论的抓取参数的工作,// 并将收集的数据传递到 Channel 中返回
// 收集的指标信息来自于 Describe 中传递,能够并发的执行抓取工作,然而必须要保障线程的平安。Collect(chan<- Metric)
}
// prometheus interface Describe
func (m *UserMetric) Describe(ch chan<- *prometheus.Desc) {m.testMetric.Describe(ch)
}
// prometheus interface Collect
func (m *UserMetric) Collect(ch chan<- prometheus.Metric) {defer func() {m.testMetric.Collect(ch)
}()
// 生成指标操作
......
}