Prometheus2.30.3

星期二, 4月 22, 2025 | 19分钟阅读

MyraZ

关于Prometheus2.30.3 的学习。

监控系统

监控概论

监控系统在这里特指对数据中心的监控，主要针对数据中心内的硬件和软件进行监控和告警。企业的 IT 架构逐步从传统的物理服务器，迁移到以虚拟机为主导的 IaaS 云。无论基础架构如何调整，都离不开监控系统的支持。

不仅如此。越来越复杂的数据中心环境对监控系统提出了更越来越高的要求：需要监控不同的对象，例如容器，分布式存储，SDN网络，分布式系统。各种应用程序等，种类繁多，还需要采集和存储大量的监控数据，例如每天数TB数据的采集汇总。以及基于这些监控数据的智能分析，告警及预警等。

在每个企业的数据中心内，或多或少都会使用一些开源或者商业的监控系统。从监控对象的角度来看，可以将监控分为网络监控，存储监控，服务器监控和应用监控等，因为需要监控数据中心的各个方面。所以监控系统需要做到面面俱到，在数据中心中充当“天眼“角色。

监控分类

google指出，监控分为白盒监控和黑盒监控之分。

白盒监控：通过监控内部的运行状态及指标判断可能会发生的问题，从而做出预判或对其进行优化。
黑盒监控：监控系统或服务，在发生异常时做出相应措施。

监控的目的如下：

根据历史监控数据，对未来做出预测
发生异常时，即使报警，或做出相应措施
根据监控报警及时定位问题根源
通过可视化图表展示，便于直观获取信息

总结：
监控系统：
特指对数据中心的监控，主要针对数据中心内的硬件和软件进行监控和告警
例如node、zookeeper、hadoop等
分类
白盒监控
监控内部的运行状态及指标判断可能会发生的问题
黑盒监控
监控系统或服务
目的
根据历史监控数据，对未来做出预测
发生异常时，即使报警，或做出相应措施
根据监控报警及时定位问题根源
通过可视化图表展示，便于直观获取信息

时序数据库

TSDB(Time Series Database) 时序数据库。常见时序数据库有InfluxDB、Kdb+、Prometheus、Graphite、TimescaleDB、阿里云TSDB。

时序数据

时序数据库全称为时间序列数据库。时间序列数据库指主要用于处理带时间标签的数据，带时间标签的数据也称为时间序列数据。

时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线，往过去看可以做成多纬度报表，揭示其趋势性、规律性、异常性;往未来看可以做大数据分析，机器学习，实现预测和预警等功能。

对比传统数据库仅仅记录了数据的当前值，时序数据库则记录了所有的历史数据。同时时序数据的查询也总是会带上时间作为过滤条件。

如图度量为Wind，每一个数据点都具有一个timestamp，两个field：direction和speed，两个tag：sensor、city。
它的第一行和第三行，存放的都是sensor号码为95D8-7913的设备，属性城市是上海。
随着时间的变化，风向和风速都发生了改变，风向从23.4变成23.2；而风速从3.4变成了3.3。

数据库特点

大部分时间都是写入操作。
写入操作几乎是顺序添加，大多数时候数据到达后都以时间排序。
写操作很少写入很久之前的数据，也很少更新数据。大多数情况在数据被采集到数秒或者数分钟后就会被写入数据库。
删除操作一般为区块删除，选定开始的历史时间并指定后续的区块。很少单独删除某个时间或者分开的随机时间的数据。
基本数据大，一般超过内存大小。一般选取的只是其一小部分且没有规律，缓存几乎不起任何作用。
读操作是十分典型的升序或者降序的顺序读。
高并发的读操作十分常见。

应用场景

时间序列数据主要由电力行业、化工行业、气象行业、地理信息等各类型实时监测、检查与分析设备所采集、产生的数据。

这些工业数据的典型特点是：产生频率快（每一个监测点一秒钟内可产生多条数据）、严重依赖于采集时间（每一条数据均要求对应唯一的时间）、测点多信息量大（常规的实时监测系统均有成千上万的监测点，监测点每秒钟都产生数据，每天产生几十GB的数据量）。

