文章目录
- Prometheus 优势
- Prometheus 的组件、架构
- Prometheus Server 直接从监控目标中或者间接通过推送网关来拉取监控指标,它在本地存储所有抓取到的样本数据,并对此数据执行一系列规则,以汇总和记录现有数据的新时间序列或生成告警。可以通过 Grafana 或者其他工具来实现监控数据的可视化
- 概念
- 数据模型
- 时间序列
- 指标名称
- 标签
- 样本
- 时间序列的表示方式
- 指标类型
- Counter(计数器)
- Gauge(仪表盘)
- Histogram(直方图)
- Summary(摘要)
- Jobs 和 Instance
- Prometheus 的部署(二进制)
- 创建 prometheus 根目录
- 官网下载 prometheus
- 上传 prometheus 到服务器并解压
- 为文件夹递归赋予可执行权限
- 创建软链接(或者直接改名文件夹)
- 前台启动 prometheus
- 另启一个终端,判断端口状态
- 关闭前台进程,准备更方便的后台进程
- 使用 promtool 检查语法正确性
- 创建自启动脚本(将 prometheus 自定义为服务)
- 重载系统配置及启动 prometheus
- 访问不了,我们看看端口状态
- 再看看服务状态
- 查看安装的文档结构
- 重新加载配置
- 查看 Prometheus 后台
- Exporter 组件
- 作用
- Exporter 类型
- 直接采集型
- 间接采集型
- 文本数据格式
- 配置 Linux 主机监控(Node Exporter)
- 安装 Exporter
- Prometheus server 关联 node_exporter(静态配置功能)
- 主配置文件介绍
- 添加 node_exporter 任务(注意对齐)
- 检查代码语法
- 查看当前 targets
- 重启 Prometheus server,看看对 node1 的监控
- metrics 数据采集
- 查看 node1 文件系统的总大小
- 查看 cpu 指标(图形呈现)
- 配置 Mysql 主机监控
- 部署 mariadb
- 添加用户 exporter
- node1 上安装配置 Exporter
- 官网下载 mysqld_exporter 二进制包解压缩
- 为 mysqld_exporter 赋予执行权限,并创建软链接
- 配置 mysqld_exporter 配置文件,存放用户名和密码
- 后台运行 mysqld_exporter
- 查看暴露的端口
- 关联 Prometheus server
- 添加 mysqld_exporter 任务
- 检查语法,重启 prometheus 监控
- 查看 Prometheus 后台
- 数据采集
- 查询 MySQL 最大连接数
- 查询吞吐量
- 查询当前连接数
- 服务发现
- 基于文件的服务发现
- 注释 proemtheus.yml 中的 exporters 配置
- 重启 prometheus 服务
- 准备 target 配置文件
- 修改 Prometheus 配置文件
- 重启服务
- 其他方法进行服务发现
- PromQL
- 时序数据库 TSDB
- 特点
- 时序数据库的基本要求
- 常见的时序数据库
- PromQL 操作符
- 数学运算
- 布尔运算
- 集合运算符
- 操作符优先级
- PromQL 聚合操作
- 例子
- sum()
- count_values()
- topk()
- quantile()
- 内置函数
- 计算 Counter (计数器)指标增长率
- increase() 函数
- rate() 函数
- irate() 函数
- 预测Gauge(仪表盘)指标变化趋势
- predict_linear函数()
- 统计Histogram(直方图)指标的分位数
- Grafana数据展示
- 部署Grafana
- 下载软件包并安装
- 安装grafana
- 启动服务,加入开机自启
- 看3000端口是否监听
- 访问Grafana
- 添加数据源
- 新建一个叫Prometheus的文件夹
- 创建仪表盘
- 添加node1磁盘可用空间的监测
- 添加更多监控项
- 仪表盘
- 保存仪表盘
- 使用第三方模板
- 根据需求选择合适的模板
- 回到仪表盘进行导入
- 展现当前Linux主机的全部状态
- Altermanager告警
- 概述
- 告警逻辑
- Altermanger机制
- 分组机制
- 抑制机制
- 静默机制
- Altermanager的部署
- 下载解压安装包
- 编辑Alertmanger配置文件
- 查看配置文件
- Alertmanager使用邮箱报警
- QQ邮箱准备
- 修改配置文件
- 后台启动Alertmanager
- 关联Prometheus
- 添加告警规则
- 在Prometheus配置文件中导入
- 用promtool检查语法
- 重启prometheus
- 在web中查看Rules
- 关闭node1测试
- 等一分钟看邮箱是否有告警
Prometheus 优势
- 强大的查询语言 PromQL
- 不依赖分布式存储
- 不依赖分布式存储;单个服务节点拥有自治能力
- 通过静态配置文件或服务发现来获取监控目标(zabbix 要进行手动配置)
- 支持多种类型的图表和仪表盘
Prometheus 的组件、架构
Prometheus Server 直接从监控目标中或者间接通过推送网关来拉取监控指标,它在本地存储所有抓取到的样本数据,并对此数据执行一系列规则,以汇总和记录现有数据的新时间序列或生成告警。可以通过 Grafana 或者其他工具来实现监控数据的可视化
组件 | 功能 |
---|---|
Prometheus server | 收集每个目标数据,并存储为时间序列数据,对外可提供数据查询支持和告警规则配置管理 |
Exporter | 用于输出被监控组件信息的 HTTP 接口 |
Pushgateway | 用于支持短期临时或批量计划任务工作的汇聚节点 |
Alertmanager | 用于处理 Prometheus 服务器端发送的 alerts 信息,对其去除重数据、分组并路由到正确的接收方式,发出告警;支持丰富的告警方式 |
Service Discovery | 动态发现待监控的 target,从而完成监控配置的重要组件 |
概念
数据模型
时间序列
- Prometheus 数据的基本单位
- Prometheus 采集的所有的监控数据均以 指标(metrics) 的形式保存在内置的时间序列数据库 TSDB 中
- 时间序列中的每一个点称为样本,每个样本由 度量名称(Metric Name)、标签(labels)、样本值(sample value)组成
- 指标名称及标签(键值对)是 时间序列的 唯一标识
指标名称
- 反映被监控样本的含义
- 如
httprequest_total
可以看出来表示当前系统接收到的 http 请求总量 - 指标名称只能由 ASCII 字符、数字、下划线以及冒号组成,同时必须匹配正则表达式
[a-zA-Z*:][a-zA-Z0-9_:]
标签
- 使用标签,Prometheus 开启了强大的多维数据模型
- 对于相同的指标名称,通过不同标签列表的集合,会形成特定的度量维度实例
- 例如,所有包含度量名称为
/api/tracks
的 http 请求,打上method=POST
的标签,就会形成具体的 http 请求 - 查询语言在这些指标和标签列表的基础上进行过滤和聚合,改变任何度量指标上的任何标签值(包括添加或删除指标),都会创建新的时间序列
- 标签的名称只能由 ASCII 字符、数字、以及下划线组成并满足正则表达式
[a-zA-Z_][a-zA-Z0-9_]*
- 标签的值则可以包含任何
Unicode
编码的字符
样本
在时间序列中的每一个点称为样本,样本由以下三部分组成
- 指标(metric):指标名称和描述当前样本特征的 labelset
- 时间戳:一个精确到时间毫秒的时间戳
- 样本值:一个浮点型数据表示当前样本的值
时间序列的表示方式
<metric name>{<label name>=<label value>, ...}
例:指标名称为 api_http_requests_total
,标签为 method="POST"
和 handler="/messages"
的时间序列可以表示为如下
api_http_requests_total{method="POST", handler="/messages"}
指标类型
四种核心指标类型(数据)
Counter(计数器)
-
计数器类型的度量 只能增加 或重置为零
-
常用于记录事件的累计次数,如请求数、错误数等。
-
例:利用 PromQL 内置操作函数对 http 请求量进行分析
# 通过rate()函数获取5min内http请求的增长率 rate(http_requests_total[5m]) # 通过topk()函数得出访问量前十的HTTP地址 topk(10,http_requests_total)
Gauge(仪表盘)
-
仪表盘类型的度量 可以任意增减
-
常用于表示瞬时值,如温度、内存使用量、当前并发请求数等
-
示例:利用 PromQL 内置操作函数获取样本在一段时间内的变化
# 利用delta()函数计算node1主机cpu温度在两小时内的变化 delta(cpu_temp_celsius{host="node1"}[2h]) # 利用predict_linear()函数基于两小时的样本数据,预测node2四个小时之后的磁盘空间剩余是否小于0 predict_linear(node_filesystem_free{job="node2"}[2h],4*3600)<0
Histogram(直方图)
-
直方图类型的度量用于记录 量化指标的分布情况(如 cpu 平均使用率、页面平均响应时间)
-
为了解决取全部平均值长尾问题:如大多数 api 请求响应时间在 100ms 以内、个别请求响应时间需要五秒,导致平均响应时间拉长
-
Histogram 在一段时间范围内(通常是请求持续时间或响应大小)对数据进行采样,并将其计入可配置的存储桶(bucket)中,之后可以通过指定区间筛选样本,也可以统计样本总数,最后的结果为直方图展示
-
例
-
统计样本的值分布在 bucket 中的数量:
<basename>_bucket{le="<上边界>"}
(即最大值小于等于上边界的数量)# 在总共2次请求当中。http 请求响应时间 <=0.005 秒 的请求次数为0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.005",} 0.0 # 在总共2次请求当中。http 请求响应时间 <=0.01 秒 的请求次数为0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.01",} 0.0 # 在总共2次请求当中。http 请求响应时间 <=0.025 秒 的请求次数为0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.025",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.05",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.075",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.1",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.25",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.5",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.75",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="1.0",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="2.5",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="5.0",} 0.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="7.5",} 2.0 # 在总共2次请求当中。http 请求响应时间 <=10 秒 的请求次数为 2 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="10.0",} 2.0 io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="+Inf",} 2.0
-
所有样本值的大小总和,命名为
<basename>_sum
# 发生的2次 http 请求总的响应时间为 13.107670803000001 秒 io_namespace_http_requests_latency_seconds_histogram_sum{path="/",method="GET",code="200",} 13.107670803000001
-
样本总数,命名为
<basename>_count
。值和<basename>_bucket{le="+Inf"}
相同。# 当前一共发生了 2 次 http 请求 io_namespace_http_requests_latency_seconds_histogram_count{path="/",method="GET",code="200",} 2.0
-
Summary(摘要)
- summary 与 histogram 功能相似,提供在某个区间抽样检查
- 但需要提前指定好动态百分位数(Quantiles)
Jobs 和 Instance
在 Prometheus 中,任何被采集的目标(每一个暴露监控样本数据的 HTTP 服务)都称为 一个 实例 Instance,通常对应单个进程
具有相同采集目的的实例集合叫做 作业 Job
Prometheus 的部署(二进制)
创建 prometheus 根目录
mkdir /prometheus
官网下载 prometheus
https://prometheus.io/download/
上传 prometheus 到服务器并解压
tar -zxvf prometheus-2.47.0.linux-amd64.tar.gz -C /prometheus/
为文件夹递归赋予可执行权限
chown -R root:root prometheus-2.47.0.linux-amd64/
创建软链接(或者直接改名文件夹)
ln -sv prometheus-2.47.0.linux-amd64/ prometheus
# 或者 mv prometheus-2.47.0.linux-amd64/ prometheus
或
前台启动 prometheus
./prometheus
# [ctrl]+c 终止
另启一个终端,判断端口状态
ss -ntl
这时理论上来说应该可以进行了,但是检查一番后发现没关防火墙,导致浏览器访问不到 Prometheus 后台
systemctl stop firewalld
setenforce 0
关闭前台进程,准备更方便的后台进程
使用 promtool 检查语法正确性
./promtool check config prometheus.yml
创建自启动脚本(将 prometheus 自定义为服务)
vim /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network.target
[Service]
Type=simple
Restart=on-failure
ExecStart=/data/prometheus/prometheus \
--config.file=/data/prometheus/prometheus.yml \
--storage.tsdb.path=/data/prometheus/data \
--web.listen-address=:9090 \
--web.enable-lifecycle
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target
重载系统配置及启动 prometheus
systemctl daemon-reload
systemctl enable prometheus.service
systemctl start prometheus.service
访问不了,我们看看端口状态
ss -ntl
发现没有暴露 prometheus 对应的 9090 端口
再看看服务状态
systemctl status prometheus
哦,发现一个很严重的问题
ExecStart=/data/prometheus/prometheus --config.file=/data/prometheus/prometheus.yml --storage.tsdb.path=/data/prometheus/data --web.listen-address=:9090 --web.enable-lifecycle (code=exited, status=203/EXEC)
服务配置文件里指定的文件路径错了
我们对应改成正确的
查看安装的文档结构
tree
# vim /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network.target
[Service]
Type=simple
Restart=on-failure
ExecStart=/prometheus/prometheus/prometheus \
--config.file=/prometheus/prometheus/prometheus.yml \
--storage.tsdb.path=/prometheus/prometheus/data \
--web.listen-address=:9090 \
--web.enable-lifecycle
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target
重新加载配置
systemctl daemon-reload
systemctl enable prometheus.service
systemctl start prometheus.service
查看 Prometheus 后台
Exporter 组件
作用
连接被监控系统和服务与 Prometheus 服务器之间的桥梁
主要作用包括:数据收集、数据转换、暴露监控接口等
Exporter 类型
直接采集型
- Exporters 内置响应程序,可以直接向 Prometheus 提供 target 数据支持
- 可以更好的监控各自系统内部的运行状态
- 适合自定义监控指标的项目实施
- 如 k8s 直接提供了给 Prometheus 的接口
间接采集型
- 原始监控项并不支持 Prometheus,需要使用 Prometheus 客户端编写监控目标的监控采集数据
- 如 Linux 操作系统本身不能直接支持 Prometheus,需要使用单独的
Node Exporter
文本数据格式
特点:良好的跨平台性和可读性
全部文本数据可以通过 curl [服务器ip]/metrics
获取到,Prometheus 后台搜索项是对这些 metrics 的过滤呈现
curl 192.168.28.88:9090/metrics
配置 Linux 主机监控(Node Exporter)
安装 Exporter
-
官网下载 node exporter 的二进制包并解压
mkdir /exporter tar -zxvf node_exporter-1.8.2.linux-amd64.tar.gz -C /exporter
-
为解压文件赋予执行权限
chown -R root:root /exporter/node_exporter-1.8.2.linux-amd64/
-
创建软链接
ln -sv /exporter/node_exporter-1.8.2.linux-amd64 /exporter/node_exporter
-
运行启动脚本后台启动 Node_exporter
cd /exporter/node_exporter ./node_exporter& # 加上`&`表示后台启动
-
jobs
命令查看后台进程jobs # fg %1 恢复前台运行
-
查看暴露的端口号
ss -ntl
Prometheus server 关联 node_exporter(静态配置功能)
通过修改 Prometheus server 的主配置文件 prometheus.yml
中的 static_config
参数来采集 node_exporter
提供的数据
主配置文件介绍
cat prometheus.yml
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).
# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: "prometheus"
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ["localhost:9090"]
global:
scrape_interval:每次数据采集的时间间隔,默认为1分钟
scrape_timeout:采集请求超时时间,默认为10秒
evaluation_interval:执行rules的频率,默认为1分钟
scrape_configs:主要用于配置被采集数据节点操作,每一个采集配置主要由以下几个参数
job_name:全局唯一名称
scrape_interval:默认等于global内设置的参数,设置后可以覆盖global中的值
scrape_timeout:默认等于global内设置的参数
metrics_path:从targets获取meitric的HTTP资源路径,默认是/metrics
honor_labels:Prometheus如何处理标签之间的冲突。若设置为True,则通过保留变迁来解决冲突;若设置为false,则通过重命名;
scheme:用于请求的协议方式,默认是http
params:数据采集访问时HTTP URL设定的参数
relabel_configs:采集数据重置标签配置
metric_relabel_configs:重置标签配置
sample_limit:对每个被已知样本数量的每次采集进行限制,如果超过限制,该数据将被视为失败。默认值为0,表示无限制
添加 node_exporter 任务(注意对齐)
- job_name: "node_exporter"
static_configs:
- targets: ["192.168.28.66:9100"]
检查代码语法
./promtool check config prometheus.yml
查看当前 targets
重启 Prometheus server,看看对 node1 的监控
systemctl restart prometheus
可以看到监测的 node1
metrics 数据采集
查看 node1 文件系统的总大小
对查询结果进行数学运算(node1 总空间约为 100G)
查看 cpu 指标(图形呈现)
node1 只分配了 2 核,且没有运行额外的进程,所以 cpu 曲线很平稳
配置 Mysql 主机监控
部署 mariadb
yum -y install mariadb-server # 安装mariadb服务端
systemctl enable --now mariadb
mysqladmin -uroot password '123456' # 初始化数据库并设置密码
mysql -uroot -p123456 -e "show databases;" # 测试数据库连接是否正常
添加用户 exporter
MariaDB [(none)]> grant all privileges on *.* to mysqld_exporter@'localhost' identified by '123456';
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> exit
node1 上安装配置 Exporter
官网下载 mysqld_exporter 二进制包解压缩
tar -zxvf mysqld_exporter-0.15.1.linux-amd64.tar.gz -C /exporter/
# exporter文件夹用的是是上个实验创建好的
为 mysqld_exporter 赋予执行权限,并创建软链接
chown -R root:root mysqld_exporter-0.15.1.linux-amd64/
ln -sv mysqld_exporter-0.15.1.linux-amd64 mysqld_exporter
配置 mysqld_exporter 配置文件,存放用户名和密码
# cd mysqld_exporter
# vim mysqld_exporter.cnf
[client]
user=mysqld_exporter
password=123456
后台运行 mysqld_exporter
./mysqld_exporter --config.my-cnf='mysqld_exporter.cnf' &
查看暴露的端口
关联 Prometheus server
添加 mysqld_exporter 任务
# vim prometheus.yml
- job_name: 'mysqld_exporter'
# scrape_interval: 10s # 设置抓取间隔为 10 秒
static_configs:
- targets: ["192.168.28.66:9104"]
检查语法,重启 prometheus 监控
./promtool check config prometheus.yml
systemctl restart prometheus
查看 Prometheus 后台
数据采集
查询 MySQL 最大连接数
查询吞吐量
查询当前连接数
我们再到客户端连接一下
mysql —uroot -p123456
服务发现
Prometheus 服务发现可以自动发现并监控目标或变更目标,动态进行数据采集和处理
基于文件的服务发现
注释 proemtheus.yml 中的 exporters 配置
重启 prometheus 服务
systemctl restart prometheus
准备 target 配置文件
cd /prometheus
mkdir targets
# vim dev_node.yaml
- targets:
- "192.168.28.66:9100"
- "192.168.88.66:9104"
修改 Prometheus 配置文件
# vim prometheus.yml
# 加上以下内容
- job_name: "node_service_discovery"
file_sd_configs:
- files:
- targets/*.yml
- refresh_interval: 60s
重启服务
systemctl restart prometheus
用于监控 Linux 的 metrics 正确 UP 了,检测 MySQL 的 metrics 却一直是 DOWN 状态
排查一下,如果说是 prometheus.yml 写错了,那压根就不会显示后台;说明是 dev_node.yml 写错了什么
cat prometheus/targets/dev_node.yml
确实是 targets 写错了
我们把他改对了,再看看
20241102202135740.png&pos_id=img-Shte1ISH-1730621534027)
由此说明,服务发现可以先把没有配置服务的 IP(端口)加上,只不过暂时会显示 DOWN 的状态
其他方法进行服务发现
除了基于文件的服务发现,Prometheus 还可以通过基于 k8s 的服务发现、基于 DNS 的服务发现
PromQL
- PromQL(Prometheus Query Language)
- Prometheus 自己开发,类似于 SQL 中的 DQL
- 使用这个查询语言能够进行各种聚合、分析和计算,使管理员能够根据指标更好地了解系统性能
时序数据库 TSDB
特点
- 数据写入——写多读少
- 数据查询——对最近生成的数据读取概率高;按一定的时间范围读取一段时间的数据
- 数据存储特点——数据存储量大;数据具有时效性(数据有一个保存周期)
时序数据库的基本要求
- 支持高并发、高吞吐的写入
- 快速查询的性能:提供索引支持或聚合查询
- 高可用性:在节点故障时能够自动恢复,保证系统的持续可用性;支持数据备份和恢复操作,防止数据丢失
- 可扩展性:支持通过添加新的节点来扩展存储和计算能力;
常见的时序数据库
- TimescaleDB: 基于 PostgreSQL 的时序数据库,支持 SQL 查询和事务处理
- OpenTSDB: 基于 HBase 的时序数据库,适用于大规模数据存储和查询
- InfluxDB: 开源时序数据库,支持高写入性能和灵活的查询语言
- VictoriaMetrics: 高性能、低成本的时序数据库,支持多租户和分布式部署
PromQL 操作符
数学运算
+
(加法)-
(减法)*
(乘法)/
(除法)%
(求余)^
(幂运算)
布尔运算
==
(相等)!=
(不相等)>
(大于)<
(小于)>=
(大于等于)<=
(小于等于)
集合运算符
and
(并且,交集)or
(或者,并集)unless
(差集)
操作符优先级
在 PromQL 操作符中优先级由高到低依次为:
^
*, /, %
+, -
==, !=, <=, <, >=, >
and, unless
or
PromQL 聚合操作
使用聚合操作的语法如下:
<aggr-op>([parameter,] <vector expression>) [without|by (<label list>)]
sum
(求和)min
(最小值)max
(最大值)avg
(平均值)stddev
(标准差)stdvar
(标准差异)count
(计数)count_values
(对 value 进行计数)bottomk
(后 n 条时序)topk
(前 n 条时序)quantile
(分布统计)
其中只有 count_values
, quantile
, topk
, bottomk
支持参数(parameter)
without 用于从计算结果中 移除列举的标签,而保留其它标签。
by 则正好相反,结果向量中 只保留列出的标签,其余标签则移除。
例子
sum()
计算所有实例的活跃内存(node_memory_Active_bytes
)总量,而不考虑具体的实例(instance
)
sum(node_memory_Active_bytes) without (instance)
显示每个 HTTP 状态码(code
)、请求处理程序(handler
)、被监控的服务或目标(job
)和 HTTP 请求方法(method
)的请求次数
sum(http_requests_total) by (code,handler,job,method)
计算整个应用的 HTTP 请求总量
sum(http_requests_total)
count_values()
count_values 会为每一个唯一的样本值输出一个时间序列,并且每一个时间序列包含一个额外的标签
count_values("count", http_requests_total)
topk()
topk()用于对样本值进行排序,返回当前样本值前 n 位,或者后 n 位的时间序列
获取 HTTP 请求数前 5 位的时序样本数据
topk(5, http_requests_total)
quantile()
quantile 用于计算当前样本数据值的分布情况
quantile(φ, express) # 其中0 ≤ φ ≤ 1
当 φ 为 0.5 时,即表示找到当前样本数据中的中位数:
quantile(0.5, http_requests_total)
内置函数
计算 Counter (计数器)指标增长率
increase() 函数
increase(v range-vector)
# 参数v是一个区间向量,increase函数获取区间向量中的第一个后最后一个样本并返回其增长量
例:统计主机节点最近两分钟内的平均 CPU 使用率
increase(node_cpu_seconds_total[2m] )/120
node_cpu [2m] 获取时间序列最近两分钟的所有样本,increase 计算出最近两分钟的增长量,最后除以时间 120 秒得到 node_cpu 样本在最近两分钟的平均增长率
12:33 左右,CPU 使用突然上升到接近满载的状态,然后保持稳定。这表明在这个时间段内,系统开机经历了一次显著的负载增加
rate() 函数
rate(v range-vector)
# 直接计算区间向量v在时间窗口内平均增长速率
例:统计主机节点最近两分钟内的平均 CPU 使用率
rate(node_cpu_seconds_total[2m])
跟之前的incraese()函数处理的结果一模一样
irate() 函数
统计瞬时增长率,避免长尾问题
irate(v range-vector)
# 通过区间向量中最后两个样本数据来计算区间向量的增长速率
例:统计主机节点最近两分钟内的平均 CPU 使用率
irate(node_cpu_seconds_total[2m])
irate函数相比于rate函数提供了更高的灵敏度,不过当需要分析长期趋势或者在告警规则中,irate的这种灵敏度反而容易造成干扰。因此在长期趋势分析或者告警中更推荐使用rate函数
预测Gauge(仪表盘)指标变化趋势
predict_linear函数()
predict_linear(v range-vector, t scalar)
预测时间序列v在t秒后的值。它基于简单线性回归的方式,对时间窗口内的样本数据进行统计,从而可以对时间序列的变化趋势做出预测
例子:基于2小时的样本数据,来预测主机可用磁盘空间的是否在4个小时候被占满
predict_linear(node_filesystem_free_bytes{job="node_service_discovery"}[2h], 4 * 3600) < 0
统计Histogram(直方图)指标的分位数
Histogram的分位数计算需要通过histogram_quantile(φ float, b instant-vector)函数进行计算,φ(0<φ<1)表示需要计算的分位数
以指标http_request_duration_seconds_bucket为例
http_request_duration_seconds_bucket{le="0.5"} 0
http_request_duration_seconds_bucket{le="1"} 1
http_request_duration_seconds_bucket{le="2"} 2
http_request_duration_seconds_bucket{le="3"} 3
http_request_duration_seconds_bucket{le="5"} 3
http_request_duration_seconds_bucket{le="+Inf"} 3
http_request_duration_seconds_sum 6
http_request_duration_seconds_count 3
计算9分位数时,使用如下表达式
histogram_quantile(0.5, http_request_duration_seconds_bucket)
Grafana数据展示
Grafana支持图表模板导入,支持除Prometheus之外多种数据源(包括MySQL、zabbix、elasticsearch等)
部署Grafana
下载软件包并安装
官网地址:https://grafana.com/grafana/download
安装grafana
rpm -ivh grafana-7.5.3-1.x86_64.rpm
# 或者用yum装
yum install -y grafana-7.5.3-1.x86_64.rpm
启动服务,加入开机自启
systemctl enable grafana-server
systemctl start grafana-server
看3000端口是否监听
访问Grafana
初始账号密码均为admin,登录以后提示修改密码
添加数据源
然后选择Prometheus数据源
!记得保存设置,不然默认监测localhost:9090端口
新建一个叫Prometheus的文件夹
创建仪表盘
可以选择各种监控项
添加node1磁盘可用空间的监测
添加更多监控项
仪表盘
保存仪表盘
点击右上角的save dashboard
使用第三方模板
官方模板网站:https://grafana.com/grafana/dashboards/
根据需求选择合适的模板
复制模板ID
回到仪表盘进行导入
展现当前Linux主机的全部状态
Altermanager告警
概述
- Prometheus对指标的收集、存储同告警能力分属于Prometheus Server和AlertManager两个独立的组件组成
- 前者仅仅负责基于告警规则生成告警通知,具体的告警操作则由后者完成
- AlertManager负责处理由客户端发来的告警通知
- 客户端通常是Prometheus Server,但也支持来自其他工具的告警
- AlertManageer对告警通知进行分组、去重后根据路由规则将其路由到不同的receiver,如email、企业微信、钉钉等
告警逻辑
- 在AlertManager上定义receiver,他们能够基于某个媒介接收告警信息的特定用户;
- 在Alertmanager上定义路由规则(route),以便将收到的告警通知按需分别进行处理
- 在Prometheus上定义告警规则生成告警通知,发送给Alertmanager
Altermanger机制
除了基本的告警,Atermanager还支持对告警进行去重分组、抑制、静默和路由等功能
分组机制
- 将相似告警合并为单个告警通知的机制
- 在系统因大面积故障而触发告警时,分组机制能避免用户被大量的告警噪声淹没,进而导致关键信息的隐没
抑制机制
- 系统中某个组件或服务故障而触发告警通知后,那些依赖于该组件或服务的其他组件或服务也会因此而触发告警
- 作用是避免类似的级联告警的一种特性,从而让用户的精力集中于真正的故障所在
静默机制
- 在一个特定的时间窗口内,便接收到告警通知,Alertmanager也不会真正向用户发送告警行为
- 通常,在系统例行维护期间,需要激活告警系统的静默特性
Altermanager的部署
下载解压安装包
mkdir /altermanager
tar -zxvf alertmanager-0.21.0.linux-amd64.tar.gz -C /altermanager/
cd /altermanager
和之前的组件类似,我们可以为这个文件夹赋予可执行权限并创建软链接
chown -R root:root alertmanager-0.21.0.linux-amd64/
ln -sv alertmanager-0.21.0.linux-amd64/ alertmanager
编辑Alertmanger配置文件
查看配置文件
# cat alertmanager.yml
global: # 全局配置模块
resolve_timeout: 5m # 用于设置处理超时时间,默认是5分钟
route: # 路由配置模块
group_by: ['alertname'] # 告警分组
group_wait: 10s # 10s内收到的同组告警在同一条告警通知中发送出去
group_interval: 10s # 同组之间发送告警通知的时间间隔
repeat_interval: 1h # 相同告警信息发送重复告警的周期
receiver: 'web.hook' # 使用的接收器名称
receivers: # 接收器
- name: 'web.hook' # 接收器名称
webhook_configs: # 设置webhook地址
- url: 'http://127.0.0.1:5001/'
inhibit_rules: # 告警抑制功能模块
- source_match:
severity: 'critical' # 当存在源标签告警触发时抑制含有目标标签的告警
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance'] # 保证该配置下标签内容相同才会被抑制
Alertmanager使用邮箱报警
QQ邮箱准备
生成授权码
修改配置文件
global:
resolve_timeout: 5m
smtp_from: '1640512870@qq.com'
smtp_smarthost: 'smtp.qq.com:465'
smtp_auth_username: '1640512870@qq.com'
smtp_auth_password: 'cdumhntvjsngejhf'
smtp_require_tls: false
smtp_hello: 'qq.com'
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: 'email'
receivers:
- name: 'email'
email_configs:
- to: '1640512870@qq.com'
send_resolved: true
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
后台启动Alertmanager
./alertmanager &
关联Prometheus
# vim /prometheus.yml
alerting:
alertmanagers:
- static_configs:
- targets:
- 192.168.28.88:9093
.....
- job_name: "Alertmanager"
static_configs:
- targets: ["192.168.28.88:9093"]
添加告警规则
mkdir -p /prometheus/prometheus/rules/
cd /prometheus/prometheus/rules
vim rule.yml
groups:
- name: up
rules:
- alert: node
expr: up{job="node_service_discovery"} == 0
for: 1m
labels:
severity: critical
annotations:
description: "Node has been dwon for more than 1 minutes"
summary: "Node down"
在Prometheus配置文件中导入
cd /prometheus/prometheus
vim prometheus.yml
rule_files:
- "/prometheus/prometheus/rules/*.yml"
用promtool检查语法
./promtool check rules rules/rule.yml
重启prometheus
systemctl restart prometheus
在web中查看Rules
关闭node1测试
三种状态
- Interval没有满足触发条件,告警未激活状态
- pending,已满足触发条件,但未满足告警持续时间的状态,即未满足告警中for子句指定的持续时间
- firing,已满足触发条件且已经超过for子句中指定的持续时间时的状态