Prometheus入门教程

Posted 2023-03-10 Java Devin

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Prometheus入门教程相关的知识，希望对你有一定的参考价值。

1、简介

Prometheus 是一套开源的系统监控报警框架。它启发于 Google 的 borgmon 监控系统，由工作在 SoundCloud 的 google 前员工在 2012 年创建，作为社区开源项目进行开发，并于 2016 年正式发布。

监控作为可观察性实践（监控、日志、追踪）中的关键一环，相较以往的系统监控，在云原生时代产生了诸多变化。一是微服务和容器化，导致监控对象和指标的指数级增加；二是监控对象的生命周期更加短暂，导致监控数据量和复杂度的成倍增加。这就需要一款统一监控指标和数据查询语言的工具，Prometheus 应运而生了。Pemetheus 可以很方便的与众多开源项目集成，帮助我们了解系统和服务的运行状态，另一方面分析其收集的大数据，可以帮助我们进行系统优化和作出决策。它不仅是可以应用在 IT 领域，对于任何需要收集指标数据的情形下都可以使用。

2、主要功能

多维数据模型（时序由 metric 名字和 k/v 的 labels 构成）。
灵活的查询语句（PromQL）。
无依赖存储，支持 local 和 remote 不同模型。
采用 http 协议，使用 pull 模式，拉取数据，简单易懂。
监控目标，可以采用服务发现或静态配置的方式。
支持多种统计数据模型，图形化友好。

3、Prometheus的架构及核心组件

Prometheus Server: 用于收集和存储时间序列数据。
Client Library: 客户端库，为需要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当 Prometheus server 来 pull 时，直接返回实时状态的 metrics。
Push Gateway: 主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter。
Exporters: 用于暴露已有的第三方服务的 metrics 给 Prometheus。
Alertmanager: 从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等。

它大致使用逻辑是这样：

Prometheus server 定期从静态配置的 target 或者服务发现的 target 拉取数据。
当新拉取的数据大于配置内存缓存区的时候，Prometheus 会将数据持久化到磁盘（如果使用 remote storage 将持久化到云端）。
Prometheus 可以配置 rule，然后定时查询数据，当条件触发的时候，会将 alert 推送到配置的 Alertmanager。
Alertmanager 收到警告的时候，可以根据配置，聚合、去重、降噪，最后发送警告。
可以使用 API、Prometheus Console 或者 Grafana 查询和聚合数据。(一般用于展示数据)

4、安装和配置

（参考官方文档或自行百度，非本文重点，主要的操作就是将prometheus部署至服务器，然后再部署各种监控指标，注意prometheus有自带的监控指标，但可能不够日常的使用，这个时候就需要其他配置监控指标的插件了，这个自行百度一下，就不在这里过多赘述了。）

Overview | Prometheus

5、相关概念

5.1、数据模型（时间序列）

Prometheus 中存储的数据为时间序列，是由 metric 的名字和一系列的标签（键值对）唯一标识的，不同的标签则代表不同的时间序列。

metric 名字：该名字应该具有语义，一般用于表示 metric 的功能，例如：http_requests_ total, 表示 http 请求的总数。其中，metric 名字由 ASCII 字符，数字，下划线，以及冒号组成，且必须满足正则表达式 a-zA-Z_:*。
标签：使同一个时间序列有了不同维度的识别。例如 http_requests_totalmethod=“Get” 表示所有 http 请求中的 Get 请求。当 method=“post” 时，则为新的一个 metric。标签中的键由 ASCII 字符，数字，以及下划线组成，且必须满足正则表达式 a-zA-Z_:*。
样本：实际的时间序列，每个序列包括一个 float64 的值和一个毫秒级的时间戳。
格式：=, …，例如:http_requests_totalmethod=“POST”,endpoint=“/api/tracks”。

5.2、metric类型

Counter（计数器）

说明：Counter是一个累积度量，它表示一个单调递增的 Metrics，其值只能在重启时递增或重置为零
场景：可以使用Counter来表示http的请求数、已完成的任务数或错误数、下单数。例如我们可以在应用程序中记录某些事件发生的次数，通过以时序的形式存储这些数据，我们可以轻松的了解该事件产生速率的变化。 PromQL内置的聚合操作和函数可以让用户对这些数据进行进一步的分析：

例如，通过rate()函数获取HTTP请求量的增长率：
```
rate(http_requests_total[5m])
```
查询当前系统中，访问量前10的HTTP地址：
```
topk(10, http_requests_total)
```

Gauge（测量仪）

说明：当前值的一次快照(snapshot)测量，可增可减。
场景：磁盘使用率，当前同时在线用户数。这类指标的样本数据可增可减。常见指标如：node_memory_MemFree（主机当前空闲的内容大小）、node_memory_MemAvailable（可用内存大小）都是Gauge类型的监控指标。

