💝💝💝欢迎来到我的博客，很高兴能够在这里和您见面！希望您在这里可以感受到一份轻松愉快的氛围，不仅可以获得有趣的内容和知识，也可以畅所欲言、分享您的想法和见解。
推荐: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 监控部署完成。