总结：
时序数据库：
主要用于处理带时间标签的数据
时间序列数据：带时间标签的数据，基于时间的一系列的数据。
特点
数据基于时间而产生
大量的查询是基于时间进行查询
很少对历史的数据进行修改，因为是无意义的
很少对数据进行删除，当数据确定无效之后，统一整体进行删除，而且删除的数据都是最先发生的数据
数据基本上都是顺序添加
应用场景
时间序列数据主要由电力行业、化工行业、气象行业、地理信息等各类型实时监测、检查与分析设备所采集、产生的数据

软件介绍

软件简介

Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发，是Google BorgMon监控系统的开源版本。
2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。
Prometheus性能也足够支撑上万台规模的集群。
官网： https://prometheus.io/

优点

强大的多维度数据模型：
- 时间序列数据通过 metric 名和键值对来区分。
- 所有的 metrics 都可以设置任意的多维标签。
- 数据模型更随意，不需要刻意设置为以点分隔的字符串。
- 可以对数据模型进行聚合，切割和切片操作。
- 支持双精度浮点类型，标签可以设为全 unicode。
灵活而强大的查询语句（PromQL）：在同一个查询语句，可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。
易于管理： Prometheus server 是一个单独的二进制文件，可直接在本地工作，不依赖于分布式存储。
高效：平均每个采样点仅占 3.5 bytes，且一个 Prometheus server 可以处理数百万的 metrics。
使用 pull 模式采集时间序列数据，这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的 metrics。
可以采用 push gateway 的方式把时间序列数据推送至 Prometheus server 端
可以通过服务发现或者静态配置去获取监控的 targets。
有多种可视化图形界面。
易于伸缩。

应用场景

适用场景
- Prometheus在记录纯数字时间序列方面表现非常好。它既适用于面向服务器等硬件指标的监控，也适用于高动态的面向服务架构的监控。对于现在流行的微服务，Prometheus的多维度数据收集和数据筛选查询语言也是非常的强大。Prometheus是为服务的可靠性而设计的，当服务出现故障时，它可以使你快速定位和诊断问题。它的搭建过程对硬件和服务没有很强的依赖关系。
不适用场景
- Prometheus它的价值在于可靠性，甚至在很恶劣的环境下，你都可以随时访问它和查看系统服务各种指标的统计信息。如果你对统计数据需要100%的精确，它并不适用，例如：它不适用于实时监控系统。

软件架构

生态圈组件

Prometheus Server（核心服务）
- Prometheus Server 是 Prometheus 组件中的核心部分，负责实现对监控数据的获取，存储以及查询。
- Prometheus Server 可以通过静态配置管理监控目标，也可以配合使用 Service Discovery 的方式动态管理监控目标，并从这些监控目标中获取数据。
- Prometheus Server 需要对采集到的监控数据进行存储，Prometheus Server 本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。
- Prometheus Server 对外提供了自定义的 PromQL 语言，实现对数据的查询以及分析。
- Prometheus Server 内置的 Express Browser UI，通过这个 UI 可以直接通过 PromQL 实现数据的查询以及可视化。
Client Library
- 客户端库，为需要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当Prometheus server 来 pull 时，直接返回实时状态的 metrics。
Push Gateway
- 主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这类jobs推送它们的 metrics到 Push Gateway，Prometheus Server再从Push Gateway中获取。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter。
Exporters
- 用于暴露已有的第三方服务的 metrics 给 Prometheus。
- 主要用来采集数据，并通过 HTTP 服务的形式暴露给 Prometheus Server，Prometheus Server通过访问该 Exporter 提供的接口，即可获取到需要采集的监控数据。常见的Exporter有很多，例如node_exporter、mysqld_exporter、haproxy_exporter 等，支持如 HAProxy、StatsD、Graphite、Redis 此类的服务监控；
Alertmanager
- 从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对的接收方式，发出报警。常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等。

