1 Prometheus 相关功能介绍

Prometheus 相当于一张时序的数据库，我们对普罗米修斯来说更多的是查

针对 Prometheus 的查询来说，普罗米修斯更多的是一个查询语言

而且普罗米修斯是一个单节点部署他的数据存储在本地的，运行的时候都是以 pull 的方式来获取数据的，联邦模式更多是解决一些上下级和性能的问题。

Prometheus 的特点：

• 单点部署，不依赖于分布式存储

• 数据采集基于 HTTP 协议，使用 pull 模式获取数据，也就是主动上报和主动拉取数据

• 由 agent 客户端主动提交数据是 push 模式

• 扫描目标与告警管理支持静态配置与动态服务发现

• 可使用 PushGateway 推送时间序列数据至 Prometheus Server

• 内置 dashboard 用于基本功能查询和管理

• 对于普罗米修斯首先需要知道这些服务器的地址，然后才能获取到相关监控数据

所以 Prometheus 的目标和告警都支持静态配置，也可以通过动态的服务发现，比如在公司中使用的是 K8S ，然后我们可以结合 Prometheus 从 K8S 的 svc 上自动发现对外暴露服务的监控

我们都知道 Prometheus 是通过 pull 的方式去拉取数据有一个问题，就是所有的链接都是由客户端向服务器端发起，但是有的时候公司的网络限制不允许从外往服务器上发起连接，当然在 Prometheus 里面通过 push 网关就实现了这种方式

push gateway：

• 这样的话就不用考虑网络限制，或者对于那先短暂的业务可以由应用主动推送到 push 网关，再由 Prometheus 的 server 到 push 网关上拉取数据

内置 Dashboard：

• 用于基本功能查看和管理

• 也可以通过 Grafana 展示

1.1 Prometheus 组件介绍

在 Prometheus 中大概提供了以下几个组件：

• Prometheus Server（核心组件）：

  • Prometheus 的核心，server 会从应用上去抓取数据，app 也会给 Prometheus 提供数据，所以 Prometheus 也会有一个数据的消息格式，包括 Prometheus 的一些采集方法，这个就相当于是我们的 sdk ，也就是说 Prometheus 是提供的 sdk 和我们的语言是有一定关系的，比如说我们的应用开发语言可能是 php、java、go、这个时候 sdk 都有不同语言的 sdk

• SDK（第三方应用开发）：

  • 对于采集来说，如上图的 app ，我们提供的 sdk 其实在开发应用的时候要把 sdk 嵌入到我们的应用中去，但是比如说我们要去监控一个操作系统，那不可能说针对操作系统来重新开发吧，所以这个时候在 Prometheus 中提供了 exporter ，然后调用 os 的接口不管是系统命令还是将 os 上的文件数据通过 os 接口去暴露给 Prometheus

  • exporter：如果我们的系统是一个第三方的组件，没有办法对他进行二次开发，然后通过 exporter 给我们的第三方系统进行通信，这里的通信的话其实依赖于第三方组件提供的一些接口，我们来采集数据如 mysql、redis 等

  • 我们也都知道 http 响应其实都是文本，所以我们也可以根据他的数据格式我们自己去写库

• push Gateway（外部服务访问）：

  • Prometheus 也是从 push Gateway 上去拉取数据的，但是 push Gateway 的数据一般用在外部网络不允许进去 Prometheus 的时候，我们可以把 push Gateway 部署在外面，从一些应用上，然后将消息推送到 push Gateway 上，这就是 push 模式

  • 一般用在网络的限制，app 运行一次就结束的情况下的任务

• PromQL（数据查询语句）：

  • 普罗米修斯将数据采集完成以后呢会存储到自己的 db 中（DB 是一个时序的数据库），最终我们拿到这些数据后可以进行查询，就会有一个 web 展示

  • 查询语言是通过 Prometheus 提供的 PromQL 的引擎，那么对于 TSDB 我们也想产生一些告警，所以在 Prometheus server 内部的话还有一个规则引擎（RuleEngine），当然我们也需要给 RuleEngine 一些规则配置，比如在那些情况下产生告警，那规则的话我们是有一些配置，是通过配置文件的方式进行提供

  • 在 Prometheus 中的配置文件主要是 json 和 yaml 格式，在配置文件中的话一般都是对规则的配置，当然 Prometheus server 也可能会有些配置，对于 Prometheus 的话还需要监控 agent ，也可以通过 yaml 文件来进行配置

  • 在 Prometheus 中告警会去查询 TSDB ，如果产生告警的话，会把告警在存储到 TSDB，然后还会将告警发送出去，对外发送的话也是提供的是 http aip ，类似于 webhooXk，那我们也可以开发个告警接收系统配置给 Prometheus ，然后当产生告警以后会把告警发生给我们的 app

  • 后期有了 srcdata 之后我们可以通过 grafana 进行数据展示，当然 Prometheus 自己也提供了 API 我们也可以自己开发和调用到我们的 web 页面上

• Service discovery Prometheus 服务发现获取监控数据：

  • 如 K8S 也提供了服务器发现功能，openstack 等，主动抓取数据并将数据存储至 TSDB 中，Prometheus 本身就是一个 TSDB 的数据库，会将数据存储在本地，我们可以部署多个，部署多个的话数据不共享我们就可以单独存储至一个存储服务器中，如 ceph、nfs 等分部署存储

