Prometheus 监控平台(Prometheus Monitoring Platform)
Prometheus(普罗米修斯)是一个最初在 SoundCloud 上构建的监控系统。自 2012年成为社区开源项目,拥有非常活跃的开发人员和用户社区。为强调开源及独立维护,Prometheus 于 2016 年加入云原生云计算基金会(CNCF),成为继 Kubernetes 之后的第二个托管项目。本章详细介绍prometheus监控部署。
·
💝💝💝欢迎来到我的博客,很高兴能够在这里和您见面!希望您在这里可以感受到一份轻松愉快的氛围,不仅可以获得有趣的内容和知识,也可以畅所欲言、分享您的想法和见解。
推荐:Linux运维老纪的首页,持续学习,不断总结,共同进步,活到老学到老
导航剑指大厂系列:全面总结 运维核心技术:系统基础、数据库、网路技术、系统安全、自动化运维、容器技术、监控工具、脚本编程、云服务等。
常用运维工具系列:常用的运维开发工具, zabbix、nagios、docker、k8s、puppet、ansible等
数据库系列:详细总结了常用数据库 mysql、Redis、MongoDB、oracle 技术点,以及工作中遇到的 mysql 问题等
懒人运维系列:总结好用的命令,解放双手不香吗?能用一个命令完成绝不用两个操作
数据结构与算法系列:总结数据结构和算法,不同类型针对性训练,提升编程思维,剑指大厂
非常期待和您一起在这个小小的网络世界里共同探索、学习和成长。💝💝💝 ✨✨ 欢迎订阅本专栏 ✨✨
部署与应用
技能目标
-
理解
Prometheus
的常用组件
-
理解配置文件与核心功能使用
-
掌握
Kubeadm
方式部署
Prometheus
监控
-
掌握
Prometheus+Grafana
图表展示
5.1 Prometheus+Grafana 监控概述
5.1.1 什么是 Prometheus
Prometheus
(普罗米修斯)是一个最初在
SoundCloud
上构建的监控系统。自
2012
年成为社区开源项目,拥有非常活跃的开发人员和用户社区。为强调开源及独立维护,
Prometheus
于
2016
年加入云原生云计算基金会(
CNCF
),成为继
Kubernetes
之后的第
二个托管项目。
事实上,作为新一代的监控框架,
Prometheus
具有以下特点:
多维数据模型:由度量名称和键值对标识的时间序列数据;
PromSQL
:一种灵活的查询语言,可以利用多维数据完成复杂的查询;
不依赖分布式存储,单个服务器节点可直接工作;
基于
HTTP
的
pull
方式采集时间序列数据;
推送时间序列数据通过
PushGateway
组件支持;
通过服务发现或静态配置发现目标;
多种图形模式及仪表盘支持。
Prometheus
适用于以机器为中心的监控以及高度动态面向服务架构的监控。
5.1.2 什么是 Grafana
Grafana
是一个可视化面板,有着非常漂亮的图表和布局展示,功能齐全的度量仪
表盘和图形编辑器,支持
Graphite
、
zabbix
、
InfluxDB
、
Prometheus
、
OpenTSDB
、
Elasticsearch
等作为数据源,比
Prometheus
自带的图表展示功能强大太多,更加灵活,
有丰富的插件,功能更加强大。本章推荐使用的监控图表模板,集群资源监控模板
id
:
3116
,主机
Node
监控模板
id
:
9276
。在后期使用图表展示时可以通过
id
号导入所需的
监控模板。
5.1.3 为什么要用 Prometheus+Grafana 监控
监视应用程序的当前状态是预测问题和发现生产环境中瓶颈的最有效方法之一。监控是
整个产品周期中最重要的一环,及时预警减少故障影响面,而且能根据历史数据追溯问题。
一般在早期服务业务系统很少,通常可以用系统工具来解决,例如经常用到的监控命令
如
free
、
vmstat
、
df
、
top
、
iftop
等,这些适合临时性分析性能及排查故障中使用。随着互
联网
+
时代的发展人们对互联网依赖越来越大,一般常规性监控命令,不能满足现在业务的
需求。目前业内有很多不错的开源产品可供选择,利用开源产品很容易能做到这一点。如表
5-1
所示。
表
5-1 Zabbix,open-Falcon,Premetheus+Grafana
监控对比
监控方案 | 告警 | 特点 | 适用 |
Zabbix | Yes | 大量定制工作 | 大部分的互联网公司 |
open-falcon | Yes | 功能模块分解比较细,显得更复杂 | 系统和应用监控 |
Prometheus+Grafana | Yes | 扩展性好 | 容器、应用、主机全方位监控 |
5.1.3 Prometheus 组件
为了理解
Prometheus
工作原理,先来剖析下
Prometheus
的结构。
Prometheus
主要
包括以下组件,但是其中许多组件是可选的。
1.Prometheus 结构
Prometheus Server
:
用于收集指标和存储时间序列数据,并提供查询接口;
client Library
:
客户端库(例如
Go
,
Python
,
Java
等),为需要监控的服务产
生相应的
/metrics
并暴露给
Prometheus Server
。目前已经有很多软件原生就支持
Prometheus
并提供
/metrics
,可以直接使用。对于像操作系统已经不提供
/metrics
,
可以使用
exporter
,或者自己开发
exporter
来提供
/metrics
服务;
push gateway
:
主要用于临时性的
jobs
。由于这类
jobs
存在时间较短,可能在
Prometheus
来
pull
之前就消失了。
Jobs
定时将指标
push
到
push gateway
,再
由
Prometheus Server
从
Push gateway
上
pull
。这种方式主要用于服务层面的
metrics
;
exporter
:
用于暴露已有的第三方服务的
metrics
给
Prometheus
;
alertmanager
:
从
Prometheus server
端接收到
alerts
后,会进行去除重复数
据,分组,并路由到对应的接受方式,发出报警。常见的接收方式有:电子邮件,
pagerduty
,
OpsGenie, webhook
等;
Web UI
:
Prometheus
内置一个简单的
Web
控制台,可以查询指标,查看配置
信息或者
Service Discovery
等,实际工作中,查看指标或者创建仪表盘通常使
用
Grafana
,
Prometheus
作为
Grafana
的数据源。
2.Prometheus 数据模型
Prometheus
将所有数据存储为时间序列;具有相同度量名称以及标签属于同一个指标。
每个时间序列都由度量标准名称和一组键值对(也称为标签)唯一标识。
时间序列格式:
<metric name>{<label name>=<label value>, ...}
示例:
api_http_requests_total{method="POST", handler="/messages"}
3.Prometheus 指标类型
Counter
:递增的计数器;
Gauge
:可以任意变化的数值;
Histogram
:对一段时间范围内数据进行采样,并对所有数值求和与统计数量;
Summary
:与
Histogram
类似。
4.Prometheus 指标实例
实例:可以抓取的目标称为实例(
Instances
)。
作业:具有相同目标的实例集合称为作业(
Job
)。
5.1.4 Prometheus 配置文件及核心功能使用
Prometheus
的主配置文件是
YAML
格式,使用
--config.file
指定配置文件的位置。以下
列出本节重要的配置项。
1. 全局配置文件
Prometheus
以
scrape_interval
规则周期性从监控目标上收集数据,然后将数据存储到
本地存储上。
scrape_interval
可以设定全局也可以设定单个
metrics
。
Prometheus
以
evaluation_interval
规则周期性对告警规则做计算,然后更新告警状态。
evaluation_interval
只有设定在全局。
global
:全局配置。
alerting
:告警配置。
rule_files
:告警规则。
scrape_configs
:配置数据源,称为
target
,每个
target
用
job_name
命名。又分
为静态配置和服务发现。
global:
\\
默认抓取周期,可用单位
ms
、
smhdwy
,默认
1
分钟
[ scrape_interval: <duration> | default = 1m ]
\\
默认抓取超时时间为
10
秒
[ scrape_timeout: <duration> | default = 10s ]
\\
估算规则的默认周期,默认
1
分钟
[ evaluation_interval: <duration> | default = 1m ]
\\
和外部系统(例如
AlertManager
)通信时为时间序列或者告警(
Alert
)
\\
强制添加的标签列表
external_labels:
[ <labelname>: <labelvalue> ... ]
\\
规则文件列表
rule_files:
[ - <filepath_glob> ... ]
\\
抓取配置列表
scrape_configs:
[ - <scrape_config> ... ]
\\Alertmanager
相关配置
alerting:
alert_relabel_configs:
[ - <relabel_config> ... ]
alertmanagers:
[ - <alertmanager_config> ... ]
\\
远程读写特性相关的配置
remote_write:
[ - <remote_write> ... ]
remote_read:
[ - <remote_read> ... ]
2. 实例作业配置文件
scrape_configs
配置项是根据目标(
target
),以静态方式或者自动发现方式指定配
置任务(
job
)以
http/s
周期性的收到(
scrape/pull
),指定目标(
target
)上的指标数据
(
metric
)。
Prometheus
将收到(
scrape
)的指标(
metric
)数据保存在本地或者远程存储上。
\\
任务名称,自动作为抓取到指标的一个标签
job_name: <job_name>
\\
抓取周期
[ scrape_interval: <duration> | default = <global_config.scrape_interval> ]
\\
每次抓取的超时
[ scrape_timeout: <duration> | default = <global_config.scrape_timeout> ]
\\
从目标抓取指标的
URL
路径
[ metrics_path: <path> | default = /metrics ]
\\
当添加标签发现指标已经有同名标签时,是否保留原有标签不覆盖
[ honor_labels: <boolean> | default = false ]
\\
抓取协议
[ scheme: <scheme> | default = http ]
\\HTTP
请求参数
params:
[ <string>: [<string>, ...] ]
\\
身份验证信息
basic_auth:
[ username: <string> ]
[ password: <secret> ]
[ password_file: <string> ]
\\Authorization
请求头取值
[ bearer_token: <secret> ]
\\
从文件读取
Authorization
请求头
[ bearer_token_file: /path/to/bearer/token/file ]
\\TLS
配置
tls_config:
[ <tls_config> ]
\\
代理配置
[ proxy_url: <string> ]
\\DNS
服务发现配置
dns_sd_configs:
[ - <dns_sd_config> ... ]
\\
文件服务发现配置
file_sd_configs:
[ - <file_sd_config> ... ]
\\K8S
服务发现配置
kubernetes_sd_configs:
[ - <kubernetes_sd_config> ... ]
\\
此
Job
的静态配置的目标列表
static_configs:
[ - <static_config> ... ]
\\
目标重打标签配置
relabel_configs:
[ - <relabel_config> ... ]
\\
指标重打标签配置
metric_relabel_configs:
[ - <relabel_config> ... ]
\\
每次抓取允许的最大样本数量,如果在指标重打标签后,样本数量仍然超过限制,则
整个抓取认为失败
\\0
表示不限制
[ sample_limit: <int> | default = 0
3. Prometheus 主配置标签
relabel_configs
配置文件中的标签可以允许在采集之前对任何目标及其标签进行修改
和替换,利于后期展示和理解,如图
5.1
所示。
图
5.1 relabel_config
配置文件内标签
replace
:默认通过
regex
匹配
source_label
的值,使用
replacement
来引用表达式
匹配的分组;
keep
:删除
regex
与连接不匹配的目标
source_labels
;
drop
:删除
regex
与连接匹配的目标
source_labels
;
labeldrop
:删除
regex
匹配的标签;
labelkeep
:删除
regex
不匹配的标签;
hashmod
:设置
target_label
为
modules
连接的哈希值
source_labels
;
labelmap
:匹配
regex
所有标签名称。然后复制匹配标签的值进行分组,
r
eplacement
分组引用(
${1},${2},…
)替代。
4. 文件服务发现
Prometheus
也提供了服务发现功能,可以从
consul
,
dns
,
kubernetes
,
file
等等多种
来源发现新的目标。其中最简单的是从文件发现服务。
支持服务发现的来源:
azure_sd_configs
//
支持微软云服务发现
consul_sd_configs
//
支持
consul
自动注册服务发现
dns_sd_configs
//
支持
dns
服务发现
ec2_sd_configs
//
支持阿里云服务发现
openstack_sd_configs //
支持
OpenStack
服务发现
file_sd_configs
//
支持文件服务发现
gce_sd_configs
//
支持
GCE
服务发现
kubernetes_sd_configs//
支持
K8s
服务发现
marathon_sd_configs //
支持
Marathon
服务发现
nerve_sd_configs
//
支持
Nerve
服务发现
serverset_sd_configs //
支持
Zookeeper Serverset
服务发现
triton_sd_configs
//
支持
Triton
服务发现
5.2 K8s 集群快速部署 Prometheus
5.2.1 环境介绍
1.本节实验环境
本节结合之前章节
k8s Kubeadm
环境来部署安装
Prometheus
及
Grafana
,实
验环境包括一台
Master
节点,两台
Node
节点,关于本章
kubeadm
环境不做过多介
绍,重点关注
Prometheus
相关内容,具体配置要求如表
5-2
所示。
表
5-2 Kubeadm
安装
Prometheus
环境
主机名 | IP 地址 | 操作系统 | 主要软件 |
k8s-master | 192.168.9.206 | CentOS 7.3 x86_64 | Prometheus,Grafana |
k8s-node01 | 192.168.9.207 | CentOS 7.3 x86_64 | node_exporter |
k8s-node02 | 192.168.9.208 | CentOS 7.3 x86_64 | NFS,node_exporter |
2.实验要求
本节的实验要求如下:
通过
Kubeadm
实现快速部署
Prometheus+Grafana
监控系统。
完成对
K8s
资源监控并使用
Grafana
展示。
完成对
K8s Node
节点基础资源监控并用
Grafana
展示。
3.实现思路本节实验的实现思路大致如下:
(
1
)部署三台主机
K8s Kubeadm
基础环境。
(
2
)准备
Prometheus+Grafana
部署的
yaml
文件。
(
3
)通过
K8s
文件快速部署
Prometheus+Grafana
集群。
(
4
)通过
Grafana
添加数据源导入
K8s
资源监控模板实现
Grafana
图表展示。
4.实验拓扑
本节实验拓扑如图
5.2
所示。
图
5.2 Prometheus
实验拓扑
5.2.2 部署 Prometheus
1. 安装 K8s
通过
Kubeadm
方式安装
K8s
,安装方法可参考 K8s集群部署。
2. 上传 yaml 文件
将编写好的
yaml
文件,上传到
k8s-master
主机的“
root/prometheus
”目录下。
[root@k8s-master prometheus]# ll
-rw-r--r--. 1 root root 644 6
月
22 17:03 alertmanager-configmap.yaml
-rw-r--r--. 1 root root 2194 6
月
22 17:18 alertmanager-deployment.yaml
-rw-r--r--. 1 root root 400 6
月
24 00:10 alertmanager-pvc.yaml
-rw-r--r--. 1 root root 392 6
月
22 16:59 alertmanager-service.yaml
-rw-r--r-- 1 root root 1446 6
月
20 10:50 grafana.yaml
//
部署
Grafana
drwxr-xr-x 2 root root
77 6
月
20 12:24 node
//
部署
Promethues Hosts Agent
二进制文件
-rw-r--r-- 1 root root 5096 6
月
20 12:28 prometheus-configmap.yaml
//Promethues
主配置文件
-rw-r--r-- 1 root root 1080 6
月
19 22:57 prometheus-rbac.yaml
//
授权
Promethues
访问
k8s API
-rw-r--r-- 1 root root 4848 6
月
19 22:57 prometheus-rules.yaml
//Promethues
报警规则
-rw-r--r-- 1 root root 392 6
月
19 22:57 prometheus-service.yaml //Promethues
暴露访问端口
-rw-r--r-- 1 root root 3368 6
月
19 23:17 prometheus-statefulset.yaml //
通过有状态对象部署
Promethues
[root@k8s-master prometheus]#
grep 192.168.9. *.yaml
//
如果
IP
不同则需要修改
alertmanager-pvc.yaml:
server: 192.168.9.208
grafana.yaml:
server: 192.168.9.208
prometheus-configmap.yaml:
- 192.168.9.207:9100
prometheus-configmap.yaml:
- 192.168.9.208:9100
prometheus-statefulset.yaml:
server: 192.168.9.208
3. 应用 Prometheus RBAC 授权
只在
master
节点上执行。
[root@k8s-master prometheus]#
kubectl apply -f prometheus-rbac.yaml
4. 通过 configmap 创建 Prometheus 主配置文件
只在
master
节点上执行。
[root@k8s-master prometheus]#
kubectl apply -f prometheus-configmap.yaml
5. 部署 NFS
在
k8s-node02
节点部署
NFS
服务,可参考
Linux
网络服务nfs服务部署
。
6. 部署 Prometheus 及 Services
Prometheus
部署操作在
master
节点上执行。在执行
yaml
文件部署前需要先在
k8s-node02
节点上完成
NFS
共享存储的安装,并且在所有
node
节点创建挂载目录,配置
过程如下所示。
[root@k8s-node02 ~]#
vim /etc/exports
//
启动
nfs
和
rpcbind
服务
/data/file 192.168.9.0/24(rw,sync,insecure,no_subtree_check,no_root_squash)
[root@k8s-node02 ~]#
mkdir -p /data/file/prometheus-data
//k8s-node02
节点执行
[root@k8s-master prometheus]#
kubectl apply -f prometheus-statefulset.yaml
//
有拉取镜像操
作,如果网络较慢可能会失败超时
[root@k8s-master prometheus]#
kubectl apply -f prometheus-service.yaml
7. 查看已部署的 Prometheus Pod 及 svc
Pod
结果为
runing
,说明
Promethues
部署成功,可以用
svc
暴露出来的端口访问
Prometheus
控制台。
[root@k8s-master prometheus]#
kubectl get pod,svc -n kube-system
8. 验证是否部署成功
Prometheus
默认部署完成,只有运行程序的
Node
节点可以从外部访问,可通过如下
设置方式来实现通过任意节点来访问
Prometheus
控制台。三个节点都需要执行。
[root@k8s-master prometheus]#
iptables -P FORWARD ACCEPT
[root@k8s-master prometheus]#
echo 1 > /proc/sys/net/ipv4/ip_forward
如果部署成功,可通过访问
http://192.168.9.206:30090
来查看
Prometheus
的控制台
页面,如图
5.3
所示。
图 5.3 Prometheus 图形界面
5.2.3 部署 Grafana 图表展示
1. 部署 Grafana
在
k8s-master
主机进行操作。需要在部署
Grafana yaml
文件之前创建
Grafana
挂载
的数据目录。
[root@k8s-master prometheus]#
mkdir -p /data/file/grafana-data
//
三个节点均需创建
[root@k8s-master prometheus]#
chmod -R 777 /data/file/grafana-data/
//
三个节点均需创建
[root@k8s-master prometheus]#
kubectl apply -f grafana.yaml
//
有拉取镜像操作
2. 查看 Grafana 部署是否成功
通过查看
Pod
是否为
runing
状态及其暴露的端口,判断
Grafana
部署是否成功。
[root@k8s-master prometheus]#
kubectl get pod,svc -n kube-system
3. 验证并访问 Grafana
如果通过
http://192.168.9.207:30007
能访问到控制台,就说明
Grafana
部署成功。控
制台界面如图
5.4
所示。
图 5.4 Grafana 控制台
5.2.4 监控 k8s Node 节点
Prometheus
社区提供的
NodeExporter
项目可以对主机的关键度量指标进行监控。通
过
Kubernetes
的
DeamonSet
可以在各个主机节点上部署有且仅有一个
NodeExporter
实
例,实现对主机性能指标数据的监控。但由于容器隔离原因,使用容器
NodeExporter
并不
能正确获取到宿主机磁盘信息,故此本章将
NodeExporter
部署到宿主机上来对
Node
进行
监控。
1. 部署 Prometheus Agent 代理
[root@k8s-master prometheus]# cd /root/prometheus/
[root@k8s-master prometheus]# scp -r node 192.168.9.207:/root/
[root@k8s-master prometheus]# scp -r node 192.168.9.208:/root/
执行以下操作,安装
Prometheus Agent
。并通过
netstat
命令判断是否成功。
[root@k8s-node01 node]#
sh node_exporter.sh
[root@k8s-node02 node]#
sh node_exporter.sh
[root@k8s-node01 node]#
netstat -anplt | grep node_export
tcp6
0
0 :::9100
:::*
LISTEN
32399/node_exporter
tcp6
0
0 192.168.9.207:9100
192.168.9.208:19304
ESTABLISHED
32399/node_exporter
[root@k8s-node02 node]#
netstat -anplt | grep node_export
tcp6
0
0 :::9100
:::*
LISTEN
32399/node_exporter
tcp6
0
0 192.168.9.207:9100
192.168.9.208:19304
ESTABLISHED
32399/node_exporter
2. 修改 Prometheus 主配置文件
在
k8s-master
节点上修改
prometheus-configmap.yaml
文件,并重新应用该配置文件。
需要修改的地方已加粗。其中
192.168.9.207-208
是
K8s
的
Node
节点。
[root@k8s-master prometheus]#
vim prometheus-configmap.yaml
#
Prometheus
configuration
format
https://prometheus.io/docs/prometheus/latest/configuration/configuration/
apiVersion: v1
kind: ConfigMap
metadata:
name: prometheus-config
namespace: kube-system
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: EnsureExists
data:
prometheus.yml: |
rule_files:
- /etc/config/rules/*.rules
scrape_configs:
- job_name: prometheus
static_configs:
- targets:
- localhost:9090
- job_name: k8s-nodes
//
需要添加的配置文件
static_configs:
- targets:
- 192.168.9.207:9100
- 192.168.9.208:9100
……
3. 应用 confgmap 配置文件
执行以下操作,使其更新到
Prometheus
主配置文件中。
[root@k8s-master prometheus]#
kubectl apply -f prometheus-configmap.yaml
4. 通过 Prometheus 控制台查看配置文件
访问
http://192.168.9.206:3009/graph
,上方菜单栏单击
Status
链接,之后再单击
Configuration
子链接,可以看到刚刚添加的
K8s Node
节点,如图
5.5
所示。
图 5.5 Configuration 配置项
5. 查看是否更新成功
从图
5.6
中可知,刚添加的
Node
节点,已更新到
Prometheus
配置文件中。
图 5.6 config 配置内容
5.2.5 配置 Grafana Dashbord
1. 创建 k8s-node Dashbord
(
1
)根据
Node id
导入监控模板,并用
Grafana
展示。首先进入控制面板首页,如图
5.7
所示。
图 5.7 Grafana 控制面板
(
2
)添加数据源。单击设置按钮(小齿轮图标),选择“
Data Source
”,如图
5.8
所
示。
图 5.8 选择数据源
(
3
)数据源选择
Prometheus
。鼠标放到
Prometheus
上,选择最右侧的“
Select
”按
钮,如图
5.9
所示。
图 5.9 添加
Prometheus
数据源
(
4
)配置数据源。
HTTP
配置项下的
URL
填写“
http://prometheus:9090
”,这里的
prometheus
是
K8s
集群内的
Service
名,也可以使用
IP
地址代替,如图
5.10
所示。
图 5.10 Prometheus 数据源配置
配置完成后,单击最下方的“
Save & Test
”按钮保存设置。
(
5
)通过
Node id
导入监控模板。单击首页左侧搜索框下面的
+
的按钮。选择
import
按钮,输入监控模板
id
:
9276
。单击
Load
按钮加载即可,最后单击
Import
按钮导入,如
图
5.11
所示。
图 5.11 监控模板导入
(
6
)完成上述步骤后,可以查看到
Node
节点在
Dashbord
监控页面展示情况,如图
5.12
所示。
图 5.12 监控展示页面
2. 创建 k8s 集群资源监控状态 Dashbord
(
1
)重复“创建
k8s-node Dashbord
”的前两步,把模板
id
修改为
3119
,如图
5.13
所示。
图 5.13 导入
3119
资源监控面板
(
2
)创建完成后,如图
5.14
所示。
图 5.14 资源面板状态
至此,
Dashbord
已经正确显示。接下来配置
Alertmanager
报警功能。
5.2.6 部署 Alertmanager 报警
在
Prometheus
平台中,告警由独立的组件
Alertmanager
处理。通常情况下,首先定
位
Prometheus Alertmanager
所在的位置,然后在
Prometheus
配置中创建告警规则,最后
配置
Alertmanager
来处理告警并发送给接收者(邮件,
webhook
、
slack
等)。
1. 报警流程
Prometheus
告警和通知的设置,首先部署
Alertmanager
,然后配置
Prometheus
与
Alertmanager
通信,最后在
Prometheus
中创建告警规则,如图
5.15
所示。
图 5.15 报警流程
2. 配置 Prometheus 与 Alertmanager 通信
[root@k8s-master prometheus]#
vi prometheus-configmap.yaml
//
添加如下内容
alerting:
alertmanagers:
- static_configs:
- targets: ["alertmanager:80"]
2. 在 Prometheus 中创建告警规则
查看报警规则示例。
groups:
- name: example
#
报警规则组名称
rules:
#
任何实例
5
分钟内无法访问发出告警
- alert: InstanceDown
expr: up == 0
for: 5m #
持续时间 , 表示持续一分钟获取不到信息,则触发报警
labels:
severity: page #
自定义标签
annotations:
summary: "Instance {{ $labels.instance }} down" #
自定义摘要
description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5
minutes." #
自定义具体描述
3. 告警状态
Alertmanager
中产生告警信息后,这些信息有如下三种状态。
Inactive
:没有触发阈值。
Pending
:已触发阈值,但未满足告警持续时间。
Firing
:已触发阈值且满足告警持续时间。警报发送到
Notification Pipeline
,经过
处理,发送给接受者。
4. 告警发送
route
属性用来设置报警的分发策略,它是一个树状结构,按照深度优先从左向右的顺
序进行匹配。示例如下所示。
route:
receiver: 'default-receiver'
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
group_by: [cluster, alertname]
#
所有不匹配以下子路由的告警都将保留在根节点,并发送到
“default-receiver”
routes:
#
所有
service=mysql
或者
service=cassandra
的告警分配到数据库接收端
- receiver: 'database-pager'
group_wait: 10s
match_re:
service: mysql|cassandra
# 所有带有
team=frontend
标签的告警都与此子路由匹配
#
按产品和环境分组的,而不是集群
- receiver: 'frontend-pager'
group_by: [product, environment]
match:
team: frontend
group_by
:报警分组依据;
group_wait
:为一个组发送通知的初始等待时间,默认
30s
;
group_interval
:在发送新告警前的等待时间。通常
5m
或以上;
repeat_interval
:发送重复告警的周期。如果已经发送了通知,再次发送之前需要
等待多长时间。通常
3
小时或以上。
主要处理流程:
(
1
)当接收到
Alert
,根据
labels
判断属于哪些
Route
(可存在多个
Route
,一个
Route
有多个
Group
,一个
Group
有多个
Alert
)。
(
2
)将
Alert
分配到
Group
中,没有则新建
Group
。
(
3
)新的
Group
等待
group_wait
指定的时间(等待时可能收到同一
Group
的
Alert
),
根据
resolve_timeout
判断
Alert
是否解决,然后发送通知。
(
4
)已有的
Group
等待
group_interval
指定的时间,判断
Alert
是否解决,当上次发
送通知到现在的间隔大于
repeat_interval
或者
Group
有更新时会发送通知。
5. 告警收敛(分组、抑制、静默)
告警面临最大问题,是告警条目太多,相当于狼来了的形式。收件人很容易麻木,不再
继续理会,从而导致关键的告警常常被淹没,贻误处理故障的最佳时间。
Alertmanger
在一
定程度上很好的解决了这个问题。
Prometheus
成功的把一条告警发给了
Altermanager
,而
Altermanager
并不是简简单单的直接发送出去,这样就会导致告警信息过多,重要告警被
淹没,它对告警信息做了适当的收敛,如图
5.16
所示。
下面是告警收敛手段:
分组(
group
):将类似性质的警报分类为单个通知;
抑制(
Inhibition
):当警报发出后,停止重复发送由此警报引发的其他警报;
静默(
Silences
):是一种简单的特定时间静音提醒的机制。
图 5.16 告警收敛过程
6. Prometheus 一条告警怎么触发流程
Prometheus 的告警触发流程如图 5.17 所示。
图
5.17
告警触发流程
报警处理流程如下:
(
1
)
Prometheus Server
监控目标主机上暴露的
http
接口(这里假设接口
A
),通过
上述
Promethes
配置的
'scrape_interval'
定义的时间间隔,定期采集目标主机上监控数据。
(
2
)当接口
A
不可用的时候,
Server
端会持续的尝试从接口中取数据,直到
"scrape_timeout"
时间之后停止尝试。这时候把接口的状态变为
“DOWN”
。
(
3
)
Prometheus
同时根据配置的
"evaluation_interval"
的时间间隔,定期(默认
1min
)
的对
Alert Rule
进行评估。当到达评估周期的时候,发现接口
A
为
DOWN
,即
UP=0
为真,
激活
Alert
,进入
“PENDING”
状态,并记录当前
active
的时间。
(
4
)当下一个
alert rule
的评估周期到来的时候,发现
UP=0
继续为真,然后判断警报
Active
的时间是否已经超出
rule
里的
‘for’
持续时间,如果未超出,则进入下一个评估周期;
如果时间超出,则
alert
的状态变为
“FIRING”
;同时调用
Alertmanager
接口,发送相关报警
数据。
(
5
)
Alertmanager
收到告警数据后,会将告警信息进行分组,然后根据
Alertmanager
配置的
“group_wait”
时间先进行等待。等
wait
时间过后再发送报警信息。
(
6
)属于同一个
Alert Group
的警报,在等待的过程中可能进入新的
alert
,如果之前
的报警已经成功发出,那么间隔
“group_interval”
的时间间隔后再重新发送报警信息。比如配
置的是邮件报警,那么同属一个
group
的报警信息会汇总在一个邮件里进行发送。
(
7
) 如 果
Alert Group
里 的 警 报 一 直 没 发 生 变 化 并 且 已 经 成 功 发 送 , 等 待
‘repeat_interval’
时间间隔之后再重复发送相同的报警邮件;如果之前的警报没有成功发送,
则相当于触发第
6
条条件,则需要等待
group_interval
时间间隔后重复发送。
(
8
)最后警报信息具体发给谁,满足什么样的条件下指定警报接收人,设置不同报警
发送频率,由
Alertmanager
的
route
路由规则进行配置。
7. 通过部署 yaml 文件部署 Alertmanager
设置报警邮箱信息。在
k8s-master
上修改
alertmanager-configmap.yaml
,将邮箱配
置参数修改为自己的邮箱,具体操作如下所示。
[root@k8s-master prometheus]#
vi alertmanager-configmap.yaml
//
省略部分内容
data:
alertmanager.yml: |
global:
resolve_timeout: 5m
smtp_smarthost: '
smtp.163.com:25
'
smtp_from: '
18810044263@163.com
'
//
发送邮箱
smtp_auth_username: '
18810044263@163.com
'
//
发送用户
smtp_auth_password: '
yourself_password
'
//
修改为自己的密码
receivers:
- name: default-receiver
email_configs:
- to: "
shikun_zhou@126.com
"
//
修改为接收者邮箱
//
省略部分内容
在
k8s-master
节点上,分别执行
configmap
配置文件、
pvc
存储文件、
Alertmanager
主程序文件,
Services
暴露端口文件。
[root@k8s-node01 ~]#
mkdir /data/file/alertmanager-data/
[root@k8s-node01 ~]#
chmod -R 777 /data/file/alertmanager-data/
[root@k8s-master prometheus]#
kubectl apply -f alertmanager-configmap.yaml
[root@k8s-master prometheus]#
kubectl apply -f alertmanager-pvc.yaml
[root@k8s-master prometheus]#
kubectl apply -f alertmanager-deployment.yaml
[root@k8s-master prometheus]#
kubectl apply -f alertmanager-service.yaml
配置告警,修改
prometheus
主配置文件,指定
rules
目录。
[root@k8s-master prometheus]#
vi prometheus-statefulset.yaml
……
volumeMounts:
- name: config-volume
mountPath: /etc/config
- name: prometheus-data
mountPath: /data
subPath: ""
- name: prometheus-rules
//
新增报警规则内容
mountPath: /etc/config/rules
terminationGracePeriodSeconds: 300
volumes:
- name: config-volume
configMap:
name: prometheus-config
- name: prometheus-rules
//
新增报警规则内容
configMap:
name: prometheus-rules
- name: prometheus-data
persistentVolumeClaim:
claimName: prometheus-data
……
[root@k8s-master prometheus]#
kubectl apply -f prometheus-rules.yaml
[root@k8s-master prometheus]#
kubectl apply -f prometheus-statefulset.yaml
打开
Prometheus
控制台,在上方菜单栏中,单击
Status
链接,之后单击
Rules
。由结
果可知,新增的报警规则已成功添加,如图 5.18 所示。
图 5.18 新增报警规则
验证报警功能。在
k8s-node01
上停掉
Agent
,操作命令如下所示。
[root@k8s-node01 node]#
systemctl stop node_exporter
到
Prometheus
控制的“
Alert
”链接下,根据告警规则,
k8s-node01
节点会先出现
Pending
状态,之后变为
Firing
状态,如图
5.19
和
5.20
所示。
图 5.19 报警
Pending
状态
图 5.20 报警
Firing
状态
此时,查看之前配置的接收邮箱,会看到关于
k8s-node01
的报警信息,如图
5.21
所示。
图 5.21 接收报警信息
至此,
Promethues
监控部署完成。
更多推荐
已为社区贡献14条内容
所有评论(0)