通过Gauge指标，用户可以直接查看系统的当前状态：
```
node_memory_MemFree
```
对于Gauge类型的监控指标，通过PromQL内置函数delta()可以获取样本在一段时间返回内的变化情况。例如，计算CPU温度在两个小时内的差异：
```
delta(cpu_temp_celsiushost="zeus"[2h])
```
还可以使用deriv()计算样本的线性回归模型，甚至是直接使用predict_linear()对数据的变化趋势进行预测。例如，预测系统磁盘空间在4个小时之后的剩余情况：
```
predict_linear(node_filesystem_freejob="node"[1h], 4 * 3600)
```

Histogram（直方图）

说明：通过区间统计样本分布。
场景：请求延迟时间的统计。例如统计 0_{200ms、200ms}400ms、400ms~800ms 区间的请求数有多少。

Summary（汇总）

说明：根据样本统计出百分位。
场景：请求延迟时间的统计。例如统计 95%的请求延迟 < xxx ms ，99%的请求延迟 < xxx ms

5.3、instance 和 jobs

在Prometheus术语中，你可以scrape的端点称为实例，通常对应于单个进程。一组同种类型的 instances（主要用于保证可扩展性和可靠性），例如：具有四个复制instances（实例）的API服务器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

当Prometheus scrape目标时，它会自动在scrape的时间序列上附加一些标签，用来识别scrape的目标。

job：目标所属的已配置job名称。
instance：:已刮擦的目标URL 的一部分。

对于每次实例 scrape，Prometheus都会在以下时间序列中存储样本：

upjob=“”, instance=“”：1如果实例是健康的，即可达，或者0刮擦失败。
scrape_duration_secondsjob=“”, instance=“”：刮擦持续时间。
scrape_samples_post_metric_relabelingjob=“”, instance=“”：应用度量标准重新标记后剩余的样本数。
scrape_samples_scrapedjob=“”, instance=“”：目标暴露的样本数。
scrape_series_addedjob=“”, instance=“”：该刮擦中新系列的大致数量。v2.10中的新功能。

up时间序列对于实例可用性监视非常有用。

5.4、存储机制

Prometheus包含一个存储在本地磁盘的时间序列数据库，同时也支持与远程存储系统集成，比如grafana cloud提供的免费云存储API，只需将remote_write接口信息填写在Prometheus配置文件即可。

Prometheus的本地存储，即TSDB时序数据库，本地存储给Prometheus带来了简单高效的使用体验，prometheus2.0以后压缩数据能力也得到了很大的提升。可以在单节点的情况下满足大部分用户的监控需求。

下图是prometheus存储在时序数据库中的数据样本：

在存储时可以通过name label来标记metric name，再通过标识符@来标识时间，这样构成了一个完整的时序数据样本。例如：

__name__="http_requests_total",method="GET	", handler="/api/v1/items"   @1649483597.197     17

下图为数据存入TSDB时序数据库的简易图

数据大致的存储顺序：

数据以（k,v）的形式，首先进入Head中，存入Head中的active chunk，active chunk也是唯一一个可以主动写入数据的单元，为了防止内存数据丢失还会做一次预写日志 WAL(write-ahead-log)，当chunk中数据的时间超过两分钟或数量大于120时，就会将旧的数据截断为head_chunk1。head_chunk1被刷新到磁盘然后进行内存映射。active chunk继续写入数据、截断数据、写入到内存映射，内存映射应该只加载最新的、最被频繁使用的数据，所以Prometheus TSDB就会将旧数据刷新到磁盘持久化存储Block。

当然Prometheus的存储机制不只有这些内容，本文只是浅提了一嘴，如果想要深层次的了解可以参考下面的文章：

普罗米修斯TSDB（第1部分）：头块 |加内什·韦尔内卡尔 (ganeshvernekar.com)

6、PromQL

Prometheus 提供了其它大量的内置函数，可以对时序数据进行丰富的处理，基础语法可参考官方文档：

查询函数 |普罗米修斯 (prometheus.io)

PromQL 内置函数 (daichangya.github.io)

7、AlertManager

6.1、概述

Prometheus 包含一个报警模块，就是我们的 AlertManager，Alertmanager 主要用于接收 Prometheus 发送的告警信息，它支持丰富的告警通知渠道，而且很容易做到告警信息进行去重，降噪，分组等，是一款前卫的告警通知系统。

6.2、工作流程

Prometheus发出告警时分为两个部分。Prometheus服务器按告警规则（rule_files配置块）将警报发送到Alertmanager（告警规则是在Prometheus上定义的）。然后，由Alertmanager 来管理这些警报，包括去重（Deduplicating）、分组（Grouping）、沉默（silencing），抑制（inhibition），聚合（aggregation），最终通过电子邮件发出通知，对呼叫通知系统，以及即时通讯平台，将告警通知路由（route）给对应的联系人。

6.3、配置详解

# 设置告警规则(这里是属于prometheus的配置，需要先设置了告警规则，才可以让prometheus去触发，接着AlertManager才会收到告警信息)
# PrometheusRule
apiVersion: monitoring.coreos.com/v1  #资源版本
kind: PrometheusRule                  #资源类型(注意这是自定义的资源类型)
metadata:
  labels:
    prometheus: k8s
    role: alert-rules
  name: node-alert-rule               #资源名称
  namespace: monitoring               #资源所属的命名空间 
