前言

这是一个介绍prometheus系列的文章,主要的参考资料是prometheus的​​官方文档​​。本章首先介绍基本的概念。

Prometheus 是什么?

prometheus是一个开源的监控系统和报警工具集合(翻译自官方文档)。主要有以下特点:

  • 支持多维度的时序数据
  • PromQL:一个灵活的查询语言
  • 不依赖分布式存储,单个节点也能工作
  • 一种pull 模型来收集metrics
  • 通过gateway来支持push模型收集metrics
  • 支持对目标的静态配置和服务发现
  • 支持多种可视化工具

可能这些描述不是那么的清晰,对于这些描述只需要知道一个重点:prometheus是一个开源的监控系统

Prometheus结构

prometheus-简介_云原生
这张图来自官网,可以看出来主要分为五大部分

  1. 收集metrics(Exporter和PushGateway)
  2. Prometheus Server
  3. Service Discover
  4. AlertManager
  5. PromQL For Query

这五个部分组成了Prometheus,后面会一个个分析。

何谓Metrics

prometheus-简介_云原生_02Metrics的中文翻译是指标,测量,度量等。在之前influxdb中有个measurement是类似的概念。日常中metrics其实有很多,比如我们要看一个接口的qps,看cpu的利用率,等等,这些都是Metrics。
prometheus-简介_云原生_02Metrics是监控的重要手段。上面提到了Prometheus是一个开源的监控系统,那么Prometheus通过什么来监控被监控的组件呢?Prometheus选择使用欧冠Metrics,也就是一系列的指标。当然监控不仅仅可以用Metrics,用log也可以。在Opentelemetry中,Log,Tracing,Metrics被看成实现可观测性的三个基础手段。
prometheus-简介_云原生_02通过上面的介绍,可以说Prometheus就是一个处理Metrics的系统,通过收集Metrics,然后存储计算,最后展示。并且通过分析Metrics来实现报警

Prometheus Metrics Data Model

prometheus-简介_云原生_02上面提到了Prometheus是处理Metrics的,那么一条Metrics在Prometheus是什么样子呢?

<metric name>{<label name>=<label value>, ...} value [timestamp]

在Prometheus中,每一个Metrics都是如上的所示。[]表示条件,可以没有。timestamp表示当前时间戳。这类数据也被叫做时序数据(time series data)。value代表当前条件下的值,看起来有点抽象,那就看一个实际的例子:

http_requests_total{method="post"} 1027  1652603639

这里有个场景,需要统计所有的http接口相关的信息,例如要统计post方法,那么这条Metrics就代表,在1652603639这个时刻,post方法已经出现了1027次。这里出现了一个没有提到过的概念:Label.

Prometheus Label

在统计Metrics时,一个Metrics可能有多种不同的具体场景,例如刚才举例子,某个系统的http请求,那么到底是get 请求还是post请求呢?这个信息可以放在label里面。Prometheus官方文档中对Label的解释是:Labels enable Prometheus’s dimensional data model.Label让Prometheus的data model具有维度的能力。

Prometheus Metric Types

prometheus-简介_云原生_02上面提到了Prometheus 中的Metric具体格式,这个Prometheus叫做data model,这个概念在其他类似的数据处理系统也有,比如在influxdb中叫做行协议(line protocol),感兴趣的可以去看看我之前的文章。不管是data model还是行协议,这些东西的作用就是一种格式或者协议,规定了这个系统查询和存储模型的具体格式。
prometheus-简介_云原生_02回到刚才的问题,我们刚才举例子是计算某个系统所有的http请求,那么qps怎么计算呢?
假设10s中,被请求了100次,那么qps就是:100/10=10.这里提出了一个需求,我们需要知道在这10s中,请求的和。或者说每一秒,这个请求当前的累加值,这样才能计算qps。例如下面:

0s 1s 2s 3s 4s 5s
0 10 20 30 80 200

知道了这个我们就能计算每一秒的qps,说明这个Metrics是需要累计递增的,也就是一个累加器。
prometheus-简介_云原生_02考虑另外一个场景,计算当前CPU的使用率。这时发现,Metrics是不需要累加的,它表示的是当前时间的状态。
prometheus-简介_云原生_02这里就的出来一个结论,不同的场景下,需要的Metrics行为是不一致的,有的需要Metrics是持续累加,有的是保持当前最新的状态等等。所以为了满足不同的场景需求,Prometheus提供多种类型的Metrics

Counter

第一种就是Counter。Counter就是我们上述提到了,累加器。
prometheus-简介_Prometheus_10
文档上的描述是,Counter只能递增或者被reset到0.

Gauge

Gauge的中文意思是仪表盘,可以联想到我们汽车上的仪表盘,代表的就是当前系统的状态,和之前的状态没关系。
prometheus-简介_运维_11
文档上说Gauge可以增加也可以减少,常用来表示温度,mem usage等。

Histogram和Summary

Histogram是直方图,用来做采样的。直方图这个大家应该都见过。但是Histogram在存储上是丢失原始数据的,Summary对这个做了优化。这个属于是比较高级的用法,后面会详细理解一下,这里就不再详细说。

Job And Instance

上面描述了Prometheus基本概念,文章的结尾再说两个。首先是Job

Job

上面提到了,Prometheus是采用pull的模式来抓取Metrics的,也就是说Prometheus会从配置里面定时去pull metrics过来。这个pull 的被叫做一个Job。

instance

上面提到了一次pull过程就是一个具体的job,每次pull可能需要到多个实例上去抓取,每个实例就是instance的概念。
这两个概念应该是比较好理解的,给个官网上的图:
prometheus-简介_Prometheus_12
比如这里配置了一个job,名字叫做api-server,需要去四个instance上pull metrics。

总结

本篇文章介绍了Prometheus 的一些基本概念,都是对官网上的一些解释。下一章具体实践下。