Prometheus时间序列、指标类型和配置文件

1. 概念

1.1 时间序列

时间序列指在连续等间隔的时间点上获取的数据值，存储时间序列数据的数据库称为时间序列数据库Time Series Database (TSDB)，时间序列数据库特点是写远大于读，并且写入平稳，基本不会涉及更新操作。Prometheus从本质上来说，就是将所有监控指标存储为时间序列，默认存在宿主机上。Prometheus的每个时间序列通过metirc name和label来标识的。
Prometheus中常见的几个名词：

• 时间序列(time-series)：时间序列，也成为向量(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时间片信息，只有当系统或者服务重启才会置零。
• 仪表盘(Gauge)
  Gauge是一个可增可减的数字，比如进程数量，可用内存大小等。
• 直方图(Histogram)
  直方图对观察值（通常是请求持续时间或响应大小之类的东西）进行采样，并将其计数在可配置的bucket中。它还提供所有观察值的总和，这是一种复杂的数据类型，个别指标才会使用的数据类型。在一次取样中会暴露多个时间序列信息，比如:
  • <basename>_bucket{le="<upper inclusive bound>"} bucket 的累计计数器
  • <basename>_sum 观测值总和
  • <basename>_count 观测的指标计数
  • 通过 histogram_quantile() 可以计算分位数
• 摘要(Summary)
  类似于直方图，摘要会采样观察值（通常是请求持续时间和响应大小之类的东西）。虽然它还提供了观测值的总数和所有观测值的总和，但它可以计算滑动时间窗口内的可配置分位数，在一次取样中会暴露多个时间序列信息，比如:
  • <basename>{quantile="<φ>"} 观测事件的φ分位数（0≤φ≤1）
  • <basename>_sum 观测值的综合
  • <basename>_count 观测的事件数量

1.2.2 摘要类型和直方图类型用途

摘要和直方图常用于请求时间、请求大小等可能会被个别事件严重影响平均值的场景，以系统API调用的平均响应时间为例：如果大多数API请求都维持在100ms的响应时间范围内，而个别请求的响应时间需要5s，那么就会导致某些WEB页面的响应时间落到中位数的情况，而这种现象被称为长尾问题。

为了区分是平均的慢还是长尾的慢，最简单的方式就是按照请求延迟的范围进行分组。例如，统计延迟在0~10ms之间的请求数有多少，而10~20ms之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。

Histogram和Summary都是为了能够解决这样问题的存在，通过Histogram和Summary类型的监控指标，我们可以快速了解监控样本的分布情况。

例如，指标prometheus_tsdb_wal_fsync_duration_seconds的指标类型为Summary。 它记录了Prometheus Server中wal_fsync处理的处理时间，通过访问Prometheus Server的/metrics地址，可以获取到以下监控样本数据：

# HELP prometheus_tsdb_wal_fsync_duration_seconds Duration of WAL fsync.
# TYPE prometheus_tsdb_wal_fsync_duration_seconds summary
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173
prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002
prometheus_tsdb_wal_fsync_duration_seconds_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 server的启停，后者为prometheus调试工具，常用于配置文件检查。

prometheus 常用参数，更多参考 prometheus --help

 -h, --help                               显示帮助信息
      --version                           显示版本
      --config.file="prometheus.yml"      指定配置文件
      --web.listen-address="0.0.0.0:9090" 指定监听的端口
      --web.max-connections=512           最大连接数
      --web.enable-lifecycle              是否开启reload和shutdown的远程API
      --web.enable-admin-api              是否开启管理API
      --web.console.templates="consoles"  控制台模板目录
      --web.console.libraries="console_libraries"  控制台库文件目录
      --storage.tsdb.path="data/"         数据存储路径
      --storage.tsdb.retention.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 提供了一个名为 Prometheus.yml 的文件中的样例配置，这是一个很好的开始。

我们删除了示例文件中的大部分注释，以使其更简洁(注释是以 # 作为前缀的行)。

# 全局配置
global:
  # 从各个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:
  # 告警标签重写
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  # alertmanager 配置
  alertmanagers:
    [ - <alertmanager_config> ... ]

# 可写入的远程存储
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_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    labels:
      severity: page
    annotations:
      summary: High request latency

要在不启动Prometheus服务器的情况下快速检查规则文件在语法上是否正确，请安装并运行Prometheus的promtool命令行工具：

promtool check rules /path/to/example.rules.yml

2.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>

# 当前Job的抓取指标的时间间隔，默认采用全局配置
[ scrape_interval: <duration> | default = <global_config.scrape_interval> ]

# 每个target抓取超时时间
[ scrape_timeout: <duration> | default = <global_config.scrape_timeout> ]

# 抓取的API接口
[ metrics_path: <path> | default = /metrics ]

# 当抓取的指标中label与系统默认添加的冲突时如何处理
# 为true表示保留抓取的label，false表示对抓取的时间序列label重命名：expoted_<org_label_name>
[ honor_labels: <boolean> | default = false ]

# 当抓取的指标中时间戳存在冲突时如何处理
# true表示以exporter显示的时间为准，反之为 false
[ honor_timestamps: <boolean> | default = true ]

# 访问 metrics API 的协议，默认 http
[ scheme: <scheme> | default = http ]

# 访问 metrics API 的参数
params:
  [ <string>: [<string>, ...] ]

# 访问 metrics API 时在header中添加 Authorization字段
# 内容为基本认证信息的用户名和密码。password和password_file互斥
basic_auth:
  [ username: <string> ]
  [ password: <secret> ]
  [ password_file: <string> ]

# 访问 metrics API 时在header中添加 Authorization字段，内容为 token
# bearer_token_file和bearer_token互斥
[ bearer_token: <secret> ]
[ bearer_token_file: <filename> ]

# tls 配置
tls_config:
  # 用于验证服务端的server证书的 CA 证书
  [ ca_file: <filename> ]
  # 客户端证书和key，用于被服务端验证
  [ cert_file: <filename> ]
  [ key_file: <filename> ]
  # server_name 扩展名，指的就是服务器名称
  [ server_name: <string> ]
  # 禁用服务器证书验证
  [ insecure_skip_verify: <boolean> ]

# 代理地址，部分跨网络的情况，可以采用正向代理
[ proxy_url: <string> ]

# 静态抓取目标配置，一般只有极个别场景才会配置，否则会导致主配置文件更新频繁，并且很臃肿
static_configs:
  # 指定抓取目标的地址
  targets:
    [ - '<host>' ]
  # 对采集到的数据指定额外的标签
  labels:
    [ <labelname>: <labelvalue> ... ]

# target 标签重写规则
relabel_configs:
  [ - <relabel_config> ... ]

# metrics 标签重写规则
metric_relabel_configs:
  [ - <relabel_config> ... ]

# 各类服务发现配置，涉及种类较多。常用有三种：
#   基于文件的自动发现规则: file_sd_configs
#   基于k8s的自动发现规则: kubernetes_sd_configs
#   基于consul的自动发现规则：consul_sd_configs
file_sd_configs:
  [ - <file_sd_config> ... ]
kubernetes_sd_configs:
  [ - <kubernetes_sd_config> ... ]
consul_sd_configs:
  [ - <consul_sd_config> ... ]

azure_sd_configs:
  [ - <azure_sd_config> ... ]
digitalocean_sd_configs:
  [ - <digitalocean_sd_config> ... ]
dockerswarm_sd_configs:
  [ - <dockerswarm_sd_config> ... ]
dns_sd_configs:
  [ - <dns_sd_config> ... ]
ec2_sd_configs:
  [ - <ec2_sd_config> ... ]
eureka_sd_configs:
  [ - <eureka_sd_config> ... ]
gce_sd_configs:
  [ - <gce_sd_config> ... ]
hetzner_sd_configs:
  [ - <hetzner_sd_config> ... ]
marathon_sd_configs:
  [ - <marathon_sd_config> ... ]
nerve_sd_configs:
  [ - <nerve_sd_config> ... ]
openstack_sd_configs:
  [ - <openstack_sd_config> ... ]
serverset_sd_configs:
  [ - <serverset_sd_config> ... ]
triton_sd_configs:
  [ - <triton_sd_config> ... ]

# 样本数限制，超过规定之则被丢弃。0表示不限制
[ sample_limit: <int> | default = 0 ]

# target 数量限制，超过的将被丢弃，目前为实验性功能。0表示不限制
[ target_limit: <int> | default = 0 ]

2.3 启动prometheus

运行：

cd  /usr/local/prometheus/
./prometheus --config.file=prometheus.yml

访问http://localhost:9090，可以看到如下图：

给它大约30秒的时间从它自己的 HTTP 指标端点收集关于它自己的数据。

你也可以通过导航到 Prometheus 自己的指标端点来验证 Prometheus 是否为自己提供指标: http://localhost:9090/metrics 指标。