Prometheus基础

2020-03-03  本文已影响0人  伊凡的一天

Prometheus 存储的是时序数据, 即按照相同时序(相同的名字和标签)，以时间维度存储连续的数据的集合。

时序

时序(time series) 是由名字(Metric)，以及一组 key/value 标签定义的。具有相同的名字以及相同的标签则属于相同时序。

时序的名字由 ASCII 字符，数字，下划线，以及冒号组成。它的名字应该具有语义化，一般表示一个可以度量的指标，例如: http_requests_total, 可以表示 http 请求的总数。

时序的标签可以使 Prometheus 的数据更加丰富，例如 http_requests_total{method="POST"} 可以表示所有 http 中的 POST 请求。

时序数据的4种类型

时序数据可以分为以下4种类型：

关于Histogram和Summary:

Histogram和Summary主用用于统计和分析样本的分布情况。例如，统计延迟在010ms之间的请求数有多少而1020ms之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。Histogram和Summary都是为了能够解决这样问题的存在，通过Histogram和Summary类型的监控指标，我们可以快速了解监控样本的分布情况。

例如下面一个Summary类型的metric:

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。其中耗时小于0.012352463秒的样本占比50%，耗时小于0.014458005的样本占比90%，而耗时小于0.017316173的样本占比99%。因此，这个quanatile表示百分位数，代表了相应样本值在总样本中的分布比例。

下面是一个Histogram类型的mertric:

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

Histogram类型的样本同样会反应当前指标的记录的总数(以_count作为后缀)以及其值的总量（以_sum作为后缀）。不同在于Histogram指标直接反应了在不同区间内样本的个数。例如上面的指标表示 tsdb_compaction_chunk 的值小于 1.6384e+06 的个数为260个，小于 6.5536e+06 的个数为780，小于 2.62144e+07 的个数为780，小于最高值的个数为780。tsdb_compaction_chunk值得总量为 1.1540798e+09(_sum指标)。指标记录总数为 780(_count指标)。

注意后面的采样点是包含前面的采用点的，例如xxx_bucket的值为30，而xxx_bucket的值为120，那么意味着这120个采用点中，有30个是小于10ms的，其余90个采样点的响应时间是介于10ms和50ms之间的。而+Inf是最高bucket的上限值，所以xxx_bucket是所有采样点的数量，是Prometheus自动增加的一个bucket。

同时对于Histogram的指标，我们还可以通过histogram_quantile()函数计算出其值的百分位数（quantile）。不同在于Histogram通过histogram_quantile函数是在服务器端计算的百分位数。 而Sumamry的百分位数则是直接在客户端计算完成。因此对于百分位数的计算而言，Summary在通过PromQL进行查询时有更好的性能表现，而Histogram则会消耗更多的资源。反之对于客户端而言Histogram消耗的资源更少。在选择这两种方式时用户应该按照自己的实际场景进行选择。

更多关于百分位数(quantile)的讨论，请参考：https://cloud.tencent.com/developer/news/319419

Job和instance

Prometheus 中，将任意一个独立的数据源（target）称之为实例（instance）。包含相同类型的实例的集合称之为作业（job）。 如下是一个含有四个重复实例的作业：

- job: api-server
    - instance 1: 1.2.3.4:5670
    - instance 2: 1.2.3.4:5671
    - instance 3: 5.6.7.8:5670
    - instance 4: 5.6.7.8:5671

这个job中包含了四个数据源，例如 1.2.3.4:5670 就是一个数据源（targe），Prometheus会定时从数据源中拉取数据存储为metric。

对于每一个实例，Prometheus都会为其存储以下metric：

up{job="<job-name>", instance="<instance-id>"}: 0 表示该实例故障，1 表示该实例正常工作

scrape_duration_seconds{job="<job-name>", instance="<instance-id>"} 表示拉取数据的时间间隔

scrape_samples_post_metric_relabeling{job="<job-name>", instance="<instance-id>"} 表示采用重定义标签（relabeling）操作后仍然剩余的样本数

scrape_samples_scraped{job="<job-name>", instance="<instance-id>"}  表示从该数据源获取的样本数

其中 up metric可以有效应用于监控该实例是否正常工作。

PromQL使用

PromQL (Prometheus Query Language) 是 Prometheus 自己开发的数据查询 DSL 语言，语言表现力非常丰富，内置函数很多，在日常数据可视化以及rule 告警中都会使用到它。

Prometheus 存储的是时序数据，而它的时序是由名字和一组标签构成的。一个简单的查询相当于是对各种标签的筛选，例如：

http_requests_total{code="200"} // 表示查询名字为 http_requests_total，code 为 "200" 的数据
http_requests_total{code!="200"}  // 表示查询 code 不为 "200" 的数据
http_requests_total{code=～"2.."} // 表示查询 code 为 "2xx" 的数据
http_requests_total{code!～"2.."} // 表示查询 code 不为 "2xx" 的数据
http_requests_total[5m] 范围区间查询: 过去 5 分钟数据

配置文件

Prometheus 启动的时候，可以加载运行参数 -config.file 指定配置文件，默认为 prometheus.yml。下面是一个典型的配置文件样例：

global:
  scrape_interval:     15s # By default, scrape targets every 15 seconds.
  evaluation_interval: 15s # By default, scrape targets every 15 seconds.

rule_files:
  - "rules/node.rules"

scrape_configs:
  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node'
    scrape_interval: 8s
    static_configs:
      - targets: ['127.0.0.1:9100', '127.0.0.12:9100']

  - job_name: 'mysqld'
    static_configs:
      - targets: ['127.0.0.1:9104']
  - job_name: 'memcached'
    static_configs:
      - targets: ['127.0.0.1:9150']

Exporter

在 Prometheus 中负责数据汇报的程序统一叫做 Exporter, 而不同的 Exporter 负责不同的业务。 它们具有统一命名格式，即 xx_exporter, 例如负责主机信息收集的 node_exporter。

一个 Exporter 本质上就是将收集的数据，转化为对应的文本格式，并提供 http 请求。Exporter 收集的数据转化的文本内容以行 (\n) 为单位，空行将被忽略, 文本内容最后一行为空行。

下面是一个Exporter收集的样本数据的例子：

# HELP node_cpu Seconds the cpus spent in each mode.
# TYPE node_cpu counter
node_cpu{cpu="cpu0",mode="idle"} 362812.7890625
# HELP node_load1 1m load average.
# TYPE node_load1 gauge
node_load1 3.0703125

告警

告警能力在Prometheus的架构中被划分成两个独立的部分。通过在Prometheus中定义AlertRule（告警规则），Prometheus会周期性的对告警规则进行计算，如果满足告警触发条件就会向Alertmanager发送告警信息。

在 Prometheus 中告警分为两部分:

使用告警服务主要的步骤如下：

告警规则

在Prometheus中一条告警规则主要由以下几部分组成：

一个典型的告警规则如下：

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
      description: description info

AlertManager

Alertmanager拥有以下特性：

Alertmanager主要负责对Prometheus产生的告警进行统一处理，因此在Alertmanager配置中一般会包含以下几个主要部分：

参考文章

上一篇 下一篇

猜你喜欢

热点阅读