工作流程

Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控。不需要任何SDK或者其他的集成过程。这样做非常适合做虚拟化环境监控系统，比如VM、Docker、Kubernetes等。
输出被监控组件信息的HTTP接口被叫做exporter 。目前互联网公司常用的组件大部分都有exporter可以直接使用，比如Varnish、Haproxy、Nginx、MySQL、Linux系统信息(包括磁盘、内存、CPU、网络等等)。
prometheus根据配置定时去拉取各个节点的数据，默认使用的拉取方式是pull，也可以使用pushgateway提供的push方式获取各个监控节点的数据。将获取到的数据存入TSDB，一款时序型数据库。
此时prometheus已经获取到了监控数据，可以使用内置的PromQL进行查询。它的报警功能使用Alertmanager提供，Alertmanager是prometheus的告警管理和发送报警的一个组件。
prometheus原生的图标功能过于简单，可将prometheus数据接入grafana，由grafana进行统一管理。

总结：
软件架构
Prometheus Server（核心服务）
它本身就是一款时序数据库，它的数据都存储在磁盘上。
它要去拉取数据，基于服务发现找到目标服务器，然后将数据拉取到TSDB
它既然是数据库就要支持数据的查询，PromQL就是查询语言
拉取数据
长生命周期job：每个任务专有一个xxxExporter。它的作用就是收集指标，这个Exporter接口是每个软件自己开发的，根据自己的需求也可以自定义自已的Exporter
短生命周期job：短生命周期的任务存活时间不可控，需要任务将自己重要的指标发送给PushGateway。
告警系统
当Prometheus 收集到的数据达到阈值，就会进行告警
将告警信息推送给AlterManaer，告警系统会发送邮件等信息给管理者
信息查询
监控每间隔一段时间使用PromQL查询TSDB，就可以获取最新的任务的执行状况
最终将信息呈现给WebUl或者Grafana

数据存储

存储方式

主要有两种数据持久化方式：本地存储和远端存储。

本地存储
存储最近发生的数据，优先考虑SSD。
通过Prometheus自带的TSDB（时序数据库），将数据保存到本地磁盘，为了性能考虑，建议使用SSD。但本地存储的容量毕竟有限，建议不要保存超过一个月的数据。Prometheus本地存储经过多年改进，自Prometheus 2.0后提供的V3版本TSDB性能已经非常高，可以支持单机每秒1000w个指标的收集。
远端存储
大量历史监控数据的存储和查询。
通过中间层的适配器的转化，Prometheus将数据保存到远端存储。适配器实现Prometheus存储的remote write和remote read接口，并把数据转化为远端存储支持的数据格式。目前，远端存储主要包括OpenTSDB、InfluxDB、Elasticsearch、M3DB等，其中M3DB是目前非常受欢迎的后端存储。

Prometheus本地数据存储能力一直为大家诟病，但Prometheus本地存储设计的初衷就是为了监控数据的查询，Facebook发现85％的查询是针对26小时内的数据。所以Prometheus本地时序数据库的设计更多考虑的是高性能而非分布式大容量。

数据模型

prometheus采集到的监控数据均以metric（指标）形式保存在时序数据库中（TSDB），属于同一指标名称，同一标签集合的、有时间戳标记的数据流。
每一条时间序列由 metric 和 labels 组成，每条时间序列按照时间的先后顺序存储它的样本值。

默认情况下各监控client向外暴露一个HTTP服务，prometheus会通过pull方式获取client的数据，数据格式如下：

# 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

####################################################
井号表示注释信息，解释了每一个指标的监控目的和类型
node_cpu表示监控指标的名称
{}内的内容是标签，以键值对的方式记录
数字是这个指标监控的数据

横坐标代表的是时间（时间戳的方式记录在TSDB中），纵坐标代表了各种不同的指标名称，坐标系中的黑点代表了各个指标在不同时间下的值。
每一个横线 就是时间序列
每个黑点就是样本（prometheus将样本以时间序列的方式保存在内存中，然后定时保存到硬盘上）
样本由三部分组成
	指标（metric）：指标名称和描述当前样本特征的 labelsets；
	时间戳（timestamp）：一个精确到毫秒的时间戳；
	样本值（value）： 一个 folat64 的浮点型数据表示当前样本的值。

指标格式

指标（metric）的格式：

<metric name>{<label name>=<label value>, ...}

指标名称反映的是监控了什么。
标签反映的是样本的维度，可以理解成指标的细化。
标签的名称只能由 ASCII 字符、数字以及下划线组成并满足正则表达式 [a-zA-Z_][a-zA-Z0- 9_]*。其中以 _作为前缀的标签是系统保留的关键字，只能在系统内部使用。
标签的值则可以包含任何 Unicode 编码的字符。

