Prometheus时间序列、指标类型和配置⽂件
⽂章⽬录
1. 概念
1.1 时间序列
时间序列指在连续等间隔的时间点上获取的数据值，存储时间序列数据的数据库称为时间序列数据库Time Series Databa (TSDB)，时间序列数据库特点是写远⼤于读，并且写⼊平稳，基本不会涉及更新操作。Prometheus从本质上来说，就是将所有监控指标存储为时间序列，默认存在宿主机上。Prometheus的每个时间序列通过metirc name和label来标识的。
Prometheus中常见的⼏个名词：
时间序列(time-ries)：时间序列，也成为向量(vector)
时间戳(timestamp)：精确到毫秒的时间戳
指标(metric)：由指标的名称(metric name)和当前指标的标签(lable)组成，格式: <metric name>{<label name>=<label value>, ...}1 metric name：指标名称匹配正则表达式: [a-zA-Z_:][a-zA-Z0-9_:]*
label: 标签匹配 [a-zA-Z_][a-zA-Z0-9_]* ， __ 开头的标签仅内部使⽤
样本值(value)：⼀个float64的值
1.2 指标类型
1.2.1 基本类型
当前prometheus提供了四种指标类型(metric type)，这四种表达的含义不同，在查询语句中需要进⾏区分。
计数器(Counter)
Counter是⼀个在运⾏中单调递增的数字，⽐如CPU时间⽚信息，只有当系统或者服务重启才会置零。
become是什么意思仪表盘(Gauge)
Gauge是⼀个可增可减的数字，⽐如进程数量，可⽤内存⼤⼩等。
直⽅图(Histogram)
直⽅图对观察值（通常是请求持续时间或响应⼤⼩之类的东西）进⾏采样，并将其计数在可配置的bucket中。它还提供所有观察值的总和，这是⼀种复杂的数据类型，个别指标才会使⽤的数据类型。在⼀次取样中会暴露多个时间序列信息，⽐如: <baname>_bucket{le="<upper inclusive bound>"} bucket 的累计计数器
<baname>_sum 观测值总和
<baname>_count 观测的指标计数
通过 histogram_quantile() 可以计算分位数
摘要(Summary)
类似于直⽅图，摘要会采样观察值（通常是请求持续时间和响应⼤⼩之类的东西）。虽然它还提供了观测值的总数和所有观测值的总和，但它可以计算滑动时间窗⼝内的可配置分位数，在⼀次取样中会暴露多个时间序列信息，⽐如:
<baname>{quantile="<φ>"} 观测事件的φ分位数（0≤φ≤1）
<baname>_sum 观测值的综合
<baname>_count 观测的事件数量
1.2.2 摘要类型和直⽅图类型⽤途
摘要和直⽅图常⽤于请求时间、请求⼤⼩等可能会被个别事件严重影响平均值的场景，以系统API调⽤的平均响应时间为例：如果⼤多数API请求都维持在100ms的响应时间范围内，⽽个别请求的响应时间需要5s，那么就会导致某些WEB页⾯的响应时间落到中位数的情况，⽽这种现象被称为长尾问题。
为了区分是平均的慢还是长尾的慢，最简单的⽅式就是按照请求延迟的范围进⾏分组。例如，统计延迟在0~10ms之间的请求数有多少，⽽10~20ms之间的请求数⼜有多少。通过这种⽅式可以快速分析系统慢的原因。
Histogram和Summary都是为了能够解决这样问题的存在，通过Histogram和Summary类型的监控指标，我们可以快速了解监控样本的分布情况。
例如，指标prometheus_tsdb_wal_fsync_duration_conds的指标类型为Summary。 它记录了Prometheus Server中wal_fsync处理的处理时间，通过访问Prometheus Server的/metrics地址，可以获取到以下监控样本数据：
# HELP prometheus_tsdb_wal_fsync_duration_conds Duration of WAL fsync.
# TYPE prometheus_tsdb_wal_fsync_duration_conds summary购物车 英文
prometheus_tsdb_wal_fsync_duration_conds{quantile="0.5"}0.012352463
prometheus_tsdb_wal_fsync_duration_conds{quantile="0.9"}0.014458005
prometheus_tsdb_wal_fsync_duration_conds{quantile="0.99"}0.017316173
prometheus_tsdb_wal_fsync_duration_conds_sum 2.888716127000002
prometheus_tsdb_wal_fsync_duration_conds_count 216
从上⾯的样本中可以得知当前Prometheus Server进⾏wal_fsync操作的总次数为216次，耗时2.888716127000002s。其中中位数（quantile=0.5）的耗时为0.012352463，9分位数（quantile=0.9）的耗时为0.014458005s。
在Prometheus Server⾃⾝返回的样本数据中，我们还能找到类型为Histogram的监控指标
prometheus_tsdb_compaction_chunk_range_bucket。
# HELP prometheus_tsdb_compaction_chunk_range Final time range of chunks on their first compaction
# TYPE prometheus_tsdb_compaction_chunk_range histogram
prometheus_tsdb_compaction_chunk_range_bucket{le="100"}0
prometheus_tsdb_compaction_chunk_range_bucket{le="400"}0
prometheus_tsdb_compaction_chunk_range_bucket{le="1600"}0
prometheus_tsdb_compaction_chunk_range_bucket{le="6400"}0
prometheus_tsdb_compaction_chunk_range_bucket{le="25600"}0
prometheus_tsdb_compaction_chunk_range_bucket{le="102400"}0
prometheus_tsdb_compaction_chunk_range_bucket{le="409600"}0
北京肚皮舞教练培训prometheus_tsdb_compaction_chunk_range_bucket{le="1.6384e+06"}260
prometheus_tsdb_compaction_chunk_range_bucket{le="6.5536e+06"}780
prometheus_tsdb_compaction_chunk_range_bucket{le="2.62144e+07"}780
prometheus_tsdb_compaction_chunk_range_bucket{le="+Inf"}780
prometheus_tsdb_compaction_chunk_range_sum 1.1540798e+09
prometheus_tsdb_compaction_chunk_range_count 780
相似点：
Summary与Histogram两个类型的样本都可以反应当前指标的总数（以_count作为后缀）以及其值的总量（以_sum作为后缀）
不同点：
分位数：Summary的分位数则是直接在客户端计算完成；Histogram指标值的分位数是通过histogram_quantile()函数计算完成。
Histogram指标直接反应了在不同区间内样本的个数，区间通过标签len进⾏定义。
因此对于分位数的计算⽽⾔，Summary在通过PromQL进⾏查询时有更好的性能表现，⽽Histogram
则会消耗更多的资源。反之对于客户端⽽⾔Histogram消耗的资源更少。在选择这两种⽅式时⽤户应该按照⾃⼰的实际场景进⾏选择。
2. Prometheus基本配置
Prometheus 配置分为两个部分，命令⾏传递的不可变配置，配置⽂件传递的可变配置。所谓不可变是指进程进⾏运⾏中是不可以动态更新。
2.1 prometheus命令⾏
Prometheus提供了两个可执⾏⽂件：prometheus 和 promtool，前者⽤于prometheus rver的启停，后者为prometheus调试⼯具，常⽤于配置⽂件检查。
prometheus 常⽤参数，更多参考 prometheus --help
-h, --help 显⽰帮助信息
--version 显⽰版本
--config.file="l"指定配置⽂件
-
-web.listen-address="0.0.0.0:9090"指定监听的端⼝
--web.max-connections=512最⼤连接数
--able-lifecycle 是否开启reload和shutdown的远程API
--able-admin-api 是否开启管理API
--plates="consoles"控制台模板⽬录
--sole.libraries="console_libraries"控制台库⽂件⽬录
--storage.tsdb.path="data/"数据存储路径
--ion.time 数据保留时间，默认15天
--query.timeout=2m 查询超时时间
--query.max-concurrency=20最⼤并发查询数量
--query.max-samples=50000000单次查询返回的最⼤样本数
-
-log.level=info ⽇志级别: [debug, info, warn, error]
--log.format=logfmt ⽇志输出格式：[logfmt, json]
深圳法语培训
promtool常⽤参数，更多参考 promtool --help
check config <config-files>... 检查配置⽂件
check rules <rule-files>... 检查规则⽂件
2.2 prometheus配置⽂件
普罗⽶修斯配置为 YAML。下载的 Prometheus 提供了⼀个名为 l 的⽂件中的样例配置，这是⼀个很好的开始。
我们删除了⽰例⽂件中的⼤部分注释，以使其更简洁(注释是以 # 作为前缀的⾏)。
# 全局配置
firmwareupdateglobal:
# 从各个target上获取监控指标的时间间隔
[ scrape_interval: <duration>| default = 1m ]
# 获取监控指标时超时时间
[ scrape_timeout: <duration>| default = 10s ]
# 评估规则时间间隔
[ evaluation_interval: <duration>| default = 1m ]
# 与外部系统通信时对时间序列或者告警信息添加的标签，如remote storage、alertmanager等
external_labels:
[<labelname>: <labelvalue>... ]
# PromQL查询⽇志，reload操作会重新打开⽇志
[ query_log_file: <string>]
# 外部规则⽂件列表，会从这些⽂件中读取rules和alerts
rule_files:
[ - <filepath_glob>... ]
# 抓取监控的规则配置
scrape_configs:
[ - <scrape_config>... ]右脑记忆方法
# 告警配置
alerting:
pamela david# 告警标签重写
alert_relabel_configs:
[ - <relabel_config>... ]
# alertmanager 配置
alertmanagers:
[ - <alertmanager_config>... ]skydrive是什么
# 可写⼊的远程存储
remote_write:
[ - <remote_write>... ]
# 可读取的远程存储
remote_read:
[ - <remote_read>... ]
在⽰例配置⽂件中有四个主要的配置块: global、alerting、 rule _ files 和 scrapt _ confgs。
2.2.1 Global
global包含⽤于控制prometheus服务器⾏为的全局设置。
scrape_interval参数：Prometheus以scrape_interval规则周期性从监控⽬标上收集数据，然后将数据存储到本地存储上。
可以为特定的服务设定不同的参数来覆盖这个全局参数。但是最好不要这样做，在整个服务器上保持⼀个全局性间隔。这样可以确保所有时间序列数据具有相同的采集间隔，可以组合在⼀起计算。如果覆盖全局采集间隔，则可能由于尝试⽐较不同间隔收集的数据⽽导致结果不⼀致。
evaluation_interval参数：Prometheus以evaluation_interval规则周期性对告警规则做计算，然后更新告警状态。
规则可以分为两⼤类：记录规则和警报规则：
记录规则-允许您根据预先记录表达式抓取监控数据，并将其结果保存为派⽣的时间序列数据。
警报规则-允许你定义警报条件。
通过这个参数，Prometheus将每隔15秒（重新）评估这些规则。
2.2.2 Altering
altering配置Prometheus的警报服务器。Prometheus的警报由⼀个名为AlertManager的独⽴⼯具提供。
AlertManager是⼀个可以集群化的独⽴警报管理⼯具。
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
Prometheus还⽀持对AlertManager的服务发现，例如，你可以查询外部源（如Consul服务器）以返回可⽤的AlertManager列表，⽽不是单独指定每个AlertManager。
2.2.3 Rule files
rule_files指定了⼀组规则⽂件，可以包含记录规则或警报规则。
规则⽂件的语法是：
groups:
[ - <rule_group>]
⼀个简单的记录规则⽂件是：
groups:
- name: example
rules:
坚硬的意思
- record: job:http_inprogress_requests:sum
expr: sum(http_inprogress_requests) by (job)
警报规则的⽰例⽂件是：
groups:
-
name: example
rules:
- alert: HighErrorRate
expr: job:request_latency_conds:mean5m{job="myjob"}>0.5
for: 10m
labels:
verity: page
annotations:
summary: High request latency
要在不启动Prometheus服务器的情况下快速检查规则⽂件在语法上是否正确，请安装并运⾏Prometheus的promtool命令⾏⼯具：
promtool check rules /path/to/l
cpsp2.2.4 Scrape configuration
scrape_configs具体说明了Prometheus想要抓取的⽬标。
Prometheus通过访问获取端点来抓取数据。为了抓取⼀个端点，普罗⽶修斯定义了⼀个称为⽬标的配置。这是执⾏抓取所需的信息，例如，需要应⽤的标签、连接所需的任何⾝份验证，或者定义抓取将如何发⽣的其他信息。⽬标组称为作业。在作业内部，每个⽬标都有⼀个名为instance的标签，该标签唯⼀地标识⽬标对象。
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
在缺省配置中有⼀个名为prometheus的作业，它⾥⾯包含⼀个static_config配置项，列出了这个作业将要抓取的⽬标。这个要抓取的⽬标列表可以⼿动 静态配置 或通过 服务发现 来设置。
详细配置：
# 当前抓取作业的名称
job_name:<job_name>
