kubernetes中服务自定义指标

吕晨曦 · · 412 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

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函数可以提供相应的分析

  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 对比

类型HistogramSummary
客户端性能耗费较低,只需增加counter较高,需聚合计算百分位数
服务端性能耗费较高,需要聚合计算较低,无需再聚合计算
时间序列数据每个bucket一个每个百分位数一个
百分位数计算误差依赖于桶区间粒度和数据分布,受限于桶的数量受限于百分位数值本身
聚合查询时可以灵活聚合数据查询时不建议做聚合,百分位数无法做聚合,只能做均值和加和的聚合
数据的时间范围可在查询时灵活定制活动窗口内,窗口大小在声明 Metrics 后不可更改,即查询时也不可更改
适用场景客户端监控,组件在系统中较多,不太关心精确的百分位数值服务端监控,组件在系统中唯一或只有个位数,需要知道较准确的百分位数值(如性能优化场景)

服务自定义指标

使用说明参考GoDoc : https://godoc.org/github.com/prometheus/client_golang/prometheus

下面以一个Guage类型的指标进行说明,使用语言为golang

  1. 暴露服务

在服务service信息中增加一下信息,在promethues配置对应规则后对主动进行采集

apiVersion: v1
kind: Service
metadata:
  annotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "80"
    prometheus.io/scheme: "http"
    prometheus.io/path: "/metrics"
  1. 暴露指标

要想你的程序能够被监控,你就必须要将程序运行中的各项目指标暴露出来,提供给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))
}
  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 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)
    }()

    // 生成指标操作
    ......
}

有疑问加站长微信联系(非本文作者)

本文来自:Segmentfault

感谢作者:吕晨曦

查看原文:kubernetes中服务自定义指标

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

412 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传