案例数据：

api_http_requests_total{method=``"POST"``, handler=``"/messages"``}

指标是“api_http_requests_total”，含义是通过api请求的http总数。
标签“method=“POST”” “handler="/messages"“代表了这些http请求中 POST 请求并且 handler是/messages的数量

指标类型

Prometheus 的客户端库中提供了四种核心的指标类型。

Counter（计数器）

定义：单调递增的累计指标，重启时归零
典型的应用如：请求的个数，结束的任务数，出现的错误数等等。
适用于生成请求次数、错误次数等指标。
特征
- 只能增加不能减少（除重启外）
- 适合记录「总量」型数据
- 通常配合 rate() 或 increase() 函数使用

示例

# HTTP请求总数
http_requests_total{method="POST", handler="/api"}

Gauge（仪表盘）

定义：反映当前瞬时状态的任意数值
典型的应用如：温度，运行的 goroutines(线程) 的个数。可以任意加减。
Gauge 是一个用来记录实时值的指标，常用于表示CPU使用率、内存使用率、线程数等指标。
特征
- 可增可减
- 适合记录「当前状态」值
- 直接反映系统瞬时状态

示例

# 当前内存使用量
node_memory_MemFree_bytes
# 当前活跃连接数
node_netstat_TCP_CurrEstab

