一、采集数据格式及分类
1.1 采集数据的格式
<metricname>{<label name=<labelvalue>, ...}
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
Gauge
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)
相关内容方面的知识，大家还有什么疑问或者想知道的吗？赶紧留言告诉小编吧！
