关于kubernetes:kubernetes中服务自定义指标

prometheus指标类型

Counter

Counter 类型代表一种样本数据枯燥递增的指标，即只增不减，除非监控零碎产生了重置。次要用于理解事件产生的速率的变动，通过PromQL函数能够提供相应的剖析,比方以 HTTP 利用申请量。

获取http申请的增长率

rate(http_requests_total[5m])

拜访前100的http申请地址

topk(100,http_requests_total)

次要蕴含两个办法

// 将Counter值加1Inc()// 将指定值加到counter上，如果指定值小于0会panicAdd()

Guage

Guage 类型代表一种样本数据能够任意变动的指标，即可增可减。罕用于像温度或者内存使用率这种指标数据，也能够示意能随时减少或缩小的“总数”，例如：以后并发申请的数量。
通过PromQL函数能够提供相应的剖析

1. 获取样本在一段时间内的变动状况

计算 CPU 温度在1小时内的差别dalta(cpu_temp_celsius{host="zeus"}[1h])

1. 基于简略线性回归的形式，对样本数据的变化趋势做出预测

基于 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 比照

服务自定义指标

应用阐明参考GoDoc : https://godoc.org/github.com/prometheus/client_golang/prometheus

上面以一个Guage类型的指标进行阐明，应用语言为golang

1. 裸露服务

在服务service信息中减少一下信息，在promethues配置对应规定后对被动进行采集

apiVersion: v1kind: Servicemetadata:  annotations:    prometheus.io/scrape: "true"    prometheus.io/port: "80"    prometheus.io/scheme: "http"    prometheus.io/path: "/metrics"

1. 裸露指标

要想你的程序可能被监控，你就必须要将程序运行中的各我的项目指标裸露进去，提供给promtheus采集信息

package mainimport (    "log"    "net/http"    "github.com/prometheus/client_golang/prometheus/promhttp")func main() {    http.Handle("/metrics", promhttp.Handler())    log.Fatal(http.ListenAndServe(":8080", nil))}

1. 自定义指标

注册指标

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 Describefunc (m *UserMetric) Describe(ch chan<- *prometheus.Desc) {    m.testMetric.Describe(ch)}// prometheus interface Collectfunc (m *UserMetric) Collect(ch chan<- prometheus.Metric) {    defer func() {        m.testMetric.Collect(ch)    }()    // 生成指标操作    ......}