prometheus-简介

前言

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

Prometheus 是什么？

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

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

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

Prometheus结构

这张图来自官网，可以看出来主要分为五大部分

收集metrics(Exporter和PushGateway)

Prometheus Server

Service Discover

AlertManager

PromQL For Query

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

何谓Metrics

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

Prometheus Metrics Data Model

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

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

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

Counter

第一种就是Counter。Counter就是我们上述提到了，累加器。

文档上的描述是，Counter只能递增或者被reset到0.

Gauge

Gauge的中文意思是仪表盘，可以联想到我们汽车上的仪表盘，代表的就是当前系统的状态，和之前的状态没关系。

文档上说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的概念。
这两个概念应该是比较好理解的，给个官网上的图：

比如这里配置了一个job，名字叫做api-server，需要去四个instance上pull metrics。

总结

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