• alert manager（监控告警）：

  • 在 Prometheus 中产生的告警是没有规则，而是每一个规则产生以后就会立即往外发送，那这个时候告警数量相对来说比较多，或者说我们的应用挂了以后告警就发送不出去了，这时候 Prometheus 就提供了一个 alert manager，我们可以通过配置 Prometheus 将告警发送给 alert manager 。

  • 当然我们可以部署多个 alert manager 来避免单点失败，这时候 Prometheus 会将告警发送给多个 alert manager 上，在由 alert manager 对外进行通知，我们可以将 app 放到后面 webhook 也提供了通知，也就会调用我的 http api（需要自己开发）

  • alert manager 也提供了其他方式如邮件方式，可以将告警信息直接发送给邮件服务器，当然也有第三方的插件

但是这种逻辑存在下面问题：

1. 如果规则引擎(rule engine) 产生了一个告警都发送给了两个 alert manager ，那两个 alert manager 给我们通知的时候就会产生两次，当然这个是我们 alert manager 要去避免的，所以 alert manager 的逻辑有以下几个

   • alert manager 高可用避免单点失败

   • 但是 alert manager 实现高可用之后，那么消息在通知的时候会是两个或更多，当然 alert manager 要进行消息的抑制也就是说已经有一个 alert manager 发送了消息，其他的 alert manager 就不用发送了

   • rule engine 的消息都是一条一条的，告警数量比较多，然后再 alert manager 会有一个等待的时间，alert manager 等待了一段时间之后将这段时间的告警统一按照分组来发送，也就是我们的告警分组

   • 而且有些 alert manager 的告警我们可以不用关注，或者说如果产生了某一个告警另外其他一样类型的告警就不想 alert manager 发送了，比如说我们的操作系统挂了，那我们这个操作系统相关的应用就不用关注了，这个就可以配置 alert manager 的告警静默处理的功能

   • alert manager 提供了对外第三方的应用发送，所以 alert manager 也有告警发送功能

   • 总结 alert manager 功能：

     1. 高可用

     2. 消息抑制

     3. 告警分组

     4. 静默处理

     5. 告警发送

1.2 Prometheus 应用场景

Prometheus 并非所有场景都能使用，我们都知道 Prometheus 采集数据是通过 pull 方式进行采集，需要定期轮询采集 agent 节点上的数据信息，那轮询的时间是有一个延时的，所以在 Prometheus 中不适合百分之百精确的数据监控应用场景。

换句话说就是如果需要监控数据的百分之百 Prometheus 是不适合的

Prometheus 应用场景：

• Prometheus 可以记录任何纯数据的时序数据

• 通过 Prometheus 的服务发现功能，常用于以机器魏中心的监控，面向高动态的服务体系架构来监控

• 不适合 100% 准确性的要求，如请求计费的场景

• 通过指标名称进行汇总，一些相关的应用数据可以通过标签的名称进行区分来进行汇总

1.3 Prometheus 数据模型

想要了解 Prometheus 数据模型的话我们就需要介绍一下 TSDB

TSDB 时序数据库：

• 在存储数据的时候都有一个属性叫时间，

  • 在每个时间点上每个对应的数据是什么。时间可以理解为数据的名称，对应的数据是什么可以理解为数据的值。

  • 数据名称：

    组成方式，数据名称其实是由两部分组成：

    1. 指标名称

    2. 标签（key=value）

  • 数据值：

    在 Prometheus 中数据值只有一个(float64)，也就说 Prometheus 中只能够存储 float64 类型

• TSDB 数据存储：

  • 对于每一个时间点，如上图中的 t1 时间点并对应 web 系统上的 request_total{path="/"} / 路径的请求数量，request_total{path="/auth/login"} 这些 RUL 都有统计结果，假如在t1 时间点 request_total{path="/"}请求了 100 次，那这个时候数据名称中的指标名称就是 request_total，标签就是 path=/ 值就是 100，而 request_total{path="/auth/login"} 请求 10 次，也就是说在 t1 这个时间点，我们的数据值可以是很多同时发生的数据

  • 可能在 t2 时间点 Prometheus 又进行采集了一次，这个时候 request_total{path="/"} 请求可能变成了 200， request_total{path="/auth/login"} 就变成了 20，这就是时序数据库

• 我们都知道 Prometheus 中的数据值都是一个 float64 类型，所以 Prometheus 只适合数据值是一个浮点类型的数据存储

• 在 Prometheus 面向服务中，我们可以通过自定义 tag 给一些监控属性、属性值来对数据进行汇总

1.3 普罗米修斯的开发需求

在 普罗米修斯中有三个项目的开发：

1. exporter 的开发

2. 告警的开发：也就是通过我们写的 app 将 alert manager 的告警发送给我们的第三方应用程序

3. 开发一个类似于 alert manager 的功能直接对 Prometheus 对 server

对于 2 和 3 的功能都需要我们提供一个 web 系统，然后配置到 alert manager 或者 Prometheus 上，然后再让他给我们转发告警，主要关注的是对于 http 数据他提交和响应的数据是什么，对于告警来说它其实关注的是告警的格式是什么样子，因为数据是通过 Prometheus 和 alert manager 提供和定义的。我们可以通过本地文件给 Prometheus 配置动态的服务发现功能