spec:
  groups:
  - name: node-alert                  #告警名称(自定义)
    rules:
    - alert: disk_load_high           #告警类型的名称(自定义)
      lables: 
      	type: node                    #这个标签下的所有标签都会在触发告警时(且有默认的参数)，回调给AlertManager(一般可以用这个标签作为AlertManager分组的条件)，例如我现在写的type标签，后期就可以用这个标签做为group的条件
      annotations:                    #这个标签下的所有标签都会在触发告警时，回调给AlertManager(一般可以用这个标签携带一些自定义的参数)
        description: "主机磁盘占用率超过预警限制"
        alerttype: "node-alert"
        severity: "warning"
      expr: |                         #这个标签下就是我们计算指标的PromQl，符合条件的时候就会触发告警
        sum(node_filesystem_avail_bytesinstance="node",fstype!="rootfs",mountpoint="/" / 			
        node_filesystem_size_bytesinstance="node", fstype!="rootfs",mountpoint="/" > 0.1) 
        by (instance)
      for: 1m                         #扫描周期

# 设置接收告警信息的规则
# AlertManager
# 可自行搜索详细配置，这里只介绍部分的配置
alertmanager.yaml:

global:
# 如果经过这个时间，prometheus没有向发送告警，那就会把告警设置标记为已解决(仅为标记，不会影响到之前收到的告警信息的发送)
  resolve_timeout: 5m
route:
  receiver: 'null'                    # 设置默认的接收者
  group_by:
  - pod
  - namespace
  group_interval: 8h                  # 分组的周期
  group_wait: 30s                     # 分组前等待
  repeat_interval: 8h                 # 重复信息的间隔
  routes:                             # 路由的匹配规则
  - match:
      alertname: Watchdog             # 匹配告警名称
    receiver: 'null'
  - match:
      alertname: disk_load_high       # 设置告警规则时设置了这个名称
    receiver: devin					  # 这个配置的意思就是将disk_load_high这个名字的告警信息转发给接收者为devin的地址
receivers:                            # 路由的配置
- name: devin                         # 接收者名称
  webhook_configs:                    # 接收者的配置
  - url: http://localhost:8080/prometheus/alertMessage/add
    send_resolved: true
- name: default
  webhook_configs:
  - url: http://localhost:8080/prometheus/alertMessage/add
    send_resolved: true
- name: 'null'

8、Grafana可视化界面

8.1、简介

Grafana 是一个监控仪表系统，它是由 Grafana Labs 公司开源的的一个系统监测 (System Monitoring) 工具。它可以大大帮助你简化监控的复杂度，你只需要提供你需要监控的数据，它就可以帮你生成各种可视化仪表。同时它还有报警功能，可以在系统出现问题时通知你。

8.2、工作原理

Grafana是一个可以和Prometheus一起使用的开源项目，之所以可以非常美观的展示各项监控数据，其实是这个项目已经事先写了大量的PromQl用于满足用户的需要，并且将这些数据以多种形态展示出来，有兴趣可以参考一些有关的文档。

顺带一提的是，Prometheus有自己的可视化界面，在该界面上可以通过写PromQl来查询需要的指标。

将数据按照instance分组，并进行累加。

9、自定义Prometheus的监控指标

Spring Boot 提供了许多已经实现的监控指标，但是有时候我们需要自定义一些特定的监控指标，以便更好地监控我们的应用程序。

具体的实现流程，可查看我下一篇文档。

10、注意事项

10.1、Prometheus

Prometheus 的数据是基于时序的 float64 的值，如果你的数据值还有其他类型，Prometheus 则无法满足。
Prometheus 不适合做审计计费，因为它的数据是按一定时间采集的，关注的更多是系统的运行瞬时状态以及趋势，即使有少量数据没有采集也能容忍，但是审计计费需要记录每个请求，并且数据长期存储，这个和 Prometheus 无法满足，可能需要采用专门的审计系统。

10.2、AlertManager

AlertManager的配置中有四个关于时间的配置项，加上Prometheus告警规则的扫描周期，一共有五个配置时间的，极端的情况下，这几个时间很有可能会叠加，导致我们配置的告警周期和真实收到的不一致

参考文档：

容器监控实践—Prometheus基本架构 - 简书 (jianshu.com)

Prometheus 入门-阿里云开发者社区 (aliyun.com)

鸡汤送上：

心中有梦，脚下有路，每一种热爱都值得全力以赴!

最后说明：

创作不易，若转载请标明出处或原文链接！！！

以上是关于Prometheus入门教程的主要内容，如果未能解决你的问题，请参考以下文章

prometheus视频教程

Prometheus在kubernetes集群的搭建教程

Prometheus 入门篇

1.Prometheus快速入门,Prometheus+node_exporter安装

prometheus-入门尝试