第02期:Prometheus 数据采集(一)

第02期:Prometheus 数据采集(一)上篇文章(第01期:详解 Prometheus 专栏开篇)介绍了 Prometheus 的架构,本文开始将介绍 Prometheus 数据采集。本文首先会介绍采集数据的格式和分类,然后会给出一些使用…

第02期:Prometheus 数据采集(一)

第02期:Prometheus 数据采集(一)

上篇文章(第01期:详解 Prometheus 专栏开篇)介绍了 Prometheus 的架构,本文开始将介绍 Prometheus 数据采集。本文首先会介绍采集数据的格式和分类,然后会给出一些使用上的建议。

一、采集数据格式及分类

1.1 采集数据的格式x`

Prometheus 使用 metric 表示监控度量指标,它由 metric name (度量指标名称)和 labels (标签对)组成:

<metric name>{<label name=<label value>, ...}

代码100分

metric name 指明了监控度量指标的一般特征,比如 http_requests_total 代表收到的 http 请求的总数。metric name 必须由字母、数字、下划线或者冒号组成。冒号是保留给 recording rules 使用的,不应该被直接使用。

labels 体现了监控度量指标的维度特征,比如 http_requests_total{method=”POST”, status=”200“} 代表 POST 响应结果为 200 的请求总数。Prometheus 不仅能很容易地通过增加 label 为一个 metric 增加描述维度,而且还很方便的支持数据查询时的过滤和聚合,比如需要获取所有响应为 200 的请求的总数时,只需要指定 http_request_total{status=”200″}

Prometheus 将 metric 随时间流逝产生的一系列值称之为 time series(时间序列)。某个确定的时间点的数据被称为 sample(样本),它由一个 float64 的浮点值和以毫秒为单位的时间戳组成。

1.2 采集数据的分类

在了解过 Prometheus 采集数据的格式之后,我们来了解一下它的分类。Prometheus 将采集的数据分为 CounterGaugeHistogramSummary 四种类型。

需要注意的是,这只是一种逻辑分类,Prometheus 内部并没有使用采集的数据的类型信息,而是将它们做为无类型的数据进行处理。这在未来可能会改变。

下面,我们将具体介绍着四种类型。

Counter

Counter 是计数器类型,适合单调递增的场景,比如请求的总数、完成的任务总数、出现的错误总数等。它拥有很好的不相关性,不会因为重启而重置为 0。

Gauge

Gauge 用来表示可增可减的值,比如 CPU 和内存的使用量、IO 大小等。

Histogram

Histogram 是一种累积直方图,它通常用来描述监控项的长尾效应。

举个例子:

假设使用 Hitogram 来分析 API 调用的响应时间,使用数组 [30ms, 100ms, 300ms, 1s, 3s, 5s, 10s] 将响应时间分为 8 个区间。那么每次采集到响应时间,比如 200ms,那么对应的区间 (0, 30ms], (30ms, 100ms], (100ms, 300ms] 的计数都会加 1。最终以响应时间为横坐标,每个区间的计数值为纵坐标,就能得到 API 调用响应时间的累积直方图。

Summary

Summary 和 Histogram 类似,它记录的是监控项的分位数。什么是分位数?举个例子:假设对于一个 http 请求调用了 100 次,得到 100 个响应时间值。将这 100 个时间响应值按照从小到大的顺序排列,那么 0.9 分位数(90% 位置)就代表着第 90 个数。

通过 Histogram 可以近似的计算出百分位数,但是结果并不准确,而 Summary 是在客户端计算的,比 Histogram 更准确。不过,Summary 计算消耗的资源更多,并且计算的指标不能再获取平均数或者关联其他指标,所以它通常独立使用。

二、使用建议

2.1 Metric 的命名

  • Metric 名字应该以它所属的领域开头,比如关于进程的 metric 以 process 开头:process_cpu_seconds_total。
  • Metric名字的结尾应该带有描述性的复数形式的基本单位。如果是总数类的 metric,还可以在结尾加上 total,比如:http_requests_total

2.2 Label 的选择

Label 应该用来描述 metric 的典型特征,比如使用 operation=”create|update|delete” 描述不同类型的 http 请求。需要特别注意:不能将用户 ID、邮件地址这种取值范围非常广泛的值作为 label,否则会显著的增加数据存储量。同时,一个 metric 的 label 数量也不应该过多,单个 metric 的 label 数量尽量保持在 10 个以内。

2.3 Histogram 与 Summary 的选择

  • 如果需要使用聚合函数,使用 Histogram
  • 如果对于观测值的分布有大致的预期,使用 Histogram,否则使用 Summary

2.4 应该监测什么?

  • 从服务的类型来讲,应该监测所有类型的服务:在线服务、离线服务和批处理任务
  • 从单一服务的实现来讲,应该监测服务的关键逻辑,比如关键逻辑执行的总数、失败次数、重试次数等
  • 从服务的质量来讲,应该监测服务的请求总数、请求错误率和请求响应时间
  • 从系统资源上来讲,应该监测资源的利用率、饱和度和错误

扩展阅读: 【recording rules】https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/#recording-rules)

第02期:Prometheus 数据采集(一)

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/8247.html

(0)
上一篇 2023-03-04
下一篇 2023-03-04

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注