其他分享
首页 > 其他分享> > Prometheus 精要(一)

Prometheus 精要(一)

作者:互联网

关于可观测性

记录所有事件的所有上下文,对调试或者了解当前系统的状况,于技术、于业务而言,都是非常有益的,但是需要处理和存储海量的数据,这是不现实的。

大概有四种方式来减少数据量,让处理和存储这些数据变得可实现:

指标类型

Counter

累计值,只增不减。通常用来记录事件累计发生的次数,用于表现事件在时间轴上发生(次数):

例:rate(user_logins_total[1m])

Gauge

快照值。通常用来直接表现状态在时间轴上的变化:

例如:temperature

Summary

对应两个累计值,只增不减。一个记录事件累计发生的次数,一个记录事件属性的累计和,主要用于表现事件在时间轴上发生(与否),以及事件发生时的属性均值:

例如:rate(request_latency_seconds_sum)/rate(request_latency_seconds_count)

如果使用了 quantile,还会有若干个 Gauge 值对应事件属性百分位值的快照:

50%的请求延迟小于这个值:request_latency_seconds{le="0.5"}

75%的请求延迟小于这个值:request_latency_seconds{le="0.75"}

95%的请求延迟小于这个值:request_latency_seconds{le="0.9"}

注意:百分位值在客户端计算,需要消耗客户端资源。

Histogram

对应 2 + N 个累计值,只增不减。一个记录事件累计发生的次数,一个记录事件属性的累计和,其余N个记录事件在N个属性值区间上累计发生的次数:

前2个累计值的使用和 Summary 类似。

剩余N个累计值:

请求延迟值(秒)命中 [0, 0.1] 区间的累计次数:

request_latency_seconds_bucket{quantile="0.1"}

请求延迟值(秒)命中 [0, 0.5] 区间的累计次数:

request_latency_seconds_bucket{quantile="0.5"}

请求延迟值(秒)命中 [0, +Inf] 区间的累计次数 = 请求累计次数:

request_latency_seconds_bucket{quantile="+Inf"}

90%的请求延迟小于这个值(百分位值):

​ histogram_quantile(0.9, rate(request_latency_seconds_bucket[1m]))

注意:计算发生在服务端,计算结果的精度和 bucket 区间个数、每个区间的大小有关。

指标命名

监测的对象

服务

关注报错以及打日志的地方

何时使用标签

指标使用了某标签K=V以后,如果无视标签K进行聚合,得到的结果还有意义,说明可以使用这个标签。

容量规划

可以简单地认为 prometheus 最多能处理 1000 万个时间序列

再预设最多有 1000 个被监控的实例,每个实例平均能占用 10000 个时间序列

1 个 Gauge/Counter 占用的时间序列数 = 1 x (标签1的的值个数) x (标签2的的值个数)x(标签3的的值个数)x ... x (标签N的的值个数)

注意:要排除 instance 标签,已经被当成 1000 个值计算过了

1 个 Summary 占用的时间序列数 = (同 Gauge/Counter) x (2 + quantile 数)

1 个 Histogram 占用的时间序列数 = (同 Gauge/Counter) x (2 + bucket 区间数)

大部分指标占用的时间序列应该少于10个

少部分指标占用的时间序允许在100个左右

如果把某个标签的值展开,变成多个指标(标签值移入到指标名),例如 http_requests_total => http_get_requests_total, http_post_requests_total, http_put_requests_total ... 占用的时间序总数并没有发生变化,还加大了聚合的难度

标签:latency,seconds,标签,request,累计,Prometheus,事件,精要
来源: https://www.cnblogs.com/roy2220/p/14839051.html