# 实时CPU使用率
100 - (avg by (instance)(irate(node_cpu_seconds_total{mode="idle"}[1m])) * 100

Histogram（直方图）

定义：对观测值进行分桶统计
数据结构
- <metric>_bucket{le="<上限>"}：各桶计数器
- <metric>_sum：所有观测值总和
- <metric>_count：总观测次数
典型的应用如：请求持续时间，响应大小。可以对观察结果采样，分组及统计。
特征
- 客户端分桶，服务端聚合
- 可计算分位数但精度有损
- 适合高基数数据

示例：

# Prometheus配置示例
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

Summary（摘要）

定义：在客户端预先计算好的分位数。
数据结构：
- <metric>{quantile="<φ>"}：预先计算的分位数
- <metric>_sum：总和
- <metric>_count：总数
类似于 Histogram, 典型的应用如：请求持续时间，响应大小。
提供观测值的 count 和 sum 功能。
Summary 类型是在客户端直接聚合生成的百分位数，即可以按百分比划分跟踪结果。

示例：

# Go GC耗时统计
go_gc_duration_seconds{quantile="0.5"}

四种指标类型对比

指标类型	特点	典型应用场景
Counter（计数器）	只增不减的累计数值	请求量、错误次数
Gauge（仪表盘）	可增可减的瞬时值	CPU使用率、内存占用
Histogram（直方图）	分桶统计的样本观测值	请求延迟、响应大小
Summary（摘要）	客户端计算的百分位数	复杂耗时统计

PromQL

Prometheus数据展现除了自带的WebUI还可以通过Grafana，他们本质上都是通过HTTP + PromQL的方式查询Prometheus数据。和关系型数据库的SQL类似，Prometheus也内置了数据查询语言PromQL，它提供对时间序列数据丰富的查询，聚合以及逻辑运算的能力。
PromQL (Prometheus Query Language) 是 Prometheus 自己开发的数据查询DSL语言。
数据运算方式：
- +（加法）
- -（减法）
- *（乘法）
- /（除法）
- %（求余）
- ^（幂运算）
聚合函数
- sum（求和）
- min（最小值）
- max（最大值）
- avg（平均值）
- stddev（标准差）
- stdvar（标准差异）
- count（计数）
- count_values（对value进行计数）
- bottomk（后n条）
- topk（前n条）
- quantile（分布统计）

prometheus安装

下载地址：https://prometheus.io/download/

下载上传解压

[root@node01 ~]# tar -zxvf prometheus-2.30.3.linux-amd64.tar.gz -C /opt/yjx/
[root@node01 ~]#  mv /opt/yjx/prometheus-2.30.3.linux-amd64  /opt/yjx/prometheus-2.30.3
[root@node01 ~]# rm -rf prometheus-2.30.3.linux-amd64.tar.gz

修改配置文件

[root@node01 ~]#  vim /opt/yjx/prometheus-2.30.3/prometheus.yml

20 # Here it's Prometheus itself.
21 scrape_configs:
22 # The job name is added as a label `job=<job_name>` to any timeseries
scraped from this config.
23 - job_name: "prometheus"
24
25 # metrics_path defaults to '/metrics'
26 # scheme defaults to 'http'.
27
28 static_configs:
29 - targets: ["192.168.126.101:9090"]

添加环境变量

[root@node01 ~]# vim /etc/systemd/system/prometheus.service

[Unit]
Description=prometheus
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=root
ExecStart=/opt/yjx/prometheus-2.30.3/prometheus \
--config.file=/opt/yjx/prometheus-2.30.3/prometheus.yml \
--storage.tsdb.path=/opt/yjx/prometheus-2.30.3/data/ \
--web.enable-lifecycle
[Install]
WantedBy=multi-user.target

[root@node01 ~]# systemctl daemon-reload

Perometues启动

[root@node01 ~]# systemctl start prometheus
[root@node01 ~]# systemctl status prometheus

访问地址：http://192.168.126.101:9090/

Exporter数据采集

安装Exporter

全量配置信息： https://prometheus.io/docs/instrumenting/exporters/ https://github.com/prometheus
上传node_exporter到要监控的服务器

[root@node01 ~]# tar -zxvf node_exporter-1.2.2.linux-amd64.tar.gz -C /opt/yjx/
[root@node01 ~]# mv /opt/yjx/node_exporter-1.2.2.linux-amd64 /opt/yjx/node_exporter-1.2.2
[root@node01 ~]# rm -rf node_exporter-1.2.2.linux-amd64.tar.gz

分发到node02、node03。

[root@node01 ~]# yjxrsync /opt/yjx/node_exporter-1.2.2/

设置开机自启动

[root@node01 ~]# vim /etc/systemd/system/node_exporter.service
[root@node02 ~]# vim /etc/systemd/system/node_exporter.service
[root@node03 ~]# vim /etc/systemd/system/node_exporter.service

[Unit]
Description=node_exporter
After=network.target
[Service]
Type=simple
User=root
ExecStart=/opt/yjx/node_exporter-1.2.2/node_exporter
Restart=on-failure
[Install]
WantedBy=multi-user.target

[root@node01 ~]# systemctl daemon-reload
[root@node01 ~]# systemctl start node_exporter
[root@node01 ~]# systemctl start node_exporter

[root@node02 ~]# systemctl daemon-reload
[root@node02 ~]# systemctl start node_exporter
[root@node02 ~]# systemctl start node_exporter

[root@node03 ~]# systemctl daemon-reload
[root@node03 ~]# systemctl start node_exporter
[root@node03 ~]# systemctl start node_exporter

数据拉取

[root@node01 ~]# vim /opt/yjx/prometheus-2.30.3/prometheus.yml

  - job_name: 'yjx-nodes'
    static_configs:
      - targets: ['192.168.126.101:9100','192.168.126.102:9100','192.168.126.103:9100']

软件热加载

[root@node01 ~]# curl -XPOST http://192.168.126.101:9090/-/reload

数据查询 prometheus_http_request_duration_seconds_bucket{job=“prometheus”}

AlterManager

简单介绍

Alertmanager是一个独立的告警模块，接收Prometheus等客户端发来的警报，之后通过分组、删除重复等处理，并将它们通过路由发送给正确的接收器；告警方式可以按照不同的规则发送给不同的模块负责人，Alertmanager支持Email, Slack，等告警方式, 也可以通过webhook接入钉钉等国内IM工具。
Prometheus的警报分为两个部分。Prometheus服务器中的警报规则将警报发送到Alertmanager。该Alertmanager 然后管理这些警报，包括沉默，抑制，聚集和通过的方法，如电子邮件发出通知，对呼叫通知系统，以及即时通讯平台。

告警规则

分组
- 分组将类似性质的警报分类为单个通知。当许多系统同时发生故障并且可能同时触发数百到数千个警报时，此功能特别有用。
- 示例：发生网络分区时，群集中正在运行数十个或数百个服务实例。您有一半的服务实例不再可以访问数据库。Prometheus中的警报规则配置为在每个服务实例无法与数据库通信时为其发送警报。结果，数百个警报被发送到Alertmanager。作为用户，人们只希望获得一个页面，同时仍然能够准确查看受影响的服务实例。因此，可以将Alertmanager配置为按警报的群集和警报名称分组警报，以便它发送一个紧凑的通知。
- 警报的分组，分组通知的时间以及这些通知的接收者由配置文件中的路由树配置。
沉默
- 沉默是一种简单的特定时间静音提醒的机制。一种沉默是通过匹配器来配置，就像路由树一样。传入的警报会匹配RE，如果匹配，将不会为此警报发送通知。
- 在Alertmanager的Web界面中配置沉默。
抑制
- 抑制是指当警报发出后，停止重复发送由此警报引发其他错误的警报的机制。
- 例如，当警报被触发，通知整个集群不可达，可以配置Alertmanager忽略由该警报触发而产生的所有其他警报，这可以防止通知数百或数千与此问题不相关的其他警报。
- 抑制机制可以通过Alertmanager的配置文件来配置。

软件安装

Prometheus开启告警

[root@node01 ~]# vim /opt/yjx/prometheus-2.30.3/prometheus.yml

# Alertmanager configuration alertmanager的地址
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - 192.168.88.101:9093
            
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  - "/opt/yjx/prometheus-2.30.3/rules/*.yml"

[root@node01 ~]# mkdir -p /opt/yjx/prometheus-2.30.3/rules

## node_alived.yml
groups:
- name: 实例存活告警规则
	rules:
	- alert: 实例存活告警
	expr: up == 0
	for: 1m
	labels:
		user: prometheus
		severity: warning
	annotations:
		summary: "主机宕机 !!!"
		description: "该实例主机已经宕机超过一分钟了。"

[root@node01 ~]# vim /opt/yjx/prometheus-2.30.3/rules/memory_over.yml

## memory_over.yml
groups:
- name: 内存报警规则
  rules:
  - alert: 内存使用率告警          expr: (1 - (node_memory_MemAvailable_bytes /(node_memory_MemTotal_bytes))) * 100 > 50
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: "服务器可用内存不足。"
      description: "内存使用率已超过50%（当前>值：{{ $value }}%）"

[root@node01 ~]# vim /opt/yjx/prometheus-2.30.3/rules/cpu_over.yml

## cpu_over.yml
groups:
- name: CPU报警规则
  rules:
  - alert: CPU使用率告警
    expr:  100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[1m]))) * 100 > 50    
    for: 1m    
    labels:      
      severity: warning    
    annotations:      
      summary: "CPU使用率正在飙升。"
      description: "CPU使用率超过50%（当前值：{{ $value }}%）"

