上篇文章（第01期：详解 Prometheus 专栏开篇）介绍了 Prometheus 的架构，本文开始将介绍 Prometheus 数据采集。本文首先会介绍采集数据的格式和分类，然后会给出一些使用上的建议。
一、采集数据格式及分类
1.1 采集数据的格式x`
Prometheus 使用 metric 表示监控度量指标，它由 metric name (度量指标名称)和 labels (标签对)组成：
<metric name>{<label name=<label value>, ...}
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 将采集的数据分为 Counter、Gauge、Histogram、Summary 四种类型。
需要注意的是，这只是一种逻辑分类，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，否则使用 Summary2.4 应该监测什么？
从服务的类型来讲，应该监测所有类型的服务：在线服务、离线服务和批处理任务 从单一服务的实现来讲，应该监测服务的关键逻辑，比如关键逻辑执行的总数、失败次数、重试次数等 从服务的质量来讲，应该监测服务的请求总数、请求错误率和请求响应时间 从系统资源上来讲，应该监测资源的利用率、饱和度和错误扩展阅读： 【recording rules】https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/#recording-rules)