[root@node01 ~]# vim /opt/yjx/prometheus-2.30.3/rules/disk_over.yml

## disk_over.yml
groups:
- name: 磁盘使用率报警规则 
  rules:
  - alert: 磁盘使用率告警    
    expr: 100 - node_filesystem_free_bytes{fstype=~"xfs|ext4"} /node_filesystem_size_bytes{fstype=~"xfs|ext4"} * 100 > 80
    for: 20m
    labels:
      severity: warning
    annotations:
      summary: "硬盘分区使用率过高"
      description: "分区使用大于80%（当前值：{{ $value }}%）"

重启Prometheus

[root@node01 ~]# curl -XPOST http://192.168.126.101:9090/-/reload

打开Prometheus WebUI 查看告警信息
- Inactive：没有触发阈值
- Pending：已触发阈值但未满足告警持续时间
- Firing：已触发阈值且满足告警持续时间

开始安装alertmanager

[root@node01 ~]# tar -zxvf alertmanager-0.23.0.linux-amd64.tar.gz -C /opt/yjx/
[root@node01 ~]# mv /opt/yjx/alertmanager-0.23.0.linux-amd64 /opt/yjx/alertmanager-0.23.0
[root@node01 ~]# rm -rf alertmanager-0.23.0.linux-amd64.tar.gz

修改配置文件

[root@node01 ~]# vim /opt/yjx/alertmanager-0.23.0/alertmanager.yml

# 全局配置项
global:
  resolve_timeout: 5m #超时,默认5min
  smtp_smarthost: 'smtp.qq.com:465' #邮箱smtp服务
  smtp_from: '2697273721@qq.com'
  smtp_auth_username: '2697273721@qq.com'
  smtp_auth_password: 'tbdifenbpjbjdcej'
  smtp_require_tls: false

# 定义模板信息
templates:
  - '/opt/yjx/alertmanager-0.23.0/template/*.tmpl' # 路径

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'mail'
receivers:
- name: 'mail'
  email_configs:
  - to: '{{ template "email.to" . }}' #接收警报的email
    html: '{{ template "email.to.html" . }}' # 模板
    send_resolved: true

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

创建发送模板

[root@node01 ~]# mkdir -p /opt/yjx/alertmanager-0.23.0/template
[root@node01 ~]# vim /opt/yjx/alertmanager-0.23.0/template/email.tmpl

{{ define "email.from" }}2697273721@qq.com{{ end }}
{{ define "email.to" }}2539666915@qq.com{{ end }}
{{ define "email.to.html" }}
{{ range .Alerts }}
=========start==========<br>
告警程序: yjxxt_prometheus_alert <br>
告警级别: {{ .Labels.severity }} 级 <br>
告警类型: {{ .Labels.alertname }} <br>
故障主机: {{ .Labels.instance }} <br>
告警主题: {{ .Annotations.summary }} <br>
告警详情: {{ .Annotations.description }} <br>
触发时间: {{ .StartsAt.Format "2006-01-02 15:04:05" }} <br>
=========end==========<br>
{{ end }}
{{ end }}

添加环境变量

[root@node01 ~]# vim /etc/systemd/system/alertmanager.service

[Unit]
Description=alertmanager
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=root
ExecStart=/opt/yjx/alertmanager-0.23.0/alertmanager \
    --config.file /opt/yjx/alertmanager-0.23.0/alertmanager.yml \
    --storage.path /opt/yjx/alertmanager-0.23.0/data/

[Install]
WantedBy=multi-user.target

[root@node01 ~]# systemctl daemon-reload
[root@node01 ~]# systemctl start alertmanager
[root@node01 ~]# systemctl status alertmanager

网络访问
- http://192.168.126.101:9093
- 关闭主机102，AlertManager会发送邮件提醒

附录

基本信息配置

--web.listen-address=":9100"
#node_exporter监听的端口，默认是9100，若需要修改则通过此参数。

--web.telemetry-path="/metrics"
#获取metric信息的url，默认是/metrics，若需要修改则通过此参数

--log.level="info"
#设置日志级别

--log.format="logger:stderr"
#设置打印日志的格式，若有自动化日志提取工具可以使用这个参数规范日志打印的格式

通过正则表达式来屏蔽或选择某些监控项

--collector.diskstats.ignored-devices="^(ram|loop|fd|(h|s|v|xv)d[a-z]|nvme\\d+n\\d+p)\\d+$"
#通过正则表达式忽略某些磁盘的信息收集

--collector.filesystem.ignored-mount-points="^/(dev|proc|sys|var/lib/docker/.+)
($|/)"
#通过正则表达式忽略某些文件系统挂载点的信息收集

--collector.filesystem.ignored-fs-types="^(autofs|binfmt_misc|bpf|cgroup2?|configfs|debugfs|devpts|devtmpfs|fusectl|hugetlbfs|mqueue|nsfs|overlay|proc|procfs|pstore|rpc_pipefs|securityfs|selinuxfs|squashfs|sysfs|tracefs)$"
#通过正则表达式忽略某些文件系统类型的信息收集

--collector.netclass.ignored-devices="^$"
#通过正则表达式忽略某些网络类的信息收集

--collector.netdev.ignored-devices="^$"
#通过正则表达式忽略某些网络设备的信息收集

--collector.netstat.fields="^$"
#通过正则表达式配置需要获取的网络状态信息

--collector.vmstat.fields="^(oom_kill|pgpg|pswp|pg.*fault).*"
#通过正则表达式配置vmstat返回信息中需要收集的选项

上一页 Grafana8.2.1

下一页 FineReportv11.0